Observability & monitoring

Two gaps in the open-source observability stack — and the two tools we built to close them

We don't just integrate monitoring tools — we build them. A tour of SenHub Agent and Toise, our two open-source, OpenTelemetry-native projects.
Two gaps in the open-source observability stack — and the two tools we built to close them
← All blog articles

3 a.m. An alert. You open five tabs — the infra dashboard, the APM, the network tool, the SIEM, the runbook wiki — and twenty minutes later you know that something is wrong without knowing what changed since last night. That’s the blind spot of most observability stacks: plenty of signals, few answers.

Building that stack for clients for eleven years, we ended up mapping two recurring gaps in the modern open-source stack. The first is at the bottom, in collection. The second is at the top, in comprehension. We built one open-source tool for each: SenHub Agent and Toise. Here’s the story — and why it holds together as a single thread.

Gap #1 — collection is a zoo of agents

Look at any mid-market infrastructure: a Prometheus agent here, a homegrown exporter there, a PRTG sensor on the Windows servers, a Nagios plugin on the legacy boxes, a cloud collector for the rest. Each tool speaks its own dialect. Metric names diverge, units too, and the day you decide to move to OpenTelemetry you discover that “migrating” means re-instrumenting ten different chains.

SenHub Agent starts from the opposite premise: collect once, export everywhere. A single Go binary (~9 MB, zero dependencies) carries probes — operating systems, databases, hyperconverged appliances, backup software, network gear — and emits everything through one OpenTelemetry pipeline. The same data comes out as OTLP, as Prometheus, and natively as PRTG and Nagios, with one vocabulary end to end.

  • One agent, not ten. You add a probe in YAML; you don’t glue together third-party exporters.
  • One vocabulary across every output: names, units and attributes match across PRTG, Nagios, Prometheus and OTLP.
  • No big bang. Keep PRTG or Nagios today, and the same collection feeds your OTel stack the day you switch. Migration becomes a change of output, not of sensors.
  • Open-core, Apache 2.0: free OS probes, vendor probes (Citrix, NetScaler, Veeam, Redfish…) in Pro.

In practice: agent.senhub.io. It’s also the technical engine behind our Monitoring as a Service.

Gap #2 — you have metrics, not understanding

Say collection is clean. You now have terabytes of time series. But a metric answers “is it down?“, rarely “why?“, and almost never “what changed?“. Yet 80% of incidents start with a change: a deployment, a network route, a dependency that moved. That information — inventory, topology, how they evolve over time — isn’t in your metrics.

Toise is the missing brick: a living, time-aware map of your infrastructure. Which objects exist (hosts, processes, interfaces, addresses, routes, services), how they connect, and — above all — how all of it changes. The log is event-sourced and bi-temporal: not just “what is the state”, but “what changed, when, and how is it different from yesterday”.

And because the real question during an incident is never a well-formed SQL query, Toise ships a native MCP server: your AI assistant queries the graph in plain language, on your behalf. “Which switches did host db-07 depend on last Tuesday — and what changed since?” becomes a question you ask, not a twenty-minute investigation. Humans keep a GraphQL API and a built-in debug UI.

Toise is in early development, in the open: the architecture, data model, OTLP ingestion and MCP server are under active design. It sits at the core of our AI-observability work (Ops Center project). Follow it at toise.dev.

The thread: OpenTelemetry end to end

The two tools aren’t two products side by side: they interlock. SenHub Agent emits OpenTelemetry entity events; Toise ingests them to build its graph. OTLP is the backbone — no proprietary protocol, no homegrown collector to maintain, no translation layer. You can in fact feed Toise from any OTel producer (a standard Collector, your own instrumentation), not just from SenHub Agent.

That choice has three direct consequences for you:

  • No lock-in. Open standards, Apache 2.0 licence. Your observability stays reversible and integrable.
  • Sovereignty. 100% self-hostable, with no dependency on the US AIOps giants. End-to-end on-premise remains possible.
  • One mental model. From collection to an AI-queried graph, it’s the same data, the same vocabulary. Less surface, less glue, less debt.

From tool to engagement

Why does a consultancy build open-source tools rather than just integrate other people’s? Because the rigour we put into these repositories is exactly the rigour we bring to you. Our consultants have all worked in IT production: SenHub Agent and Toise are the building blocks we wished we had had at 3 a.m. What we learn building them — about collection, topology, AI applied to ops — feeds straight back into our monitoring, observability and Monitoring as a Service engagements.

Want to dig in? It’s all on our open-source Labs. And if you’d like to run this at scale without carrying the load, let’s talk about your project.

An observability project on the horizon?

Let's talk about your context. Audit, consulting, integration — together we map out the best way forward.

Contact us

Related reading

OpenTelemetry, VictoriaMetrics, Grafana: The Open-Source Stack That Changes the Game
Observability & monitoring

OpenTelemetry, VictoriaMetrics, Grafana: The Open-Source Stack That Changes the Game

April 16, 2026
White paper: “From Monitoring to Observability” — full version available for download
Observability & monitoring

White paper: “From Monitoring to Observability” — full version available for download

May 19, 2026
Building Your Observability Roadmap: 4 Phases, Results at Every Step
Observability & monitoring

Building Your Observability Roadmap: 4 Phases, Results at Every Step

May 7, 2026