Skip to main content
Flowker emite trazas, métricas y logs estructurados utilizando el estándar OpenTelemetry. Esta guía explica qué está disponible, cómo habilitarlo y cómo interpretar los datos en tu stack de observabilidad.

Descripción general


La telemetría de Flowker se basa en tres señales: Todas las señales se exportan via OTLP (OpenTelemetry Protocol) a un collector de tu elección.

Configuración


La telemetría se controla mediante variables de entorno.
Si ENABLE_TELEMETRY=true está configurado sin OTEL_EXPORTER_OTLP_ENDPOINT, Flowker no podrá iniciarse.

Trazabilidad distribuida


Cada solicitud HTTP y operación interna crea un span de OpenTelemetry. Los spans se propagan a través de toda la cadena de ejecución, por lo que una sola ejecución de workflow produce una traza conectada desde el handler HTTP hasta los pasos individuales del executor.

Convención de nombres de spans

Los spans siguen un patrón <layer>.<resource>.<operation>: Spans de ejecución Spans de comandos de workflow Spans de configuración de executor Spans de configuración de provider Spans de consulta
En Grafana Tempo, busca por nombre de servicio (flowker) y filtra por nombre de span para aislar operaciones específicas. Usa command.execution.execute como punto de entrada para ver una traza completa de workflow.

Métricas


Flowker expone métricas HTTP y del sistema automáticamente a través del SDK de OpenTelemetry. No se necesita configuración adicional más allá de habilitar la telemetría.

Métricas HTTP (via otelfiber)

Recopiladas por ruta mediante el middleware otelfiber: Cada métrica incluye las etiquetas: http.method, http.route, http.status_code.

Métricas del sistema

Buckets de histograma

Los histogramas de latencia utilizan los siguientes límites de bucket (en segundos):
Flowker no expone un endpoint de scrape de Prometheus (/metrics) directamente. Las métricas se exportan via OTLP a tu collector, que luego las envía a Prometheus. Configura tu collector OTLP para incluir un exportador prometheusremotewrite.

Logging estructurado


Flowker utiliza logging JSON estructurado via Zap. Cada entrada de log se enriquece con campos contextuales que pueden ser indexados y consultados en Loki.

Referencia de campos de log

Niveles de log

Configura la variable de entorno LOG_LEVEL para controlar la verbosidad.

Ejemplos de entradas de log

Ejecución de workflow iniciada:
Recuperación de ejecuciones incompletas:
Ejecución fallida:

Sondas de salud


Flowker expone sondas de liveness y readiness compatibles con Kubernetes para monitoreo operacional. Liveness indica si el proceso está en ejecución; readiness indica si las dependencias (notablemente la base de datos) están accesibles. Configura ambas a nivel del cluster, como parte de tus manifiestos de despliegue, para que la orquestación pueda reiniciar pods no saludables y remover instancias degradadas de los balanceadores de carga.

Dashboards de Grafana


La telemetría de Flowker se integra directamente con el stack de observabilidad de Lerian. Los dashboards preconfigurados están disponibles a través de la instancia de Grafana administrada por Lerian.

Paneles recomendados

Throughput de solicitudes
  • Query: sum(rate(http_server_duration_count{service_name="flowker"}[5m])) by (http_route)
  • Muestra solicitudes por segundo, desglosadas por ruta
Latencia P95
  • Query: histogram_quantile(0.95, sum(rate(http_server_duration_bucket{service_name="flowker"}[5m])) by (le, http_route))
  • Muestra el tiempo de respuesta del percentil 95 por ruta
Tasa de errores
  • Query: sum(rate(http_server_duration_count{service_name="flowker", http_status_code=~"5.."}[5m])) / sum(rate(http_server_duration_count{service_name="flowker"}[5m]))
  • Muestra la proporción de respuestas 5xx
Ejecuciones activas (via logs)
  • Loki query: {service_name="flowker"} |= "Starting workflow execution" | count_over_time([1m])
Para la configuración completa del stack de observabilidad, consulta Plataforma → Observabilidad.