Alexandre Vazquez

Promtail es la solución cuando necesitas proporcionar métricas que solo están presentes en los rastros de registro del software que necesitas monitorear para proporcionar una plataforma de monitoreo consistente

Es un entendimiento común que tres pilares en el mundo de la observabilidad nos ayudan a obtener una vista completa del estado de nuestras propias plataformas y sistemas: Registros, Trazas y Métricas.

Para proporcionar un resumen de las diferencias entre cada uno de ellos:

• Las métricas son los contadores sobre el estado de los diferentes componentes desde una vista técnica y de negocio. Así que aquí podemos ver cosas como el consumo de CPU, el número de solicitudes, el uso de memoria o disco…
• Los registros son los diferentes mensajes que cada una de las piezas de software en nuestra plataforma proporciona para entender su comportamiento actual y detectar algunas situaciones no esperadas.
• La traza es la diferente información sobre el flujo de solicitudes de extremo a extremo a través de la plataforma con los servicios y sistemas que han sido parte de ese flujo y datos relacionados con esa solicitud concreta.

Tenemos soluciones que afirman abordar todos ellos, principalmente en el software empresarial con Dynatrace, AppDynamics y similares. Y por otro lado, intentamos ir con una solución específica para cada uno de ellos que podamos integrar fácilmente juntos y hemos discutido mucho sobre esas opciones en artículos anteriores.

Pero, algunas situaciones en ese software no funcionan siguiendo este camino porque vivimos en la era más heterogénea. Todos abrazamos, en algún nivel, el enfoque políglota en las nuevas plataformas. En algunos casos, podemos ver que el software está utilizando rastros de registro para proporcionar datos relacionados con métricas u otros asuntos, y aquí es cuando necesitamos confiar en piezas de software que nos ayuden a «arreglar» esa situación, y Promtail hace específicamente eso.

Promtail es principalmente un reenviador de registros similar a otros como fluentd o fluent-bit de CNCF o logstash del stack ELK. En este caso, esta es la solución de Grafana Labs, y como puedes imaginar, esto es parte del stack de Grafana con Loki para ser el «cerebro» que cubrimos en este artículo que te recomiendo que eches un vistazo si aún no lo has leído:

Promtail tiene dos formas principales de comportarse como parte de esta arquitectura, y la primera es muy similar a otras en este espacio, como comentamos antes. Nos ayuda a enviar nuestros rastros de registro desde nuestros contenedores a la ubicación central que principalmente será Loki y puede ser una diferente y proporcionar las opciones habituales para jugar y transformar esos rastros como podemos hacer en otras soluciones. Puedes ver todas las opciones en el enlace a continuación, pero como puedes imaginar, esto incluye transformación, filtrado, análisis, y así sucesivamente.

Stages

Stages Esta seccion es una colección de todas las etapas Sopportas en una tuberá. Parsing etapas: docker: Extraer datos parsendo la linea de log usando la …

Pero lo que hace a promtail tan diferente es solo una de las acciones que puedes hacer, y esa acción es metrics. Metrics proporciona una forma específica de, basado en los datos que estamos leyendo de los registros, crear métricas de Prometheus que un servidor de Prometheus puede recolectar. Eso significa que puedes usar los rastros de registro que estás procesando que pueden ser algo como esto:

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 123

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 191

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 52

Con esta información aparte de enviar esas métricas a la ubicación central para crear una llamada de métrica, por ejemplo: `total_request_count` que será generada por el agente promtail y también expuesta por él y siendo capaz también de usar un enfoque de métricas incluso para sistemas o componentes que no proporcionan una forma estándar de hacer eso como una API de métricas formal.

Y la forma de hacer esto está muy bien integrada con la configuración. Esto se hace con una etapa adicional (así es como llamamos a las acciones que podemos hacer en Promtail) que se llama metrics.

El esquema de esa etapa de métrica es sencillo, y si estás familiarizado con Prometheus, verás lo directo que es desde una definición de métricas de Prometheus a este fragmento:

# Un mapa donde la clave es el nombre de la métrica y el valor es un tipo de
# métrica específico.
metrics:
  [<string>: [ <metric_counter> | <metric_gauge> | <metric_histogram> ] ...]

Así que comenzamos definiendo el tipo de métricas que nos gustaría definir, y tenemos las habituales: contador, gauge o histograma, y para cada uno de ellos, tenemos un conjunto de opciones para poder declarar nuestras métricas como puedes ver aquí para una Métrica de Contador

# El tipo de métrica. Debe ser Counter.
type: Counter

# Describe la métrica.

[description: <string>]

# Define un nombre de prefijo personalizado para la métrica. Si no está definido, el nombre predeterminado «promtail_custom_» será prefijado.

[prefix: <string>]

# Clave del mapa de datos extraídos para usar en la métrica, # por defecto al nombre de la métrica si no está presente.

[source: <string>]

# Los valores de las etiquetas en las métricas son dinámicos, lo que puede causar que las métricas exportadas se vuelvan obsoletas (por ejemplo, cuando un flujo deja de recibir registros). # Para prevenir el crecimiento ilimitado del endpoint /metrics, cualquier métrica que no haya sido actualizada dentro de este tiempo será eliminada. # Debe ser mayor o igual a ‘1s’, si no está definido el valor predeterminado es ‘5m’

[max_idle_duration: <string>]

config: # Si está presente y es verdadero, todas las líneas de registro serán contadas sin # intentar coincidir la fuente con el mapa extraído. # Es un error especificar `match_all: true` y también especificar un `value`

[match_all: <bool>]

# Si está presente y es verdadero, todos los bytes de la línea de registro serán contados. # Es un error especificar `count_entry_bytes: true` sin especificar `match_all: true` # Es un error especificar `count_entry_bytes: true` sin especificar `action: add`

[count_entry_bytes: <bool>]

# Filtra los datos de origen y solo cambia la métrica # si el valor objetivo coincide exactamente con la cadena proporcionada. # Si no está presente, todos los datos coincidirán.

[value: <string>]

# Debe ser «inc» o «add» (insensible a mayúsculas). Si # se elige inc, el valor de la métrica aumentará en 1 por cada # línea de registro recibida que pase el filtro. Si se elige add, # el valor extraído debe ser convertible a un flotante positivo # y su valor se sumará a la métrica. action: <string>

Y con eso, tendrás tu métrica creada y expuesta, solo esperando que un servidor de Prometheus la recolecte. Si te gustaría ver todas las opciones disponibles, toda esta documentación está disponible en la documentación de Grafana Labs que puedes consultar en el enlace:

metrics

metrics stage The metrics stage is an action stage that allows for defining and updating metrics based on data from the extracted map. Note that created …

Espero que encuentres esto interesante y una forma útil de mantener toda tu información de observabilidad gestionada correctamente usando la solución adecuada y proporcionar una solución para estas piezas de software que no siguen tu paradigma.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.