División de límites de registros, indicadores y seguimiento.

La primera reacción de muchos equipos cuando intentan complementar la observabilidad es “conectar registros, indicadores y seguimiento”.

Esta frase suena correcta, pero el verdadero problema es el siguiente paso: las tres cosas están conectadas, pero los límites no están determinados, por lo que cada método limpia el trasero de los otros dos.

Los resultados suelen ser muy familiares: las etiquetas de los indicadores explotan, el muestreo de seguimiento aumenta por completo, el volumen de registros se duplica cada mes, las alarmas siguen siendo inexactas y la solución de problemas sigue dependiendo de la grep humana. No faltan herramientas, pero el sistema no se ha vuelto realmente más observable.

Mi opinión es: **Los límites de los registros, indicadores y seguimiento no deben trazarse por “el aspecto de los datos” sino por “qué decisión tomar a continuación”. **

• El indicador responde: si se debe abordar de inmediato y si el alcance del impacto es grande;
• Seguimiento de respuestas: ¿En qué sección del enlace probablemente esté atascado el problema?
• El registro responde: ¿Qué sucedió exactamente en ese fragmento de código en esa solicitud?

Los tres están en una relación de costos crecientes en la toma de decisiones. El indicador es el más económico y adecuado para un seguimiento continuo del mercado; El rastreo es más caro y adecuado para reducir el alcance; el tronco es el más pesado y apto para la restauración final de la escena.

Si el registro es responsable de las alarmas, el seguimiento es responsable de la auditoría y los indicadores son responsables de cada usuario, cada pedido y cada dimensión SQL, el sistema ciertamente podrá ejecutarse, pero el precio será muy honesto en almacenamiento, consulta, muestreo, control de cardinalidad y resolución de problemas humanos.

La verdadera primera decisión deberían ser los indicadores.

Cuando hay un problema en la línea, el primer paso suele ser “juzgar si vale la pena solucionarlo de inmediato”.

Este paso es el más adecuado para indicadores. Superficialmente, parece que el indicador es más avanzado, pero en realidad está más cerca y es el más barato.

Un buen sistema de indicadores debería responder las siguientes preguntas en decenas de segundos:

• ¿Está aumentando la tasa de error o se trata simplemente de ruido ocasional?
• ¿La variación del retardo es global o se concentra en una determinada interfaz?
• El impacto se produce en una máquina, en una sala de ordenadores o en toda la cadena de llamadas;
• ¿El problema acaba de ocurrir o lleva media hora?

Estos problemas esencialmente hacen lo mismo: **Usar agregación de información de bajo costo a cambio de juicios de acción de alto valor. **

Por lo tanto, el principio de diseño más importante de los indicadores es “también pueden apoyar la toma de decisiones después de la agregación”.

Muchos equipos crean malos indicadores al utilizar campos de alta cardinalidad que no deberían incluirse en los indicadores, como user_id, order_id, trace_id, URL completas y mensajes de error dinámicos. Esto es muy satisfactorio a corto plazo y parece que todo se puede hacer; a mediano plazo, la expansión del almacenamiento, la desaceleración de las consultas y las dimensiones de alarma comenzarán a descontrolarse; El resultado a largo plazo suele ser que el propio equipo tiene miedo de utilizar la plataforma de indicadores.

Los indicadores son adecuados para expresar tendencias y distribuciones en dimensiones estables, como nombres de interfaces, códigos de estado, salas de computadoras, servicios dependientes y aciertos de caché. El valor de estas dimensiones no es “restaurar una solicitud específica”, sino ayudar a determinar rápidamente si el problema ocurre en los clústeres.

Una vez que la pregunta que desea hacer es “¿Qué orden falló?”, ya no es una pregunta que el indicador deba responder por sí solo.

El valor del Tracing radica en acortar la ruta de posicionamiento.

El rastreo a menudo se malinterpreta como “registro más avanzado que registro”. Esto lo consumirá directamente.

En lo que Tracing es realmente bueno es en describir la ruta y la relación que requiere mucho tiempo de una solicitud entre servicios y componentes. Naturalmente, es adecuado para responder preguntas como esta:

