Useful observability: start with a concrete question
Connecting metrics, logs and traces to investigate failures without turning telemetry into noise.
Before installing another dashboard, I would ask what we need to understand: did errors increase, which part of a request became slow, and what changed around the incident? A tool helps when instrumentation can answer those questions.
Three complementary signals
OpenTelemetry provides mechanisms to collect, process and export signals. For a small service, I would start with request and error metrics, traces of key operations and structured logs with enough context for investigation.
These signals contain different information. Metrics reveal patterns, a trace describes an operation’s path, and a log records an event with context. Their value increases when they can be connected during an investigation.
A Collector as a control point
A Collector can receive and process telemetry before exporting it. In this portfolio’s design, I would use it for filtering, batching and shared export configuration. Choosing the storage backend remains a separate decision.
It also introduces an operational component that needs configuration, limits and monitoring. A central component should not become an unobserved point of failure.
Fewer labels, better questions
I would avoid user or request identifiers as metric labels. Besides exposing information, uncontrolled cardinality complicates operations and cost. Choose attributes based on concrete questions, with explicit rules about information removed before export.
Test the investigation path
The proposed exercise introduces a slow dependency in a disposable environment. Starting from a degradation signal, find an affected trace and related logs. Then remove the fault and check recovery.
Document which evidence helped and what was missing. An attractive dashboard does not prove that a team can diagnose a problem.
The next improvement
With an instrumented service and repeatable exercises, we could measure diagnosis time. Until then, the portfolio case describes architecture and a validation plan without claiming real results.
References
Antes de instalar otro dashboard preguntaría qué necesitamos entender: ¿aumentaron los errores?, ¿qué parte de una solicitud se volvió lenta?, ¿qué cambió alrededor del incidente? Una herramienta ayuda cuando la instrumentación permite responder esas preguntas.
Tres señales que se complementan
OpenTelemetry proporciona mecanismos para recoger, procesar y exportar señales. Para un servicio pequeño empezaría con métricas de solicitudes y errores, trazas de las operaciones principales y logs estructurados con contexto suficiente para investigar.
No son copias de la misma información. Las métricas permiten observar patrones; una traza describe el recorrido de una operación; un log registra un evento con contexto. Su valor crece cuando se pueden relacionar durante una investigación.
Un Collector como punto de control
Un Collector puede recibir y procesar telemetría antes de exportarla. En el diseño de este portafolio lo usaría para aplicar filtros, lotes y una configuración compartida de exportación. El backend que almacena los datos sigue siendo una decisión independiente.
Eso también introduce una pieza operativa que necesita configuración, límites y observación. Un componente central no debería convertirse en un punto de fallo que nadie supervisa.
Menos etiquetas, mejores preguntas
Evitaría usar identificadores de usuario o de solicitud como etiquetas de métricas. Además del riesgo de exponer información, una cardinalidad sin control complica la operación y el costo. Elegiría atributos a partir de preguntas concretas, con reglas explícitas sobre qué información se elimina antes de exportar.
Probar el recorrido de investigación
El ejercicio propuesto introduce una dependencia lenta en un entorno desechable. A partir de una señal de degradación se busca una traza afectada y los logs relacionados. Después se retira el fallo y se comprueba la recuperación.
Documentaría qué evidencia ayudó y cuál faltó. Un dashboard visualmente atractivo no prueba que el equipo pueda diagnosticar un problema.
La próxima mejora
Con un servicio instrumentado y ejercicios repetibles podríamos medir el tiempo de diagnóstico. Hasta entonces, el caso del portafolio describe la arquitectura y el plan de validación, sin atribuirle resultados reales.