Architecture
An observability architecture diagram implementing the three pillars (metrics, traces, logs) with OpenTelemetry SDK instrumentation, OTLP collector pipeline, Prometheus, Jaeger, and Loki backends, Grafana dashboards, SLO/SLI tracking, and PagerDuty alerting integration. This template provides a complete observability stack reference showing how telemetry data flows from application instrumentation through collection, storage, visualization, and incident response. Essential for SRE teams building production monitoring infrastructure.
Application { # Application Services
n1: rectangle label:"Service A"
n2: rectangle label:"Service B"
n3: rectangle label:"Service C"
n4: rectangle label:"OpenTelemetry SDK"
n1.handle(bottom) -> n4.handle(top) [label="Instrument"]
n2.handle(bottom) -> n4.handle(top) [label="Instrument"]
n3.handle(bottom) -> n4.handle(top) [label="Instrument"]
n4.handle(bottom) -> Collector.n5.handle(top) [label="OTLP Export"]
}
Collector { # OpenTelemetry Collector
n5: rectangle label:"Receive Telemetry"
n6: rectangle label:"Process and Batch"
n7: rectangle label:"Export Metrics"
n8: rectangle label:"Export Traces"
n9: rectangle label:"Export Logs"
n5.handle(right) -> n6.handle(left) [label="Pipeline"]
n6.handle(right) -> n7.handle(left) [label="Metrics"]
n6.handle(bottom) -> n8.handle(top) [label="Traces"]
n6.handle(bottom) -> n9.handle(top) [label="Logs"]
n7.handle(bottom) -> Backends.n10.handle(top) [label="Prometheus"]
n8.handle(bottom) -> Backends.n11.handle(top) [label="Jaeger"]
n9.handle(bottom) -> Backends.n12.handle(top) [label="Loki"]
}
Backends { # Observability Backends
n10: rectangle label:"Prometheus (Metrics)"
n11: rectangle label:"Jaeger (Distributed Traces)"
n12: rectangle label:"Loki (Log Aggregation)"
n13: rectangle label:"Alertmanager"
n10.handle(right) -> n13.handle(left) [label="Alert Rules"]
n10.handle(bottom) -> Visualization.n14.handle(top) [label="PromQL"]
n11.handle(bottom) -> Visualization.n14.handle(top) [label="Trace ID"]
n12.handle(bottom) -> Visualization.n14.handle(top) [label="LogQL"]
}
Visualization { # Visualization & Alerting
n14: rectangle label:"Grafana Dashboard"
n15: rectangle label:"SLO/SLI Tracking"
n16: rectangle label:"Incident Response"
n17: rectangle label:"PagerDuty / Slack"
n14.handle(right) -> n15.handle(left) [label="SLO Burn Rate"]
n15.handle(right) -> n16.handle(left) [label="SLO Breach"]
n16.handle(right) -> n17.handle(left) [label="Alert"]
n13.handle(bottom) -> Visualization.n17.handle(top) [label="Fire Alert"]
}
Monitoring alone (dashboards and alerts) tells you something is wrong but not why. The three pillars of observability—metrics, traces, and logs—provide the complete picture: metrics detect anomalies, traces pinpoint which service in a request chain is slow, and logs reveal the specific error details.
Vendor-specific solutions (Datadog, New Relic) provide all-in-one observability but at significant cost. ELK stack handles logs but not traces natively. This template shows the open-source observability stack with OpenTelemetry.
| Template Name | Observability Three Pillars Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Architecture
A sidecar pattern architecture diagram showing Envoy proxy, log collector, and config watcher sidecars running alongside application containers in a Kubernetes pod, with a control plane managing configuration. This template demonstrates how auxiliary concerns like logging, monitoring, and configuration are deployed as co-located containers. Foundational for teams adopting cloud-native container orchestration patterns.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.