• ¿La lentitud es causada por la puerta de enlace, la aplicación, la base de datos o dependencias externas?
• Un reintento, cuyo salto se amplifica;
• Si el P99 de una determinada interfaz es tan alto, ¿está relacionado con un determinado servicio descendente?
• Una solicitud anormal comienza a desviarse de la ruta normal después de pasar por qué servicios.

En otras palabras, **Tracing proporciona una estructura de enlace, no una escena completa. **

Por lo tanto, lo que más debería contener es información de ruta, etapa clave que requiere mucho tiempo y una pequeña cantidad de etiquetas que pueden ayudar a filtrar, en lugar de llenar completamente objetos comerciales, y mucho menos convertir cada variable local en un atributo de intervalo.

He visto a muchos equipos intentar convertirlo en una fuente unificada de verdad tan pronto como comienzan a rastrear: se debe colgar el texto SQL original, se debe colgar la entrada del usuario, se debe colgar el cuerpo completo de la respuesta y se deben colgar todos los parámetros de reintento. El resultado final es:

• El tamaño del tramo aumenta rápidamente y la frecuencia de muestreo se ve obligada a reducirse;
• Al consultar el enlace, el ruido es mucho mayor que la señal;
• Cuando llegamos al lugar del accidente, la solicitud de llave no fue entregada debido al muestreo;
• La gobernanza de datos sensibles comienza a convertirse en un nuevo coste de mantenimiento.

El momento más valioso para el seguimiento es cuando puede utilizar un vínculo para determinar rápidamente qué servicio, tramo y sección de registro deben verse en el siguiente salto.

Si es tan pesado que no se puede retener globalmente de manera estable, o es tan pesado que consultarlo aunque sea una vez es doloroso, entonces se ha cruzado el límite.

El registro no es el segundo sistema de indicadores, es el material final de recopilación de evidencia.

El tronco es el más fácil de juzgar mal porque parece que puede contener cualquier cosa.

De hecho, el registro es el más cercano a la escena. Cómo se tomó la rama, cómo se veían los parámetros, cuántas veces se reintentó, qué ruta de degradación se realizó y por qué esta vez se devolvió un resultado aparentemente exitoso pero semánticamente incorrecto a menudo solo se puede ver en los registros.

Pero precisamente porque tiene la entropía de información más alta, es el menos adecuado para la “observación continua global”.

El uso de registros como principal fuente de seguimiento tiene tres consecuencias comunes.

Primero, el costo de la consulta es alto. **Cada vez se extraen conclusiones temporales de los hechos originales, lo cual es lento y tiene poca estabilidad.

En segundo lugar, el sonido es extremadamente ruidoso. ** Cuando el volumen de registros es grande, el equipo naturalmente reducirá la impresión; una vez que se reduce la impresión, las ramas clave a menudo carecen de pruebas; Al final, todo el mundo irá y vendrá entre “demasiado para ver” y “muy poco para ver”.

En tercer lugar, puede inducir malos hábitos de ingeniería. ** Muchos desarrolladores crean una capa adicional de registro cuando encuentran un problema y, como resultado, el sistema se vuelve más ruidoso. Lo que realmente necesita complementarse son registros de eventos con límites claros, registros de errores con contexto e identificadores de solicitud que puedan asociarse, en lugar de más “métodos de entrada”, “métodos de salida”, “inicio de procesamiento” y “procesamiento completado”.

El lugar más apropiado para el registro es usar indicadores para determinar “realmente hay un problema aquí” y usar el rastreo para saber “el problema probablemente esté aquí” y luego usarlo para restaurar una solicitud específica.

En otras palabras, los registros deben tener fines forenses, no de patrullaje.

Una simple división del trabajo es más efectiva que “los tres elementos”

El enfoque que recomiendo es simple: primero defina la secuencia de resolución de problemas y luego defina los límites de la colección.

La solución de problemas en línea se puede dividir en tres pasos.

1. Primero utilizar indicadores para determinar si existen problemas sistémicos;
2. Luego utilice el rastreo para hacer converger el problema a la etapa de servicio y enlace;
3. Finalmente, use el registro para explicar por qué la solicitud fue así.

