Saltar al contenido
Telemetry
Explorar documentación
GuíasActualizado el 29 de julio de 2026Revisado por los equipos editorial y de producto de Telemetry3 min de lectura

Usa esta documentación con tu agente de programación

Abra un paquete de mensajes enfocados para Claude Code, Codex, Cursor u otro agente de codificación, luego adáptelo al flujo de trabajo que se describe aquí.

En esta página
  1. Definir el contrato del evento.
  2. Calcular el cumplimiento de disponibilidad
  3. Monitorear la tasa de grabación
  4. Agregue SLI de latencia y flujo de trabajo
  5. Cree el panel y la ruta de alerta
  6. Validar antes de paginar

Monitoreo de presupuesto de errores, SLI y SLO con SQL

Un indicador de nivel de servicio (SLI) mide un resultado de la experiencia de los usuarios. Un objetivo de nivel de servicio (SLO) establece una meta para ese indicador durante un período definido. Un presupuesto de error es la cantidad de falla permitida que implica el objetivo.

Comience con el resultado de una aplicación limitada, como una solicitud API, pago, trabajo o entrega de webhook. La disponibilidad de la infraestructura es un contexto útil, pero un host en buen estado no prueba que el flujo de trabajo del cliente haya tenido éxito.

Definir el contrato del evento.

Para un SLI de disponibilidad basado en solicitudes, emita un evento de terminal con:

  • event_id;
  • timestamp_utc;
  • service y route_template;
  • status y status_code;
  • latency_ms;
  • environment y release;
  • un error_type controlado;
  • un account_id seguro opcional para análisis de impacto.

Elegibilidad del documento. Los controles de estado, el tráfico sintético, las solicitudes canceladas y los errores esperados del cliente pueden o no pertenecer al denominador. La decisión debe ser coherente en toda la consulta, el panel y la alerta.

Calcular el cumplimiento de disponibilidad

El Disponibilidad de SLO Receta SQL separa las solicitudes elegibles, las solicitudes buenas, las solicitudes malas y el porcentaje de cumplimiento. Úselo con una ventana de observación completa y una definición de buen evento revisada.

Para un objetivo del 99,9 %, la fracción defectuosa permitida es 0.001. Un presupuesto de error medido en solicitudes es:

eligible_requests * (1 - objective)

Mantenga los recuentos junto a los porcentajes. Una tasa de fracaso del 50 % en dos solicitudes y una tasa de fracaso del 2 % en un millón de solicitudes requieren una interpretación diferente.

Monitorear la tasa de grabación

La tasa de quema compara la fracción de eventos negativos observada con la fracción de eventos incorrectos permitida. Una tasa de consumo de 1 consume presupuesto exactamente al ritmo planificado. Una velocidad de combustión superior a 1 lo consume demasiado rápido.

El receta de quema de presupuesto de error calcula el valor en períodos de tiempo. Empareje una ventana corta, que detecta incidentes rápidamente, con una ventana más larga que evita que un grupo ruidoso llame al equipo.

No alerte sobre el período de tiempo incompleto más reciente a menos que la consulta tenga en cuenta explícitamente datos parciales. Requerir un volumen mínimo elegible y puntos de evaluación sostenidos antes de activarse.

Agregue SLI de latencia y flujo de trabajo

La disponibilidad es solo una propiedad visible para el usuario. Una solicitud puede tener éxito después de un retraso inaceptable. Defina un SLI de latencia como la fracción de solicitudes elegibles por debajo de un umbral revisado, o inspeccione p95 y p99 con el Receta percentil de latencia API.

Para trabajos en segundo plano y webhooks, defina el éxito en torno al resultado comercial del terminal en lugar de un intento individual. Un reintento recuperado puede consumir el presupuesto de latencia sin contar como una falla del terminal. Mantenga disponibles los diagnósticos a nivel de intento sin inflar el denominador SLI.

Cree el panel y la ruta de alerta

Coloque estas vistas juntas:

  1. Volumen de solicitudes elegibles y actualización de los datos.
  2. Cumplimiento de SLO para toda la ventana móvil.
  3. Tasa de combustión de ventana corta y larga.
  4. Desglose de fallas por ruta, versión y tipo de error.
  5. Una tabla de eventos recientes para la investigación del impacto en el cliente.

Agregue notas operativas que nombren el propietario, el objetivo, el denominador, las exclusiones y la acción de respuesta. Siga el guía de alerta para el comportamiento de evaluación y el guía de respuesta a incidentes para el flujo de investigación.

Validar antes de paginar

Vuelva a reproducir un encuentro con éxitos conocidos, fracasos, eventos excluidos y un segmento más nuevo incompleto. Confirme el recuento exacto de elegibles, las fallas permitidas, el cumplimiento y la tasa de quemado. Luego observe la alerta sin notificaciones antes de adjuntar una respuesta de guardia.

Función relacionada del producto

Ejecute DataFusion SQL de solo lectura sobre tablas de eventos estructurados y reutilice el resultado.

Responsabilidad y referencias técnicas

El equipo editorial de Telemetry es responsable de esta explicación; el equipo de producto revisa el comportamiento, los ejemplos y las limitaciones.

Consultar los criterios editoriales