Tools tagged with "Monitoring"

Monitoring covers repositories for observing system health, performance, and errors: metrics collection and storage (Prometheus), visualization dashboards (Grafana), error tracking (Sentry, GlitchTip), distributed tracing (Jaeger, Zipkin), and the broader OpenTelemetry ecosystem for instrumenting applications in a vendor-neutral way.

These tools typically split into three signal types: metrics, logs, and traces. Prometheus is the standard for pulling and storing time-series metrics, usually paired with Grafana for building dashboards and alerts on top of that data. Error tracking tools like Sentry capture exceptions with stack traces and context at the moment they happen, which serves a different purpose than metrics: metrics show trends over time, while error trackers show the specifics of individual failures. Distributed tracing tools like Jaeger follow a single request as it moves across multiple services, which becomes necessary once an application is split into more than a few services and a slow request could originate anywhere in the chain.

OpenTelemetry has become the common instrumentation layer across this tag, since it lets an application emit metrics, logs, and traces in a standard format that many backends (Prometheus, Jaeger, and commercial vendors) can consume, reducing lock-in to any single monitoring tool.

Self-hosting monitoring infrastructure adds its own operational burden, since the monitoring stack needs to stay up when the systems it watches go down, which is why some teams run a minimal self-hosted stack and offload long-term storage or alerting to a managed backend.

Factors to weigh:

• Which signal types (metrics, logs, traces) are actually needed
• Storage and retention costs for high-cardinality metrics
• Alerting capabilities and integration with on-call tools
• OpenTelemetry compatibility for future backend flexibility
• Operational overhead of self-hosting versus a managed option