Architecture
Diagramme d'architecture d'observabilité implémentant les trois piliers (métriques, traces, logs) avec instrumentation SDK OpenTelemetry, pipeline de collecteur OTLP, backends Prometheus, Jaeger et Loki, tableaux de bord Grafana, suivi SLO/SLI et intégration d'alertes PagerDuty. Ce modèle fournit une référence complète de pile d'observabilité montrant comment les données de télémétrie circulent de l'instrumentation applicative à la collecte, au stockage, à la visualisation et à la réponse aux incidents. Essentiel pour les équipes SRE construisant une infrastructure de surveillance de production.
Code FlowZap complet
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"]
}
Pourquoi ce workflow ?
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.
Comment ça fonctionne
- Step 1: Application services are instrumented with the OpenTelemetry SDK.
- Step 2: Telemetry data (metrics, traces, logs) is exported via OTLP to the OpenTelemetry Collector.
- Step 3: The collector processes, batches, and routes data to specialized backends.
- Step 4: Prometheus stores metrics, Jaeger stores distributed traces, and Loki stores logs.
- Step 5: Grafana dashboards provide unified visualization across all three pillars.
- Step 6: SLO/SLI tracking and Alertmanager trigger PagerDuty alerts when error budgets are consumed.
Alternatives
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.
Key Facts
| Template Name | Architecture d'observabilité des trois piliers |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture du pattern sidecar montrant le proxy Envoy, le collecteur de logs et le watcher de configuration fonctionnant aux côtés des conteneurs applicatifs dans un pod Kubernetes, avec un plan de contrôle gérant la configuration. Ce modèle démontre comment les préoccupations auxiliaires comme la journalisation, la surveillance et la configuration sont déployées en tant que conteneurs co-localisés. Fondamental pour les équipes adoptant des patterns d'orchestration de conteneurs cloud-native.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.