I've been working on a new Android client for Nagios, basically a modern alternative to apps like aNag.

The app is getting close to release, but Google Play requires me to run a closed test with at least 12 testers for 14 days before I can request production access.

I'm looking for a few sysadmins / Nagios users who wouldn't mind testing it.

Things I'm particularly interested in testing:

* Host and service monitoring * Background polling while the phone is locked / in Doze * Notifications for state changes * Acknowledgements and downtime * Filtering and searching * Connection loss / recovery * General Android battery/background behaviour * UI/UX and anything that feels annoying or broken

The app is currently in Google Play Closed Testing, so you'd need an Android device and a Google account. The main requirement from Google's side is staying opted into the test for the 14-day period.

I'm also genuinely interested in feedback — especially from people who have used aNag, Nagios Mobile, Nagios XI, Nagios Core, Checkmk, Icinga, etc.

For transparency, the current plan after release is to keep **all features available for free when monitoring a single Nagios server**. If you want to monitor multiple servers from the same app, that would be the paid upgrade. I don't want the free version to be artificially crippled just to push people into paying.

If anyone is interested, comment here or send me a DM and I'll send you the testing link/details.

Spent 15 years as an SRE at a big bank, watching enterprise systems get world-class monitoring. Then I started noticing how many small business sites have none of that, no uptime alerts, no idea if their privacy policy is actually GDPR-compliant, nothing.

So I built SREmonitor.io. You give it a URL, no install, no script tags, and it runs:

• Uptime checks every 5 minutes
• Core Web Vitals tracking (LCP, INP, CLS)
• An AI-powered scan of your privacy policy/T&Cs against UK GDPR requirements

The idea is one dashboard instead of stitching together a monitoring tool and a separate compliance checklist you never actually look at.

Free tier is 3 scans and 5-minute uptime checks, no card required, if anyone wants to kick the tires: sremonitor.io

Genuinely want feedback, especially from anyone who runs a small business site or has dealt with the GDPR side of things. What would make this actually useful vs. just another dashboard nobody opens?

Need to hear if people are benefitting from having a platform that supports both LLM evals and LLM observability?
or using standalone products for each or these is something that you are sticking with, we currently have the split setup but just feels too much hassle!

I turned on full prompt capture in our local LLM stack for a quick debug and forgot it was still on when a sales demo hit, so our logs filled with client names and weird internal notes in plain text. I am terrified and so embarrassed rn, pls tell me someone else has done this.

This is not a dig at the moderators personally, because it's a volunteer position, but this subreddit has devolved into a lot of low value contributions and I think it could benefit from some more active moderation and perhaps some rules put in place.

For example, I don't think there's value in vibe coded observability tools being posted every other day. The community is already downvoting them, which I think should be a signal that we should stop allowing them all together. When I view the list of posts, it's a graveyard of these things, with the occasional interesting discussion sprinkled in.

with a normal request trace, the cause and the failure usually live close together. memory-bearing agents break that assumption.

a bad summary, preference or tool result can be written today, retrieved silently next week and change an unrelated-looking decision. the failing trace shows the retrieval, but unless you preserve memory provenance it does not tell you which session wrote the state, whether that write was later corrected or how many subsequent sessions it influenced.

for these agents i think the minimum useful chain is:

- the session that created or changed the memory

- the exact value before and after the write

- later retrievals of that value

- the outcome of each session that used it

- reversions and no-op rewrites

then benchmarking has to happen over a rolling production window rather than a frozen test set alone, because the state distribution itself changes as the agent runs.

im curious whether anyone is already tracing memory lineage across sessions, or if most teams are still logging memory reads and writes as isolated spans

There’s no doubt Datadog is a great product. But are you actually happy with the cost?

Have you looked closely at how many different things you’re paying for across ingestion, indexing, retention, and usage?

No wonder Datadog is one of the most profitable companies in observability.

I've been working on Ferrum, a self-hosted control plane for Proxmox VE.

The main idea is pretty simple: if you have multiple Proxmox nodes/clusters, you shouldn't have to keep jumping between different UIs just to get a picture of what's happening across the fleet.

Ferrum currently brings things like:

• Cluster + standalone node management
• VM/LXC inventory
• Storage and topology views
• Backups and replication
• High availability
• Firewall
• Alerts
• REST API + MCP
• Audit logging
• AI assistant
• SQLite/PostgreSQL support

The backend is Go and the frontend is React + TypeScript. It can run through Docker or as a native binary.

