From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform

Razvan Cicu, Giovanni Pepe
9 min readintermediate
--
View Original

Overview

Uber Engineering details their migration from a legacy monolithic monitoring system to a modern, cloud-native observability platform for their corporate network infrastructure. The article covers the architecture built on open-source tools (Telegraf, Prometheus, Thanos, Grafana, Elasticsearch) deployed on Kubernetes across global regions, featuring dynamic configuration management, intelligent alert ingestion, and AIOps capabilities to reduce Mean Time To Repair.

What You'll Learn

1

How to architect a cloud-native observability platform using open-source tools like Prometheus, Thanos, Telegraf, and Grafana on Kubernetes

2

How to implement dynamic configuration management for monitoring agents that automatically adapts to network inventory changes

3

Why transitioning from static monitoring to context-rich observability improves incident resolution and operational awareness

4

How to build an intelligent alert ingestion system that de-duplicates, correlates, and enriches alerts from multiple sources

5

How to leverage centralized alert data for AIOps to reduce Mean Time To Repair (MTTR)

Prerequisites & Requirements

  • Understanding of network monitoring concepts (SNMP, metrics collection, alerting)
  • Familiarity with Kubernetes and containerized microservices architecture
  • Basic understanding of time-series databases and metrics storage (Prometheus)
  • Experience with enterprise network infrastructure monitoring at scale(optional)
  • Familiarity with Grafana, Elasticsearch, or similar observability tooling(optional)

Key Questions Answered

What open-source technologies does Uber use for corporate network observability?
Uber uses Telegraf for metrics collection (supporting SNMP, API, and MQTT protocols), Prometheus for real-time metrics storage with Thanos for long-term storage and global querying, Grafana and Kibana for visualization dashboards, and Elasticsearch for metadata indexing and search. The entire stack runs on Kubernetes as containerized microservices deployed across USC, EMEA, and APAC regions.
How does Uber dynamically update monitoring configuration without redeploying agents?
Uber built a Dynamic Config App that tracks inventory updates in Elasticsearch, continuously refreshed from ServiceNow as the source of truth. When devices are added, removed, or reassigned, the Config App immediately reflects changes in Telegraf's configuration. Telegraf agents periodically check their configuration URL and automatically reload when the Last-Modified timestamp changes, using parameters like region, site, or device type to filter which devices to poll.
What is the difference between monitoring and observability in network operations?
Monitoring answers 'Is it up?' by providing static checkpoint-style metrics about system status. Observability answers 'Why does it feel slow?' by providing context-rich insights into system behavior. Observability combines enriched data from multiple sources, correlates events across systems and regions, and enables engineers to understand the full journey of an incident from first detection to resolution.
How does Uber handle alert noise and deduplication in their observability platform?
Uber's Alert Ingestion App, built on FastAPI, Celery, and Redis, processes alerts asynchronously and in parallel. It filters and prioritizes alerts by importance, groups similar events to reduce alert storms, adds context and correlation so engineers understand root causes, and updates alerts in real-time by editing existing notifications as states change rather than creating duplicates, preventing flooding of Slack and PagerDuty.
How does Uber use AIOps with their observability platform for faster incident resolution?
By centralizing all alert data (both firing and resolved) into Elasticsearch, Uber creates a rich historical dataset that feeds an AI engine. This engine analyzes past network behavior patterns to help engineers pinpoint root causes faster, lowering MTTR. The architecture also supports interactive AI agents like a Slack bot where engineers can ask natural language questions about alert trends and receive immediate, context-rich answers during incidents.
Why did Uber choose a cloud-native microservices architecture for their observability platform?
Uber chose cloud-native microservices on Kubernetes for modularity, resilience, and scalability. Each component is a containerized service communicating via APIs, making the system open to new integrations. Kubernetes provides automatic restarts for failed components ensuring high availability. The global deployment across USC, EMEA, and APAC regions ensures monitoring probes provide accurate, low-latency measurements by being geographically close to monitored devices.
What cost savings did Uber achieve by migrating to open-source observability tools?
Uber eliminated hundreds of thousands of dollars in recurring licensing fees by replacing their legacy monolithic monitoring system with an open-source stack. These savings allowed the team to reinvest resources into more innovative parts of their strategy, including AIOps capabilities and AI-driven network operations for smarter incident resolution.

Key Statistics & Figures

Licensing cost savings
Hundreds of thousands of dollars in recurring fees eliminated
By migrating from legacy proprietary monitoring to open-source observability stack
Global deployment regions
3 regions
USC, EMEA, APAC

Technologies & Tools

Some links below are affiliate links. We may earn a commission if you make a purchase.

