En esta guía (7 elementos)
Observability Guide
Observability Guide
MANDATORY FOR ALL AI AGENTS: Every new use case, adapter, or entry point MUST include appropriate observability instrumentation. Metrics MUST be added via decorator adapters (Chain of Responsibility pattern), NEVER inline in business logic. Tracing is provided automatically via Micrometer-OTEL bridge. Logging is correlated via MDC populated by the tracing bridge.
Project-agnostic: code samples use placeholder package
com.example.platform, service nameplatform-service. Replace with your project’s actual values when applying patterns.
This file is the index. Concrete patterns live in the four themed files below.
Companion guides:
- hexagonal-architecture.md — Chain of Responsibility / decorator pattern.
- security.md §10 — what NEVER to log (PII, secrets).
- adr.md — capture observability backend decisions (Prometheus vs DataDog vs NewRelic).
- arch-doc-spec.md §Observability — NFR + SLO section.
Companion command/agent: /arch-otel → arch-observability-injector (generates metrics decorator wrapping a port).
Themed Files
| File | Scope | LOC |
|---|---|---|
| obs-metrics.md | Dependency setup, Prometheus, custom metrics via decorator, naming conventions, tag conventions. | ~290 |
| obs-tracing.md | OpenTelemetry tracing, Micrometer bridge, automatic + custom spans, propagation, NewRelic options. | ~290 |
| obs-logging.md | SLF4J + Logback, JSON structured logging, OTEL trace-id correlation, logging rules. | ~150 |
| obs-recipes.md | Step-by-step recipe (port → use case → metrics adapter → chain → verify), dashboards, alerting, checklist. | ~320 |
1. Observability Architecture
The three pillars of observability are implemented as cross-cutting concerns, fully decoupled from business logic via the Chain of Responsibility (Decorator) pattern.
Three Pillars
| Pillar | Technology | Purpose |
|---|---|---|
| Metrics | Micrometer MeterRegistry |
Counters, timers, gauges for use cases and adapters |
| Traces | Micrometer Tracing Bridge to OTEL | Distributed tracing with OpenTelemetry export |
| Logs | SLF4J with MDC correlation | Structured logs enriched with trace-id and span-id |
Core Principle
Observability is a cross-cutting concern and MUST be handled via the decorator pattern (Chain of Responsibility). This is defined in hexagonal-architecture.md under the “Chain of Responsibility Pattern (Decorator Pattern)” section.
Hard rules:
- Business logic (use cases, domain) MUST NOT contain any metrics, tracing, or observability code.
- Metrics adapters live in the
metrics-publisherinfrastructure module. - Metrics adapters extend
MetricRecordedand implement the corresponding port interface. - The chain is wired in
UseCaseConfig(bootstrap module) viabuildChain(). - Tracing is automatic — the Micrometer-OTEL bridge instruments spans without code changes.
- Logs are correlated via MDC fields (
trace-id,span-id) populated by the tracing bridge. - Never log secrets, tokens, PII, or full request bodies. See security.md §10.
Architectural Flow
Entry Point (REST / Kafka) │ ▼[Metrics Adapter] @Order(10) → records timer, counter, error rate │ ▼[Cache Adapter] @Order(50) → optional cache lookup │ ▼[Use Case] @Order(100) → pure business logic (no observability code) │ ▼[Repository Chain] [Cache] @Order(50) [Metrics] @Order(10) [JDBC] @Order(100)All adapters in the chain are linked via ChainablePort<T>.setDelegate() and sorted by @Order in UseCaseConfig.buildChain().
Reading Order
Discovering observability (first read):
- This page — architecture + three pillars.
- obs-metrics.md — how custom metrics integrate via decorator.
- obs-tracing.md — how tracing flows automatically through.
- obs-logging.md — how logs correlate with traces.
- obs-recipes.md — apply to a new feature end-to-end.
Adding observability to a new feature:
- obs-recipes.md §9 — 5-step recipe.
- obs-metrics.md §5 — pick metric names + tags.
- obs-logging.md — structured log fields.
- obs-recipes.md §10 — verify with Prometheus + Grafana.
Production troubleshooting / on-call:
- obs-recipes.md §10 — key metrics, alerting rules, queries.
- obs-tracing.md §NewRelic NRQL — trace queries.
Pre-Merge Checklist (delta)
For PRs that add a new use case, adapter, or entry point:
- Metrics decorator implemented and registered in
buildChain()(see obs-recipes.md). - No
MeterRegistryinjected into use case or domain. - Metric names follow conventions (see obs-metrics.md §5).
- Tags use the documented allowlist (no unbounded cardinality — never
userIdas a tag). - Structured logs added at boundaries with
traceId,userId,tenantId(see obs-logging.md). - No PII / secrets in logs (see security.md §10).
- Dashboard updated in Grafana (or template generated) when a new SLO is introduced.
- Alerting rule reviewed for new critical metric.
Full checklist in obs-recipes.md.