Saltar al contenido
Telemetry
Paneles compartidos

Mantenga las señales operativas y de productos legibles en una vista compartida

Combine resultados de Explore, gráficos de consultas SQL, tablas de resultados, encabezados de sección y notas explicativas en paneles que los agentes de programación pueden generar y los humanos pueden perfeccionar.

Resultados

  • Ofrezca a ingeniería, productos, soporte y fundadores una visión común del flujo de trabajo.
  • Coloque definiciones y notas operativas junto a los cuadros que explican.
  • Cree o actualice paneles a través de la API cuando la automatización sea dueña del primer paso.

como funciona

Un flujo de trabajo revisable desde la señal hasta la decisión

1

Liderar con la decisión

Un panel debe responder a un pequeño conjunto de preguntas relacionadas. Comience con la métrica primaria de salud o de resultados en lugar de con todos los gráficos disponibles.

2

Colocar diagnóstico después de la detección.

Coloque primero las vistas de tendencias y umbrales, luego agregue desgloses y tablas de eventos recientes que expliquen un cambio.

3

Propiedad del documento y respuesta

Utilice encabezados y notas para definir la métrica, el rango esperado, el propietario y el siguiente paso. El contexto hace que el panel sea utilizable durante un incidente.

Creación de un panel Telemetry compartido

Una captura de producto real que muestra la disposición de los gráficos y la edición colaborativa del panel.

Límites

Lo que esto no reemplaza

  • Los paneles resumen las consultas revisadas; no hacen que una definición de métrica inestable sea confiable.
  • Un tablero compartido debe centrarse en un pequeño conjunto de decisiones en lugar de convertirse en un inventario de todos los gráficos disponibles.
  • Los paneles Telemetry no reemplazan un libro de ejecución de incidentes, un modelo de propiedad ni un sistema duradero de fuente de verdad para los informes financieros.

Ruta de prueba inspeccionable

Del contrato de evento a una respuesta visible

Este ejemplo utiliza un esquema declarado, SQL de solo lectura y resultados sintéticos deterministas. Demuestra el flujo de trabajo sin presentar datos de muestra como punto de referencia del cliente.

1. Contrato de evento

una fila en api_requests, con los tipos utilizados por la consulta explícitos.

timestamp_utc
Timestamp
route_template
Utf8
status_code
Int64
latency_ms
Float64
Explorar contratos de eventos

2. SQL de solo lectura

¿Qué rutas API tienen la tasa de error 5xx significativa más alta?

SELECT
  route_template,
  COUNT(*) AS requests,
  SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
  100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
HAVING COUNT(*) >= 20
ORDER BY error_rate_pct DESC
LIMIT 10;

3. Resultado sintético

La ruta de pago es el riesgo de confiabilidad más claro, aunque la búsqueda tiene más tráfico total.

route_templaterequestserrores
/api/checkout255
/api/search251
/api/profile200
Inspeccionar consultas, resultados y advertencias

Capacidades

Que esta incluido

Explorar y widgets de consulta SQL
Resultados de línea, barra, dispersión, área apilada y tabla
Títulos de sección y notas de rebajas para contexto
Arrastre, cambie el tamaño, cambie el nombre y comparta paneles de control con ámbito de equipo
Panel de control para crear, actualizar, enumerar y eliminar API

Ver el análisis

Recetas SQL que utilizan esta capacidad

Casos de clientes

Cómo utilizan los equipos este flujo de trabajo

Capacidades relacionadas

Continuar el flujo de trabajo desde el evento hasta la decisión

Comience con un flujo de trabajo de producción

Utilice un mensaje enfocado, envíe eventos sintéticos y verifique la primera consulta útil antes de ampliar la cobertura.