Metrics Collection
Telegraf
Lightweight data collection agent supporting SNMP, API, and MQTT protocols for gathering metrics from network devices
Metrics Storage
Prometheus
Real-time time-series metrics storage and alerting engine
Metrics Storage
Thanos
Long-term metrics storage and global query view extending Prometheus
Visualization
Grafana
Unified dashboards for metrics visualization and alerting
Visualization
Kibana
Dashboard visualization for log and alert data from Elasticsearch
Search And Metadata
Elasticsearch
Indexing device inventory metadata, alert history, and enabling search across operational data
Orchestration
Kubernetes
Container orchestration platform for deploying all observability microservices with high availability
Backend Framework
Fastapi
Python web framework powering the Alert Ingestion App
Task Queue
Celery
Distributed task queue for asynchronous and parallel alert processing
Message Broker
Redis
Message broker for Celery task queue in the alert ingestion pipeline
Cmdb/Itsm
Servicenow
Source of truth for network device inventory that feeds into Elasticsearch
Protocol
Snmp
Network management protocol used by Telegraf for polling network devices
Protocol
Mqtt
Lightweight messaging protocol used for IoT sensor data collection and alert sources
Network Management
Meraki
Third-party network system integrated via webhooks for alert ingestion
Network Management
Hpe Mist
Third-party wireless network system integrated via webhooks for alert ingestion
Communication
Slack
Alert notification channel and interactive AI bot interface for incident response
Incident Management
Pagerduty
Critical alert routing and on-call notification system

Key Actionable Insights

1
Implement dynamic configuration management for monitoring agents instead of relying on static configuration files. By connecting your monitoring agents to a centralized inventory service and using mechanisms like Last-Modified timestamp checks, agents can automatically adapt to infrastructure changes without manual edits or redeployments.
This is especially critical for large-scale environments where devices are frequently added, removed, or reassigned across regions. Uber's approach uses ServiceNow as source of truth synced to Elasticsearch, with Telegraf agents polling for configuration updates.
2
Build an intelligent alert ingestion layer that de-duplicates, groups, and enriches alerts before routing them to communication channels. Rather than forwarding every alert directly to Slack or PagerDuty, process alerts asynchronously to filter noise, correlate related events, and update existing notifications as alert states change.
Alert fatigue is a major operational challenge. Uber uses FastAPI, Celery, and Redis for async alert processing, posting alerts once and editing them as states change rather than creating duplicate notifications.
3
Deploy monitoring infrastructure globally with probes geographically close to the devices being monitored. This ensures accurate, low-latency measurements and avoids misleading data caused by network distance between monitoring systems and their targets.
Uber deploys across USC, EMEA, and APAC regions, using regional parameters to filter which devices each Telegraf agent polls, enabling workload redistribution across regions.
4
Centralize all alert data—both firing and resolved—into a searchable index to create a historical dataset that enables AIOps capabilities. This historical context allows AI engines to identify patterns, correlate incidents, and suggest root causes based on past behavior.
Uber routes all alerts from Prometheus, MQTT sensors, and network APIs into a single Elasticsearch index, creating a continuous trail of operational awareness that engineers can query and that AI systems can analyze.
5
Choose an open-source observability stack over proprietary monolithic monitoring tools to gain flexibility, avoid vendor lock-in, and eliminate significant licensing costs. Prioritize tools that handle specific functions well (collection, storage, visualization, search) rather than a single tool that does everything.
Uber saved hundreds of thousands of dollars in recurring licensing fees by adopting Telegraf, Prometheus, Thanos, Grafana, Kibana, and Elasticsearch, while gaining better extensibility through API-driven integrations.
6
Use tag-based filtering (region, site, device type) in your monitoring configuration to enable fine-grained control over what each collector monitors. This allows you to roll out new collectors or plugin changes globally without redeploying agents.
Uber's Dynamic Config App uses URL parameters like /v1/snmp/cisco?region=EMEA to filter device polling assignments, enabling instant redistribution of workloads across their global infrastructure.

Common Pitfalls

1
Relying on static configuration files for monitoring agents in a dynamic, large-scale environment. Static configs require manual edits and redeployments every time a device is added, removed, or reassigned, which cannot keep pace with a live global network and leads to monitoring gaps.
Uber solved this by building a Dynamic Config App that syncs with the device inventory and automatically generates updated configurations that Telegraf agents reload based on Last-Modified timestamps.
2
Forwarding every alert directly to communication channels without intelligent filtering, grouping, or deduplication. This creates alert storms that overwhelm engineers and cause critical alerts to be lost in noise, ultimately increasing incident response times.
Uber's Alert Ingestion App processes alerts asynchronously, groups similar events, adds context and correlation, and updates existing alert notifications rather than creating duplicates.
3
Treating monitoring as sufficient when observability is needed. Traditional monitoring only confirms whether something is up or down but doesn't explain why issues occur or how different parts of the system interact, leaving engineers without the context needed for fast incident resolution.
The shift to observability requires combining enriched data from multiple sources, correlating events across systems and regions, and enabling full incident journey tracing from detection to resolution.
4
Running monitoring probes from a single centralized location rather than distributing them geographically close to monitored devices. Remote monitoring introduces network latency that skews measurements and can mask or create false alerts about device health.
Uber deploys across three global regions (USC, EMEA, APAC) to ensure monitoring probes provide accurate, low-latency measurements by being close to the infrastructure they monitor.

Related Concepts

Cloud-native Architecture
Microservices
Network Observability
Snmp Monitoring
Time-series Databases
Aiops
Mean Time To Repair (mttr)
Alert Correlation And Deduplication
Dynamic Service Discovery
Infrastructure As Code
Global Distributed Systems
Event-driven Architecture
Iot Sensor Monitoring
Webhook Integrations
Incident Management