Observability Guidelines

by mindrally97184105b5daNo license269 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 5 weeks ago

Observability guidelines for distributed systems using OpenTelemetry, tracing, metrics, and structured logging

Instructions onlyDevOps & Cloud
AI-generated overview

Guidelines for adding OpenTelemetry tracing, metrics, structured logging, and alerting to distributed systems.

What it does
Provides a set of observability guidelines for distributed systems and microservices, covering OpenTelemetry integration, distributed tracing, metrics collection, structured logging, correlation and context propagation, dashboards and alerting, instrumentation practices, and production sampling and retention considerations. It also lists architecture patterns such as Clean Architecture and domain-driven design. It is an instruction-only reference and produces no files or scripts.
When to use it
Use when instrumenting or reviewing a distributed system or microservice for observability. It suits teams standardizing tracing, metrics, logging, and alerting conventions. It is also useful when planning sampling, dashboards, and runbooks for production services.
Requirements
No tools, packages, or credentials are required; it is instructions only and ships no scripts. Applying the guidance assumes systems that can use OpenTelemetry and related backends such as an OpenTelemetry Collector, Jaeger, or Prometheus.

Observability Guidelines

Apply these observability principles to ensure comprehensive visibility into distributed systems and microservices.

Core Observability Principles

  • Guide the development of idiomatic, maintainable, and high-performance code with built-in observability
  • Enforce modular design and separation of concerns through Clean Architecture
  • Promote test-driven development and robust observability from the start

OpenTelemetry Integration

  • Use OpenTelemetry for distributed tracing, metrics, and structured logging
  • Start and propagate tracing spans across all service boundaries
  • Use otel.Tracer for creating spans and otel.Meter for collecting metrics
  • Export data to OpenTelemetry Collector, Jaeger, or Prometheus
  • Configure appropriate sampling rates for production environments

Distributed Tracing

  • Trace all incoming requests and propagate context through internal calls
  • Use middleware to instrument HTTP and gRPC endpoints automatically
  • Include trace context in all downstream service calls
  • Create child spans for significant operations within a service
  • Add relevant attributes to spans for debugging and analysis

Metrics Collection

Monitor these key metrics across all services:

  • Request latency: Track p50, p90, p95, and p99 percentiles
  • Throughput: Measure requests per second by endpoint
  • Error rate: Track 4xx and 5xx responses separately
  • Resource usage: Monitor CPU, memory, disk, and network utilization
  • Custom business metrics: Track domain-specific KPIs

Structured Logging

  • Include unique request IDs and trace context in all logs for correlation
  • Use structured logging formats (JSON) for machine parseability
  • Include relevant context: timestamp, service name, trace ID, span ID
  • Log at appropriate levels: DEBUG, INFO, WARN, ERROR
  • Avoid logging sensitive information (PII, credentials)

Architecture Patterns

  • Apply Clean Architecture with handlers, services, repositories, and domain models
  • Use domain-driven design principles for clear boundaries
  • Prioritize interface-driven development with explicit dependency injection
  • Prefer composition over inheritance; favor small, purpose-specific interfaces

Correlation and Context

  • Propagate context through the entire request lifecycle
  • Use correlation IDs for request tracking across services
  • Include service version and deployment information in telemetry
  • Tag traces with relevant business context for filtering
  • Enable trace-to-log and log-to-trace correlation

Alerting and Dashboards

  • Create dashboards for service health and business metrics
  • Set up alerts based on SLOs and error budgets
  • Use anomaly detection for proactive issue identification
  • Document runbooks for common alert scenarios
  • Review and tune alerts regularly to reduce noise

Instrumentation Best Practices

  • Instrument at service boundaries (entry/exit points)
  • Add custom spans for database operations and external calls
  • Include relevant attributes (user ID, request type, etc.)
  • Avoid over-instrumentation that creates noise
  • Use semantic conventions for consistent attribute naming

Production Considerations

  • Configure appropriate sampling rates to balance visibility and cost
  • Use head-based sampling for consistent trace capture
  • Implement tail-based sampling for capturing errors
  • Set retention policies based on debugging needs
  • Monitor observability infrastructure health

Source and attribution

Source:mindrally/skillsinobservability-guidelinesat commit9718410

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal