¿Qué pinta tiene una buena observabilidad para un servicio del que eres responsable?

Deberías poder responder preguntas que no anticipaste. Eso significa logs estructurados con un id de traza en cada línea, métricas que cubran tasa, errores y duración más la saturación de tus recursos clave, y trazas distribuidas que sigan una petición entre servicios. Las alertas saltan por síntomas visibles para el usuario y atados a tus objetivos de nivel de servicio, los paneles parten de la experiencia del cliente, y todas las señales comparten etiquetas coherentes para poder pivotar entre ellas.

La prueba que uso es si puedo responder una pregunta en la que nadie pensó cuando se construyó el servicio, por ejemplo por qué las peticiones van lentas solo para un cliente en un endpoint. Para llegar ahí las tres señales tienen que estar conectadas. Cada línea de log es estructurada y lleva el id de traza, así que desde una traza lenta puedo saltar directo a los logs de esa petición en vez de buscar por marca de tiempo. Las métricas cubren tasa, errores y duración de cada endpoint como percentiles y no como medias, más la saturación de las cosas que de verdad se agotan: pools de conexiones, profundidad de cola, disco. Las trazas van muestreadas, pero siempre me quedo con los errores y con la cola lenta, porque la petición media no me enseña nada. Las alertas son la parte que la gente hace mal: alerto sobre síntomas que los clientes notan, atados al objetivo, no sobre que la CPU esté al ochenta por ciento. Y vigilo el coste, porque meter un id de usuario en una etiqueta de métrica es como conviertes una factura de doscientos en una de seis mil de la noche a la mañana; el detalle por usuario pertenece a las trazas y a los logs.