Monitoreo

Métricas

Las métricas se emiten desde Horizon a través de HTTP en el formato de exposición de texto basado en de facto. Las métricas se publican en la ruta privada /metrics del puerto de administración de Horizon, que es un servicio opcional que debe ser iniciado y se vinculará por el proceso de Horizon en la red de bucle local de la máquina anfitriona (localhost o 127.0.0.1). Para habilitar el puerto de administración, añade el parámetro de configuración del entorno ADMIN_PORT=XXXXX, el endpoint de métricas será accesible en la máquina anfitriona como localhost:<ADMIN_PORT>/metrics. Puedes verificar esto apuntando cualquier navegador que pueda acceder a esta dirección, mostrará todas las claves de métricas.

Exportando

Una vez que se habilite el puerto de administración, el endpoint de métricas de Horizon puede ser 'scrapeado' por infraestructura de monitoreo externa. Dado que la salida de las métricas está codificada en un formato de texto estándar, será compatible para su uso con muchos tipos de infraestructura de monitoreo que interoperan con el mismo formato estándar.

En el caso de Horizon, las métricas se publican en el puerto HTTP de administración que está vinculado a la interfaz de red de bucle local de la máquina anfitriona (127.0.0.1), por lo que los sistemas o servicios de monitoreo externos no pueden acceder al puerto directamente. Para exponer las métricas de manera segura, recomendamos seguir el patrón del exportador, que es una estrategia común de 'scraping' de métricas.

Un ejemplo del mundo real para exportar desde una instalación de Horizon en hardware (Horizon ha sido instalado directamente en un sistema operativo), usa FluentBit y el exportador de Prometheus en la misma máquina anfitriona donde se ejecuta Horizon. FluentBit realizará un simple reenvío de puertos en la máquina anfitriona. Configura la entrada para que sea localhost:<ADMIN_PORT>/metrics de Horizon y la salida para que represente la máquina anfitriona y el puerto que representan la interfaz de red y el puerto en la máquina anfitriona, y luego configura tu infraestructura de monitoreo para 'scrapear' esa dirección de la máquina anfitriona.

En entornos orquestados por contenedores como Kubernetes, puedes usar la misma estrategia de exportador. Asumimos que ya tienes una implementación de infraestructura de métricas como Prometheus y Grafana configurada en el clúster a través del Operador de Prometheus, y solo necesitarás configurar esa infraestructura para scrapear el pod de Horizon basado en el ADMIN_PORT.

Modelo de datos

Hay numerosas claves de métricas de aplicación emitidas por Horizon en tiempo de ejecución, codificadas en cuatro tipos de formatos de exposición: contador, gauge, histograma, resumen. Cada clave se califica además con etiquetas para mayor granularidad. Para resumir, podemos resaltar los agrupamientos de claves de métricas por función común denotada en el prefijo de su nombre:

• go_: rendimiento específico de golang en tiempo de ejecución
• horizon_txsub_: atributos del subsistema de envío de transacciones de Horizon si está habilitado.
• horizon_stellar_core_: atributos de tiempo de ejecución de la red Stellar reportados por el núcleo cautivo.
• horizon_order_book_: atributos de tiempo de ejecución del libro de órdenes en memoria mantenido por Horizon de la red Stellar actual
• horizon_log_: contadores de cuántos mensajes de registro se imprimieron en cada nivel de severidad
• horizon_ingest_: mediciones de rendimiento y aspectos de estado del subsistema de ingestión interna de Horizon
• horizon_http_: estadísticas y mediciones del servicio API HTTP de Horizon, todos los aspectos de la carga y tiempos de solicitudes/respuestas.
• horizon_history_: estadísticas sobre los ledgers históricos ingeridos por Horizon
• horizon_db_: mediciones sobre el rendimiento de la base de datos, tiempos de consulta por endpoints, estadísticas de agrupamiento
• process_: mediciones de computación genérica en la máquina host

Y para cada clave, habrá una posibilidad de 0 o más etiquetas, el formato de salida serializada (exposición) sigue esta plantilla:

<metrics_key_name>{label_1="value",label_2="value",,,} <value>

En lugar de enumerar todas las claves de métricas individuales en la documentación, ya que cambian con frecuencia, se recomienda realizar un HTTP GET contra el endpoint de métricas de Horizon, localhost:<ADMIN_PORT>/metrics, utilizando cualquier cliente HTTP (navegador, curl, wget, etc.) y la respuesta tendrá las claves de métricas y meta información adicional sobre cada clave de métrica para descripción y tipo (contador, gauge, histograma, resumen), como ejemplo para una clave, horizon_http_requests_duration_seconds:

# HELP horizon_http_requests_duration_seconds HTTP requests durations, sliding window = 10m
# TYPE horizon_http_requests_duration_seconds summary
horizon_http_requests_duration_seconds{method="GET",route="/",status="200",streaming="false",quantile="0.5"} 0.000186958
horizon_http_requests_duration_seconds{method="GET",route="/",status="200",streaming="false",quantile="0.9"} 0.00043625
horizon_http_requests_duration_seconds{method="GET",route="/",status="200",streaming="false",quantile="0.99"} 0.000645
...

