Bymond Operations Intelligence
A fleet telemetry and smart-alerting platform Bymond is building to monitor its own BigBlueButton and Linux infrastructure. It is in development, not yet running as the production system of record.
What we're building
Operations Intelligence is a purpose-built observability stack for Bymond's own fleet: a lightweight per-node agent reporting over mutually-authenticated TLS, a central ingestion and verification service, and a Prometheus, Alertmanager, and Grafana layer tuned to tell a real infrastructure emergency apart from routine noise. It is not yet promoted to production across the fleet. The existing Node Exporter and BigBlueButton Exporter monitoring remains the system of record while this is validated.
Generic monitoring doesn't understand BigBlueButton-specific state
Standard server monitoring answers “is the CPU busy” well. It doesn't naturally answer the questions that actually matter for a managed BigBlueButton fleet: whether a customer's recording storage is genuinely close to their entitlement, or whether a spike in load is a real capacity problem versus an expected traffic pattern. Answering those required manually cross-referencing multiple systems instead of getting a single, trustworthy alert.
What the platform needs to guarantee
- A per-node collector reporting real, factual system and BBB-specific state, not guesses.
- Delivery that can't be spoofed or replayed.
- Central verification before anything reaches a dashboard or alert.
- Alerting that separates infrastructure emergencies from business-logic warnings from noise.
- No path for a node collector to become a remote command channel.
Architecture
A one-directional pipeline by design: the node agent reports up through a verifying ingestion service to the alerting layer, with no path back down to the node. A monitoring collector that can also receive commands is a much larger blast radius if anything upstream is ever compromised.
What's actually hard about this
Trustworthy telemetry delivery
Every node gets its own mutual-TLS identity issued through a one-use enrollment token, with two-phase certificate rotation (a new key is generated, both certificates overlap briefly, then the old one is retired), so a compromised or decommissioned node can't keep reporting under its old identity.
No remote command surface
The collector is deliberately read-only: it gathers and reports facts about a host, but the production runtime has no path for the central service to push commands back down to a node. A monitoring agent that can also execute commands is a much larger blast radius if anything upstream is ever compromised.
Separating infrastructure emergencies from business warnings
A full disk is an infrastructure emergency. A customer approaching their storage quota is a business warning. Conflating the two into one alert stream trains people to ignore alerts, so they get separate rules, separate routes, and independent critical-alert relays, each with an external dead-man signal, so a silent failure of the alerting pipeline itself doesn't go unnoticed.
Reconciling entitlements without guessing
Business-storage alerting compares actual recording bytes against one authoritative entitlement record. If that record is stale, ambiguous, or unknown, the system suppresses the business decision and raises a data-quality alert instead of guessing. No AI participates in entitlement arithmetic.
How it fits together
bymond-agent runs on each node as an unprivileged collector, reporting factual Linux and BigBlueButton state: CPU, memory, filesystems, network counters, and, on approved BBB hosts, aggregate meeting and recording-inventory metrics with no meeting identifiers or customer data leaving the node. bymond-ops verifies every batch with mutual TLS and Ed25519 signatures before it reaches Prometheus, and reconciles state periodically rather than trusting a single report. Alertmanager and Grafana sit on top, with infrastructure alerts, business warnings, and two independent critical-alert relays kept deliberately separate.
What it's built on
Why this is labeled In Development, not Production
- Not yet fleet-authorized: the project's own implementation status explicitly states that fleet production promotion has not been authorized. The existing Node Exporter and BigBlueButton Exporter monitoring remains the system of record until this is validated in production.
- Verification rigor: the agent, ingestion service, and monitoring configuration each pass their full automated test suites, static analysis, and dependency-vulnerability audits before any release is considered.
- Release integrity: production builds are signed and checksummed, with a rollback-capable installer that verifies both before installing anything.
See it in context
Thinking about fleet monitoring or alerting for your own infrastructure?
Telemetry, alerting design, or just too much noise from your current monitoring: tell us what's not working.