Si el diseño integrado no puede soportar esta secuencia, generalmente se debe a que las responsabilidades están mal asignadas.

La siguiente es una forma de escribir relativamente restringida:

func CreateOrder(ctx context.Context, req CreateOrderReq) error {
  start := time.Now()
  defer metrics.OrderCreateLatency.Observe(time.Since(start).Seconds())

  ctx, span := tracer.Start(ctx, "order.create")
  defer span.End()
  span.SetAttributes(
    attribute.String("payment_provider", req.Provider),
    attribute.Bool("has_coupon", req.CouponID != ""),
  )

  err := service.Create(ctx, req)
  if err != nil {
    metrics.OrderCreateErrors.WithLabelValues(classify(err)).Inc()
    logger.Error("create order failed",
      "request_id", requestid.FromContext(ctx),
      "provider", req.Provider,
      "err", err,
    )
    return err
  }
  return nil
}

Aquí hay tres límites que están intencionalmente restringidos.

• El indicador solo conserva dimensiones que aún tienen valor para la toma de decisiones después de la agregación, como la clasificación errónea;
• El rastreo solo bloquea algunos atributos que pueden ayudar a filtrar rutas, en lugar de todo el cuerpo de la solicitud;
• El registro solo registra el contexto clave en la ruta fallida y se garantiza que estará asociado con el enlace a través de request_id.

Este diseño no es sofisticado, pero resuelve un problema muy real: después de que ocurre un accidente, ¿puede el equipo abordar la respuesta desde el costo más bajo hasta el más alto, en lugar de sumergirse en los datos más costosos desde el principio? **

Un malentendido común: entender la “observabilidad unificada” como “agregar todos los datos”

Ahora muchas plataformas hablan de observación unificada. Esto no tiene nada de malo en sí mismo, el problema reside en la forma en que se implementa.

Algunos equipos entienden la unificación como “todos los datos ingresan a una plataforma, todos los campos están conectados entre sí y es mejor resolver todos los problemas con una sola consulta”. Esta idea es tentadora porque parece eliminar los límites de las herramientas; pero en ingeniería, a menudo elimina los límites de costos.

La dirección correcta para la unificación es conectarlos con baja fricción.

Por ejemplo:

• Las alarmas del indicador pueden saltar directamente a los servicios y ventanas de tiempo relevantes;
• el rastreo puede encontrar el registro correspondiente según request_id o el código de error;
• Los registros pueden brindar contexto de seguimiento en lugar de funcionar de forma independiente.

Esto se llama China Unicom, no uso mixto.

El verdadero peligro es que todas las preguntas sólo puedan responderse con la capa más pesada de datos.

Contraejemplos y límites: no todos los sistemas requieren un conjunto completo de tres piezas

Admita también que en algunas escenas no es necesario contar los límites de forma tan completa.

Para herramientas internas de bajo QPS, scripts por lotes independientes y tareas fuera de línea muy estables, los registros pueden ser suficientes; para servicios con enlaces de solicitud cortos y dependencias simples, los beneficios del rastreo pueden no ser tan altos como se esperaba; Para ciertos escenarios de auditoría sujetos a restricciones de cumplimiento, no debe esperar que los registros de seguimiento o de aplicaciones ordinarias sirvan como registros de auditoría formales.

Por eso este artículo dice: **Mientras decidas hacer tres cosas, no dejes que se reemplacen entre sí. **

Cuanto más complejo sea el sistema, más responsabilidades habrá que limitar. De lo contrario, lo que se elimina hoy son los límites del diseño y lo que se agrega mañana es la factura de la plataforma, el tiempo de resolución de problemas y la carga cognitiva del equipo.

Resumen

Lo más aterrador de la observabilidad es que cada capa quiere responder a todas las preguntas.

Los indicadores deberían permitirle decidir si actuar lo más rápido posible, el rastreo debería permitirle decidir dónde buscar primero lo antes posible y los registros deberían permitirle saber qué sucedió lo antes posible.

Si el orden de estas tres acciones es incorrecto, no importa cuán completas sean, solo enterrará más profundamente el costo de la resolución de problemas.