Churn: GÉANT's Next Iteration in Network Monitoring and Reporting#

Erik Reid (GÉANT)

• Why: A rare, well-argued reference architecture for telemetry pipelines. GÉANT redesigned its monitoring/reporting stack after hitting three predictable walls: duplicated collector configuration across SNMP/NETCONF/gRPC, no unified picture of what talks to the devices, and tech-stack coupling (every debate about Influx vs. ClickHouse vs. Elastic vs. Telegraf vs. gNMIc stalling progress).
• What: Churn is not another monitoring tool or datastore — it consolidates device access and ingestion (gNMI, SNMP, NETCONF, SSH, ICMP) behind small, repeatable message processors, and deliberately keeps storage/visualization choices at the processing level rather than the architecture level. A deliberate "middle path" between a premature framework and per-service pipelines: share only what converges, keep internals explicit (no "metadata" trap), accept some per-integration effort.
• How: Processors follow a consume → filter → transform → publish pattern over RabbitMQ exchanges, with strict internal consistency via Pydantic validation; internal Churn models never leave Churn. Horizontal scaling via round-robin task queues over shared exchanges. Notably, Prometheus is used as a lightweight data-sharing tool (via ROBIN to NRENs and the community) rather than as a monitoring platform — a trick worth stealing. EuroHPC reporting needs were absorbed by reusing the same pipelines.
• Where applicable: GÉANT-scale backbone, but the processor pattern and the design reasoning transfer to any observability pipeline rebuild. Source code and documentation are publicly available (GÉANT GitLab).