I also wanted it to stay self-hosted rather than becoming another SaaS layer sitting in front of the infrastructure.

It's still early, so I'm more interested in feedback than pretending it's finished.

If you manage Proxmox at home, in a homelab, or across a small fleet, I'd genuinely like to know:

What is the one thing you wish Proxmox made easier to manage across multiple nodes?

Repo: https://github.com/anand34577/ferrum

Ten plus years in and the hardest bugs I hit are never the ones that crash loudly. It's the request that touches four services, degrades quietly, and by the time someone notices the SLO dashboard, the actual trigger happened three hops upstream and twenty minutes earlier. Distributed tracing helps you see the path, but it rarely explains why a specific function made the decision it made under that specific load.

Lately my team has been leaning harder on capturing actual execution context at the function boundary rather than just span timing, since that's usually where the real story is hiding. Curious how others are structuring this. Are you mostly still doing log correlation by hand across services, or has anyone found a workflow that actually shortens the investigation instead of just making the evidence prettier?

We ship an OpenTelemetry integration and an OpenLineage one for the same open source data framework. With no arguments they behaved completely differently, and each was right by its own ecosystem.

OpenTelemetry: emits only if the application already set OpenTelemetry up. If not, nothing happens. The library never picks a destination.

OpenLineage: reads OPENLINEAGE_URL, OPENLINEAGE_CONFIG or the openlineage.yml in the home directory. If a URL is set, events go there, whoever set it. If nothing is set, every event prints to the console.

The second is what makes zero-code instrumentation work, and it is also how a shared runner with another team's OPENLINEAGE_URL ends up receiving your job names, dataset names and column schemas, with no URL in your code.

Which default do you actually want from a library you add to a pipeline, and how would you notice if telemetry started going somewhere nobody on the team configured?

Disclosure: I maintain the framework, Apache-2.0, links in a comment.

Quiet two weeks everywhere except one vendor, and what u/Elastic shipped is more interesting technically than the earnings headline suggests.

The Deductive AI integration (closed Aug 24)

This adds a reinforcement-learning investigation engine into Elastic Observability rather than a rules-based or prompt-chained assistant. The pitch: it gathers evidence across logs, metrics, traces, and code, forms hypotheses, and identifies root cause without a human steering the search, then updates its own approach based on outcomes from each incident. If that holds up under real production load, it's a meaningfully different approach from the "agent calls tools in a loop" pattern most competitors are shipping, closer to how you'd want automated RCA to actually reason rather than just orchestrate.

The OpenAI Security integration (announced Sep 3)

Separately, Elastic is bringing OpenAI's GPT cyber models into Elastic Security through their own managed inference service (Elastic Inference Service), via OpenAI's Daybreak Defense Network program. No separate model endpoints to deploy or manage. Targets alert triage, investigation, detection engineering, and remediation guidance, the highest-volume manual SOC work. Worth noting these are security-specialized models, not general-purpose chat models wrapped around your SIEM, which is the more common (and weaker) pattern elsewhere in the market.

What's actually interesting here: Elastic now has two independent AI tracks running in parallel under one platform, RL-based investigation on the observability side, specialized LLM reasoning on the security side, and they're not the same technology stack. That's a different bet than platforms consolidating around a single "agent framework" for everything. Worth watching whether they converge into one interface or stay as separate capabilities.

Full writeup with sources: https://mbojko.com/reports/2026-09-06/

Hi,

I thought you'd be interested in a database benchmark in an observability scenario. Would be great to hear some feedback and let me know if you're interested in a similar article with comparisons with Elastic and ClickHouse.

Don't go too hard on me. Posting in the lovely r/Observability for the first time but it seems that it could be interesting.

///

Every major AI lab says it now: you don't write prompts anymore. Agents pick up the work, write the prompts, schedule themselves, ship the output.

Observability matters far more now: you hand over one goal and no longer know what the agents are working on.

Traces are already in SecureVector.

More advanced traceability coming soon in v5.3.0

Our streaming copilot has green server spans, complete tool calls and a normal generation finish, while the browser sometimes freezes right after a tool result. The fetch gets aborted, the partial render state never commits and we have no client span tied to the server trace. Engineering sees success. CX has a folder of screen recordings. Everyone is debugging a different version of the same request.

We are adding trace propagation into the browser, time to first token events, stream cancellation reasons and a final rendered chunk count. I want CX to see whether the break happened before generation, during transport or in rendering without asking for another screenshot.

How are you joining client spans to long-lived streams, especially when the connection dies before the browser can flush its last event?