Consultas

Construir consultas contra el modelo de datos de métricas para resaltar el rendimiento de una implementación de Horizon dada. Consulta el Tablero de Grafana Horizon de Stellar para ejemplos de consultas de métricas para derivar el rendimiento de la aplicación:

• Número de solicitudes por minuto.
• Número de solicitudes por ruta (las rutas más populares).
• Tiempo de respuesta promedio por ruta.
• Tiempo de respuesta máximo para solicitudes no streaming.
• Número de solicitudes streaming vs. no streaming.
• Número de solicitudes limitadas por tasa.
• Lista de IPs limitadas por tasa.
• IPs únicas.
• Los SDKs/apps más populares que envían solicitudes a un nodo de Horizon dado.
• Tiempo de ingestión promedio de un ledger.
• Tiempo de ingestión promedio de una transacción.

Elige la pestaña de revisiones, y descarga el archivo fuente del tablero para tener acceso al código fuente del tablero de Grafana y a las consultas de métricas que construyen cada panel en los tableros.

Alertas

Una vez que se desarrollan consultas en un tablero de Grafana, permite un paso conveniente para agregar reglas de alerta basadas en consultas específicas para activar notificaciones cuando se exceden los umbrales.

Aquí hay algunos ejemplos de alertas a considerar con posibles causas y soluciones.

Alerta	Causa	Solución
Pico en el número de solicitudes	Posible ataque DoS	configuraciones de carga balanceada de red o conmutación de contenido
La ingestión es lenta	los recursos de computación del servidor anfitrión son bajos	aumentar las especificaciones de computación
Las respuestas de la API HTTP están devolviendo errores	los recursos de computación del servidor anfitrión son bajos o la conexión de red con la base de datos se ha perdido	revisa los registros de Horizon para ver qué errores se están emitiendo, reduce la causa raíz a partir de ahí

Registros

Horizon generará registros a la salida estándar del sistema operativo. Registrarás en todos los aspectos del tiempo de ejecución, incluyendo solicitudes HTTP y ingestión. Normalmente, hay muy pocos mensajes emitidos de severidad nivel warn o error. El nivel de severidad predeterminado registrado en Horizon está configurado como LOG_LEVEL=info, este parámetro de configuración de entorno puede ser establecido en uno de trace, debug, info, warn, error. La verbosidad de la salida de registros es inversa al nivel de severidad elegido. Es decir. para los registros más verbosos usa 'trace', para los registros menos verbosos usa 'error'.

Para implementaciones en producción, recomendamos usar la configuración de severidad predeterminada del nivel info y elegir una estrategia de captura de registros dependiendo de la implementación.

• Implementación en metal desnudo directa al sistema operativo, redirige la salida estándar del proceso de Horizon a un archivo en disco y aplica una herramienta de rotación de registros al archivo como logrotate para gestionar el uso del espacio en disco.
• Implementación orquestada en Kubernetes, usa un stack EFK/ELK en el clúster y se puede configurar para capturar la salida estándar del pod de Horizon.

Perfilado en tiempo de ejecución

Horizon está escrito en Golang, por lo tanto, se ha habilitado opcionalmente para emitir los diagnósticos y la salida de perfilado de tiempo de ejecución de Golang pprof. Los endpoints HTTP pprof están alojados en el puerto HTTP de administración de Horizon, se puede habilitar agregando el parámetro de configuración del entorno ADMIN_PORT=XXXXX, ya que el enlace del puerto de administración está deshabilitado por defecto.

Se publican dos de los perfiles predefinidos estándar:

localhost:<ADMIN_PORT>/debug/pprof/heap - perfilado de heap

localhost:<ADMIN_PORT>/debug/pprof/profile - perfilado de CPU

Usa la herramienta de línea de comandos pprof de Go para acceder a los endpoints publicados y visualizar los datos diagnósticos perfilados que se emiten. Un breve ejemplo de uso de la herramienta pprof desde la línea de comandos para comenzar, usando web para mostrar una representación gráfica de las asignaciones de heap actuales:

$ go tool pprof http://localhost:6060/debug/pprof/heap
Fetching profile over HTTP from http://localhost:6060/debug/pprof/heap
Saved profile in ./pprof/pprof.stellar-horizon.alloc_objects.alloc_space.inuse_objects.inuse_space.022.pb.gz
File: stellar-horizon
Type: inuse_space
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) web

¡Estoy Atascado! ¡Ayuda!

Si alguno de los pasos anteriores no funciona o no puedes configurar correctamente Horizon, por favor únete a nuestra comunidad y háznoslo saber. O publica una pregunta en nuestro Stack Exchange o chatea con nosotros en Horizon Discord para pedir ayuda.