A time-series database stores timestamped measurements and optimizes retrieval of numerical data points over time. In observability, it provides the metrics storage layer for historical analysis, trend identification, and troubleshooting. section 5.1.4
The database handles metrics separately from log and trace stores: logs preserve detailed system events, while traces reconstruct transaction flows across services. This separation lets each data type use an appropriate ingestion and query path. section 5.1.4
A typical observability path uses the database as one stage in a broader pipeline:
- Ingestion APIs validate, format, and receive metrics from monitored systems. section 5.1.4
- An ingestion service consumes queued data and formats it for storage and analytics. section 5.3.1
- The storage service routes metrics to the time-series backend and connects them to dashboard queries. section 5.3.1
Prometheus in a Kubernetes observability platform
Prometheus stores high-resolution metrics and can use block storage managed through Persistent Volume Claims, preserving performance data across container restarts or migrations. Grafana queries Prometheus to provide visualization and alerting. section 5.3.1
Table 5.1 Tools used by Epetech across the eight different axes of observability
| Axis |
Tool Used |
| Infrastructure |
Prometheus (metrics collection) + Grafana (Dashboarding) |
| Application |
DataDog |
| Service Health |
Pingdom |
| Incident Response |
PagerDuty |
| Portfolio |
JIRA |
| Platform |
DataDog |
| Cloud Costs |
IBM Kubecost |
| Business |
Tableau |
Compare Prometheus and Grafana with tools assigned to application, service-health, incident-response, cost, and business observability. section 5.1.4
