Capítulo 1. ¿Qué es Prometeo? ¿Qué es Prometeo?

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Prometheus es un sistema de monitoreo de código abierto basado en métricas. Por supuesto, Prometheus no es ni mucho menos el único que existe, así que, ¿qué lo hace notable?

Prometheus hace una cosa y la hace bien. Tiene un modelo de datos sencillo pero potente y un lenguaje de consulta que te permite analizar el rendimiento de tus aplicaciones e infraestructura. No intenta resolver problemas fuera del espacio de las métricas, dejando esos a otras herramientas más apropiadas.

Desde sus inicios con no más de un puñado de desarrolladores trabajando en SoundCloud en 2012, ha crecido una comunidad y un ecosistema en torno a Prometheus, que está escrito principalmente en Go y licenciado bajo la licencia Apache 2.0. Hay cientos de personas que han contribuido al proyecto en sí, que no está controlado por ninguna empresa. Siempre es difícil saber cuántos usuarios tiene un proyecto de código abierto, pero estimamos que en 2022 cientos de miles de organizaciones utilizan Prometheus en producción. En 2016, el proyecto Prometheus se convirtió en el segundo miembro¹ de la Fundación de Computación Nativa en la Nube (CNCF).

Para instrumentar tu propio código, hay bibliotecas cliente en todos los lenguajes y tiempos de ejecución populares, como Go, Java/JVM, C#/.Net, Python, Ruby, Node.js, Haskell, Erlang y Rust. Muchas aplicaciones populares ya están instrumentadas con bibliotecas cliente Prometheus, como Kubernetes, Docker, Envoy y Vault. Para el software de terceros que expone métricas en un formato que no es Prometheus, hay cientos de integraciones disponibles. Se denominan exportadores e incluyen HAProxy, MySQL, PostgreSQL, Redis, JMX, SNMP, Consul y Kafka. Un amigo de Brian incluso añadió soporte para el monitoreo de servidores de Minecraft, ya que se preocupa mucho por sus fotogramas por segundo.

Un sencillo formato de texto² facilita la exposición de métricas a Prometheus. Otros sistemas de monitoreo, tanto de código abierto como comerciales, han añadido soporte para este formato. Esto permite que todos estos sistemas de monitorización se centren más en las funciones básicas, en lugar de tener que dedicar tiempo a duplicar esfuerzos para dar soporte a cada una de las piezas de software que un usuario como tú desee monitorizar.

El modelo de datos identifica cada serie temporal no sólo con un nombre, sino también con un conjunto desordenado de pares clave-valor llamados etiquetas. El lenguaje de consulta PromQL permite la agregación a través de cualquiera de estas etiquetas, por lo que puedes analizar no sólo por proceso, sino también por centro de datos y por servicio o por cualquier otra etiqueta que hayas definido. Éstas pueden representarse gráficamente en sistemas de cuadros de mando como Grafana y Perses.

Las alertas pueden definirse utilizando exactamente el mismo lenguaje de consulta PromQL que utilizas para los gráficos. Si puedes hacer un gráfico, puedes alertar sobre él. Las etiquetas facilitan el mantenimiento de las alertas, ya que puedes crear una única alerta que cubra todos los valores posibles de las etiquetas. En otros sistemas de monitoreo tendrías que crear individualmente una alerta por máquina/aplicación. En relación con esto, el descubrimiento de servicios puede determinar automáticamente qué aplicaciones y máquinas se deben rastrear desde fuentes como Kubernetes, Consul, Amazon Elastic Compute Cloud (EC2), Azure, Google Compute Engine (GCE) y OpenStack.

A pesar de todas estas características y ventajas, Prometheus es eficiente y sencillo de ejecutar. Un solo servidor Prometheus puede ingerir millones de muestras por segundo. Es un único binario enlazado estáticamente con un archivo de configuración. Todos los componentes de Prometheus pueden ejecutarse en contenedores, y evitan hacer cualquier cosa extravagante que se interponga en el camino de las herramientas de gestión de la configuración. Está diseñado para integrarse en la infraestructura que ya tienes y construirse sobre ella, no para ser una plataforma de gestión en sí misma.

Ahora que ya tienes una idea general de lo que es Prometheus, vamos a retroceder un momento y examinar qué se entiende por "monitoreo", con el fin de proporcionar algo de contexto. A continuación, veremos cuáles son los componentes principales de Prometheus y qué no es Prometheus.

¿Qué es el monitoreo?

En secundaria, uno de los profesores de Brian le dijo que si preguntaras a 10 economistas qué significa economía, obtendrías 11 respuestas. El monitoreo tiene una falta de consenso similar en cuanto a lo que significa exactamente. Cuando cuenta a los demás lo que hace, la gente piensa que su trabajo implica desde vigilar la temperatura en las fábricas, hasta el monitoreo de los empleados, donde él es quien averigua quién accede a Facebook durante las horas de trabajo, e incluso detectar intrusos en las redes.

Prometheus no se construyó para hacer ninguna de esas cosas.³ Se construyó para ayudar a los desarrolladores y administradores de software en el funcionamiento de los sistemas informáticos de producción, como las aplicaciones, herramientas, bases de datos y redes que respaldan los sitios web populares.

Entonces, ¿qué es el monitoreo en ese contexto? Reduzcamos este tipo de monitoreo operativo de los sistemas informáticos a cuatro cosas:

Alerta: Saber cuándo las cosas van mal suele ser lo más importante para lo que quieres el monitoreo. Quieres que el sistema de monitoreo llame a una persona para que eche un vistazo.
Depurando: Ahora que has llamado a un humano, éste tiene que investigar para determinar la causa raíz y, en última instancia, resolver el problema, sea cual sea.
Tendencias: Las alertas y la depuración suelen producirse en escalas de tiempo del orden de minutos a horas. Aunque menos urgente, la capacidad de ver cómo se utilizan tus sistemas y cómo cambian con el tiempo también es útil. Las tendencias pueden influir en las decisiones de diseño y en procesos como la planificación de la capacidad.
Fontanería: Cuando sólo tienes un martillo, todo empieza a parecerte un clavo. Al fin y al cabo, todos los sistemas de monitoreo son conductos de procesamiento de datos. A veces es más conveniente apropiarse de parte de tu sistema de monitoreo para otro fin, en lugar de construir una solución a medida. Esto no es estrictamente monitoreo, pero es habitual en la práctica, así que nos gusta incluirlo.

Dependiendo de con quién hables y de su formación, pueden considerar que sólo algunas de estas cosas son monitoreo. Esto lleva a que muchas discusiones sobre el monitoreo den vueltas en círculo, dejando a todo el mundo frustrado. Para ayudarte a entender de dónde vienen los demás, vamos a repasar un poco la historia del monitoreo.

Una historia breve e incompleta del monitoreo

En los últimos años, el monitoreo se ha desplazado hacia herramientas como Prometheus. Durante mucho tiempo, la solución dominante ha sido alguna combinación de Nagios y Graphite o sus variantes.

Cuando decimos Nagios, estamos incluyendo cualquier software de la misma amplia familia, como Icinga, Zmon y Sensu. Funcionan principalmente mediante la ejecución regular de secuencias de comandos denominadas comprobaciones. Si una comprobación falla devolviendo un código de salida distinto de cero, se genera una alerta. Nagios fue creado inicialmente por Ethan Galstad en 1996 como una aplicación MS-DOS utilizada para realizar pings. Se lanzó por primera vez como NetSaint en 1999, y se rebautizó como Nagios en 2002.

Para hablar de la historia de Graphite, tenemos que remontarnos a 1994. Tobias Oetiker creó un script en Perl que se convirtió en Multi Router Traffic Grapher, o MRTG 1.0, en 1995. Como su nombre indica, se utilizaba principalmente para el monitoreo de redes a través del Protocolo Simple de Gestión de Redes (SNMP). También podía obtener métricas mediante la ejecución de scripts.⁴ El año 1997 trajo grandes cambios con el traslado de parte del código a C, y la creación de la Base de Datos Round Robin (RRD), que se utilizó para almacenar datos de métricas. Esto aportó notables mejoras de rendimiento, y RRD fue la base de otras herramientas, como Smokeping y Graphite.

Creado en 2006, Graphite utiliza Whisper para el almacenamiento de métricas, que tiene un diseño similar a RRD. Graphite no recopila datos por sí mismo, sino que los envían herramientas de recopilación como collectd y StatsD, creadas en 2005 y 2010, respectivamente.

La clave es que antes los gráficos y las alertas eran cuestiones completamente separadas, realizadas por herramientas diferentes. Podías escribir un script de comprobación para evaluar una consulta en Graphite y generar alertas sobre esa base, pero la mayoría de las comprobaciones solían ser sobre estados inesperados, como un proceso no en marcha.

Otro vestigio de esta época es el enfoque relativamente manual de la administración de los servicios informáticos. Los servicios se implementaban en máquinas individuales y los administradores de sistemas los cuidaban con esmero. Las alertas que podían indicar un problema eran atendidas por ingenieros dedicados. A medida que la nube y las tecnologías nativas de la nube, como EC2, Docker y Kubernetes, han ido adquiriendo importancia, tratar a las máquinas y servicios individuales como mascotas, prestando a cada uno de ellos una atención individualizada, no es escalable. Más bien, se tiende a considerarlos más como ganado y a administrarlos y monitorizarlos como un grupo. Del mismo modo que la industria ha pasado de hacer la gestión a mano, a herramientas como Chef y Ansible, y ahora empieza a utilizar tecnologías como Kubernetes, el monitoreo también necesita hacer una transición similar. Esto significa pasar de la comprobación de procesos individuales en máquinas individuales al monitoreo basado en la salud del servicio en su conjunto.

Trasladándonos a una época más reciente, OpenTelemetry nace de otros dos proyectos de código abierto, OpenCensus y OpenTracing. OTel⁵ es una especificación y un conjunto decomponentes que pretenden ofrecer telemetría integrada para los proyectos. Su componente de métricas es compatible con Prometheus con la adición del recolector OpenTelemetry,⁶ que se encarga de recoger y proporcionar métricas a tu servidor Prometheus.

Te habrás dado cuenta de que no hemos mencionado el registro, el rastreo y la creación de perfiles. Históricamente, los registros se han utilizado como algo en lo que utilizabas tail, grep, y awk a mano. Puede que hayas tenido una herramienta de análisis como AWStats para producir informes cada hora o cada día. En años más recientes, los registros también se han utilizado como una parte importante del monitoreo, como con la pila Elasticsearch, Logstash y Kibana (ELK) y OpenSearch. El rastreo y la creación de perfiles se realizan generalmente con su propia pila de software: Zipkin y Jaeger están hechos para el rastreo, mientras que Parca y Pyroscope se ocupan del perfilado continuo.

Ahora que hemos visto un poco los gráficos y las alertas, veamos cómo encajan las métricas y los registros en el panorama. ¿Hay más categorías de monitoreo que esas dos?

Categorías de monitoreo

Al fin y al cabo, la mayor parte del monitoreo consiste en lo mismo: eventos. Los eventos pueden ser casi cualquier cosa, incluyendo

Recibir una solicitud HTTP
Enviar una respuesta HTTP 400
Introducir una función
Llegar a else de una declaración if
Salir de una función
Un usuario que se conecta
Escribir datos en el disco
Lectura de datos de la red
Solicitar más memoria al núcleo

Todos los eventos también tienen contexto. Una solicitud HTTP tendrá la dirección IP de la que procede y a la que se dirige, la URL solicitada, las cookies establecidas y el usuario que realizó la solicitud. Una respuesta HTTP tendrá el tiempo que tardó la respuesta, el código de estado HTTP y la longitud del cuerpo de la respuesta. Los eventos en los que intervienen funciones tienen la pila de llamadas de las funciones que están por encima de ellos, y lo que desencadenó esta parte de la pila, como una solicitud HTTP.

Tener todo el contexto de todos los eventos sería estupendo para depurar y comprender cómo funcionan tus sistemas, tanto en términos técnicos como empresariales, pero no resulta práctico procesar y almacenar esa cantidad de datos. Por tanto, vemos aproximadamente cuatro formas de reducir ese volumen de datos a algo factible: perfilado, rastreo, registro y métricas.

Perfilando

La elaboración de perfiles adopta el enfoque de que no puedes tener todo el contexto para todos los eventos todo el tiempo, pero puedes tener parte del contexto durante periodos de tiempo limitados.

Tcpdump es un ejemplo de herramienta de perfilado. Te permite grabar el tráfico de red en función de un filtro especificado. Es una herramienta de depuración esencial, pero en realidad no puedes activarla todo el tiempo porque te quedarás sin espacio en disco.

Otro ejemplo son las compilaciones de depuración de binarios que rastrean datos de perfiles. Proporcionan una plétora de información útil, pero el impacto en el rendimiento de recopilar toda esa información, como los tiempos de cada llamada a una función, significa que no suele ser práctico ejecutarlo en producción de forma continuada.

En el núcleo Linux, los Filtros de Paquetes Berkeley mejorados (eBPF) permiten realizar perfiles detallados de los eventos del núcleo, desde las operaciones del sistema de archivos hasta las rarezas de la red.Permiten acceder a un nivel de conocimiento que antes no estaba disponible de forma general. eBPF tiene otras ventajas, como la portabilidad y la seguridad. Te recomendamos que leaslos escritos de Brendan Gregg sobre el tema.

El perfilado es en gran medida para la depuración táctica. Si se va a utilizar a largo plazo, habrá que reducir el volumen de datos para que encaje en alguna de las otras categorías de monitoreo, o tendrás que pasar al perfilado continuo, que permite la recogida a lo largo de tiradas más largas.

La novedad del perfilado continuo es que, para reducir el volumen de datos y mantener una sobrecarga relativamente baja, reduce la frecuencia de perfilado. Una de las herramientas emergentes de perfilado continuo, el Agente Parca basado en eBPF, utiliza una frecuencia de 19 Hz.⁷ Como consecuencia, intenta obtener datos estadísticamente significativos durante minutos en lugar de segundos, sin dejar de proporcionar los datos necesarios para comprender cómo se gasta el tiempo de la CPU en una infraestructura, y ayudar a mejorar la eficiencia de la aplicación donde sea necesario.

Rastreando

El rastreo no suele mirar todos los eventos, sino que toma cierta proporción de eventos, como uno de cada cien, que pasan por algunas funciones de interés. El rastreo anotará las funciones en la traza de la pila de los puntos de interés, y a menudo también cuánto tiempo tardó en ejecutarse cada una de esas funciones. A partir de esto puedes hacerte una idea de dónde pasa el tiempo tu programa y qué rutas de código contribuyen más a la latencia.

En lugar de hacer instantáneas de las trazas de pila en los puntos de interés, algunos sistemas de trazado rastrean y registran los tiempos de cada llamada a una función por debajo de la función de interés. Por ejemplo, se podría muestrear una de cada cien solicitudes HTTP de usuario, y para esas solicitudes podrías ver cuánto tiempo se dedicó a hablar con backends como bases de datos y cachés. Esto te permite ver cómo difieren los tiempos en función de factores como las visitas a la caché frente a las pérdidas de caché.

El rastreo distribuido va un paso más allá. Hace que el rastreo funcione a través de los procesos adjuntando identificadores únicos a las peticiones que se pasan de un proceso a otro en las llamadas a procedimientos remotos (RPC), además de indicar si esta petición es una de las que deben rastrearse. Las trazas de diferentes procesos y máquinas se pueden unir basándose en el ID de la solicitud. Se trata de una herramienta vital para depurar arquitecturas de microservicios distribuidos. Las tecnologías en este espacio incluyen OpenZipkin y Jaeger.

Para el rastreo, es el muestreo el que mantiene los volúmenes de datos y el impacto en el rendimiento de la instrumentación dentro de lo razonable.

Registro

El registro examina un conjunto limitado de eventos y registra parte del contexto de cada uno de ellos. Por ejemplo, puede examinar todas las solicitudes HTTP entrantes, o todas las llamadas a la base de datos salientes. Para evitar consumir demasiados recursos, por regla general se limita a unos cien campos por entrada de registro. Más allá de eso, el ancho de banda y el espacio de almacenamiento tienden a convertirse en un problema.

Por ejemplo, para un servidor que gestiona 1.000 solicitudes por segundo, una entrada de registro con 100 campos que ocupan 10 bytes cada uno equivale a 1 megabyte por segundo, lo que supone una proporción no trivial de una tarjeta de red de 100 Mbit, y 84 GB de almacenamiento al día sólo para el registro.

Una gran ventaja del registro es que (normalmente) no hay muestreo de eventos, por lo que, aunque hay un límite en el número de campos, es práctico determinar cómo están afectando las solicitudes lentas a un usuario concreto que habla con un punto final de la API concreto.

Al igual que monitoreo significa cosas distintas para cada persona, registro también significa cosas distintas según a quién preguntes, lo que puede causar confusión. Los distintos tipos de registro tienen diferentes usos, durabilidad y requisitos de conservación. En nuestra opinión, hay cuatro categorías generales y en cierto modo superpuestas:

Registros de transacciones: Estos son los registros empresariales críticos que debes mantener a salvo a toda costa, probablemente para siempre. Todo lo que tenga que ver con dinero o se utilice para funciones críticas de cara al usuario tiende a estar en esta categoría.
Solicitar registros: Si estás rastreando cada solicitud HTTP, o cada llamada a la base de datos, eso es un registro de solicitudes.Pueden procesarse para implementar funciones de cara al usuario, o simplemente para optimizaciones internas. Por lo general, no quieres perderlos, pero no es el fin del mundo si algunos desaparecen.
Registros de aplicaciones: No todos los registros son sobre solicitudes; algunos son sobre el propio proceso. Son típicos los mensajes de inicio, las tareas de mantenimiento en segundo plano y otras líneas de registro a nivel de proceso. Estos registros suelen ser leídos directamente por un humano, por lo que debes intentar evitar tener más de unos pocos por minuto en operaciones normales.
Registros de depuración: Los registros de depuración tienden a ser muy detallados y, por tanto, caros de crear y almacenar. A menudo sólo se utilizan en situaciones de depuración muy limitadas, y tienden hacia la creación de perfiles debido a su volumen de datos. Los requisitos de fiabilidad y retención tienden a ser bajos, y los registros de depuración pueden incluso no salir de la máquina en la que se generan.

Tratar los distintos tipos de registros de la misma forma puede ponerte en el peor de los mundos, donde tienes el volumen de datos de los registros de depuración combinado con los requisitos de fiabilidad extrema de los registros de transacciones. Por tanto, a medida que tu sistema crezca, debes planificar la separación de los registros de depuración para que puedan tratarse por separado.

Algunos ejemplos de sistemas de registro son la pila ELK, OpenSearch, Grafana Loki y Graylog.

Métricas

Las métricas ignoran en gran medida el contexto, y en su lugar rastrean agregaciones a lo largo del tiempo de diferentes tipos de eventos. Para mantener cuerdo el uso de recursos, hay que limitar la cantidad de números diferentes que se registran: 10.000 por proceso es un límite superior razonable que debes tener en cuenta.

Ejemplos del tipo de métricas que podrías tener serían el número de veces que recibiste solicitudes HTTP, cuánto tiempo se empleó en gestionar las solicitudes y cuántas solicitudes están actualmente en curso. Al excluir cualquier información sobre el contexto, los volúmenes de datos y el procesamiento necesario se mantienen razonables.

Esto no quiere decir, sin embargo, que siempre se ignore el contexto. Para una solicitud HTTP podrías decidir tener una métrica para cada ruta URL. Pero hay que tener en cuenta la directriz de las 10.000 métricas, ya que cada ruta distinta cuenta ahora como una métrica. Utilizar contextos como la dirección de correo electrónico de un usuario no sería aconsejable, ya que tienen una cardinalidad ilimitada.⁸

Puedes utilizar métricas para rastrear la latencia y los volúmenes de datos manejados por cada uno de los subsistemas de tus aplicaciones, lo que facilita la determinación de la causa de una ralentización. Los registros no pueden registrar tantos campos, pero una vez que sepas de qué subsistema es la culpa, los registros pueden ayudarte a averiguar qué peticiones de usuario exactas están implicadas.

Aquí es donde la compensación entre registros y métricas se hace más evidente. Las métricas te permiten recopilar información sobre eventos de todo tu proceso, pero generalmente con no más de uno o dos campos de contexto con cardinalidad limitada. Los registros te permiten recoger información sobre todo un tipo de sucesos, pero sólo pueden rastrear un centenar de campos de contexto con cardinalidad ilimitada. Es importante comprender la cardinalidad y los límites que impone a las métricas, y la exploraremos en capítulos posteriores.

Como sistema de monitoreo basado en métricas, Prometheus está diseñado para hacer un seguimiento general de la salud, el comportamiento y el rendimiento del sistema, más que de eventos individuales. Dicho de otro modo, Prometheus se preocupa de que hubo 15 peticiones en el último minuto que tardaron 4 segundos en gestionarse, dieron lugar a 40 llamadas a la base de datos, 17 visitas a la caché y 2 compras por parte de los clientes. El coste y las rutas de código de las llamadas individuales serían la preocupación del perfilado o el registro.

Ahora que ya sabes dónde encaja Prometheus en el ámbito general del monitoreo, veamos los distintos componentes de Prometheus.

Prometeo Arquitectura

La Figura 1-1 muestra la arquitectura general de Prometheus. Prometheus descubre objetivos para scrapear desde el descubrimiento de servicios. Pueden ser tus propias aplicaciones instrumentadas o aplicaciones de terceros que puedes raspar mediante un exportador. Los datos raspados se almacenan, y puedes utilizarlos en cuadros de mando mediante PromQL o enviar alertas al Alertmanager, que las convertirá en páginas, correos electrónicos y otras notificaciones.

Bibliotecas de clientes

Las métricas no suelen brotar mágicamente de las aplicaciones; alguien tiene que añadir la instrumentación que las produce. Aquí es donde entran en juego las bibliotecas cliente. Con sólo dos o tres líneas de código, puedes definir una métrica y añadir la instrumentación que desees en el código que controlas. Esto se denomina instrumentación directa.

Existen bibliotecas cliente para los principales lenguajes y tiempos de ejecución. El proyecto Prometheus proporciona bibliotecas cliente oficiales en Go, Python, Java/JVM, Ruby y Rust. También hay diversas bibliotecas cliente de terceros, como para C#/.Net, Node.js, Haskell y Erlang.

Las bibliotecas cliente se encargan de todos los detalles esenciales, como la seguridad de los hilos, la contabilidad y la producción del texto de Prometheus y/o el formato de exposición de OpenMetrics en respuesta a las solicitudes HTTP. Como el monitoreo basado en métricas no rastrea los eventos individuales, el uso de memoria de la biblioteca cliente no aumenta con el número de eventos que tengas. Más bien, la memoria está relacionada con el número de métricas que tengas.

Si una de las dependencias de biblioteca de tu aplicación tiene instrumentación de Prometheus, se recogerá automáticamente. Así, instrumentando una biblioteca clave, como tu cliente RPC, puedes obtener instrumentación para ella en todas tus aplicaciones.

Algunas métricas, como el uso de la CPU y las estadísticas de recogida de basura, suelen proporcionarlas de fábrica las bibliotecas cliente, dependiendo de la biblioteca y del entorno de ejecución.

Las bibliotecas cliente no se limitan a generar métricas en los formatos de texto de Prometheus y OpenMetrics. Prometheus es un ecosistema abierto, y las mismas API utilizadas para alimentar la generación de formatos de texto pueden utilizarse para producir métricas en otros formatos o para alimentar otros sistemas de instrumentación. Del mismo modo, es posible tomar métricas de otros sistemas de instrumentación e introducirlas en una biblioteca cliente de Prometheus, si aún no lo has convertido todo a la instrumentación de Prometheus.

Exportadores

No todo el código que ejecutas es código que puedas controlar o al que tengas acceso, por lo que añadir instrumentación directa no es realmente una opción. Por ejemplo, es poco probable que los núcleos de los sistemas operativos empiecen a emitir métricas con formato Prometheus a través de HTTP en un futuro próximo.

Este tipo de software suele tener alguna interfaz a través de la cual puedes acceder a las métricas, que puede ser un formato ad hoc que requiera un análisis y un manejo personalizados, como ocurre con muchas métricas de Linux, o un estándar bien establecido, como SNMP.

Un exportador es una pieza de software que despliegas junto a la aplicación de la que quieres obtener métricas. Recibe solicitudes de Prometheus, recoge los datos necesarios de la aplicación, los transforma en el formato correcto y, finalmente, los devuelve en una respuesta a Prometheus. Puedes pensar en un exportador como un pequeño proxy uno a uno, que convierte los datos entre la interfaz de métricas de una aplicación y el formato de exposición de Prometheus.

A diferencia de la instrumentación directa que utilizarías para el código que controlas, los exportadores utilizan un estilo diferente de instrumentación conocido como colectores personalizados oConstMetrics.⁹

La buena noticia es que, dado el tamaño de la comunidad Prometheus, el exportador que necesitas probablemente ya existe y puede utilizarse con poco esfuerzo por tu parte. Si al exportador le falta una métrica que te interesa, siempre puedes enviar una solicitud de mejora para que la próxima persona que lo utilice pueda utilizarlo mejor.

Descubrimiento de servicios

Una vez que tengas todas tus aplicaciones instrumentadas y tus exportadores en ejecución, Prometheus necesita saber dónde están. Así Prometheus sabrá qué debe monitorizar y podrá darse cuenta de si algo que debe monitorizar no responde. Con entornos dinámicos no puedes simplemente proporcionar una lista de aplicaciones y exportadores una sola vez, ya que quedará desfasada. Aquí es donde entra en juego el descubrimiento de servicios.

Probablemente ya tengas alguna base de datos de tus máquinas, aplicaciones y lo que hacen. Puede estar en la base de datos de Chef, en un archivo de inventario de Ansible, en las etiquetas de tu instancia EC2, en las etiquetas y anotaciones de Kubernetes, o tal vez en tu wiki de documentación.

Prometheus tiene integraciones con muchos mecanismos habituales de descubrimiento de servicios, como Kubernetes, EC2 y Consul. También hay una integración genérica para aquellos cuya configuración se salga un poco de lo habitual (ver "Archivo" y "HTTP").

Sin embargo, esto sigue dejando un problema. Que Prometheus tenga una lista de máquinas y servicios no significa que sepamos cómo encajan en tu arquitectura. Por ejemplo, puede que utilices la etiqueta EC2 Name ¹⁰ para indicar qué aplicación se ejecuta en una máquina, mientras que otros podrían utilizar una etiqueta llamada app.

Como cada organización lo hace de forma ligeramente distinta, Prometheus te permite configurar cómo se asignan los metadatos del descubrimiento de servicios a los objetivos de monitoreo y sus etiquetas mediante el reetiquetado.

Raspando

El descubrimiento de servicios y el reetiquetado nos dan una lista de objetivos que hay que monitorizar. Ahora Prometheus necesita obtener las métricas. Prometheus lo hace enviando una solicitud HTTP llamada "scrape". La respuesta al scrape se analiza e ingiere en el almacenamiento. También se añaden varias métricas útiles, como si el scrape tuvo éxito y cuánto tiempo tardó. Los scrapes se realizan con regularidad; normalmente se configuran para que se realicen cada 10 a 60 segundos para cada objetivo.

Almacenamiento

Prometheus almacena los datos localmente en una base de datos personalizada. Los sistemas distribuidos son difíciles de hacer fiables, por lo que Prometheus no intenta hacer ningún tipo de agrupación. Además de la fiabilidad, esto hace que Prometheus sea más fácil de ejecutar.

A lo largo de los años, el almacenamiento ha pasado por varios rediseños, y el sistema de almacenamiento de Prometheus 2.0 es la tercera iteración. El sistema de almacenamiento puede gestionar la ingesta de millones de muestras por segundo, haciendo posible el monitoreo de miles de máquinas con un solo servidor Prometheus. El algoritmo de compresión utilizado puede alcanzar 1,3 bytes por muestra en datos del mundo real. Se recomienda un SSD, pero no es estrictamente necesario.

Cuadros de mando

Prometheus tiene una serie de API HTTP que te permiten solicitar datos sin procesar y evaluar consultas PromQL. Pueden utilizarse para producir gráficos y cuadros de mando. Prometheus proporciona el navegador de expresiones. Utiliza estas API y es adecuado para realizar consultas ad hoc y explorar datos, pero no es un sistema general de cuadros de mando.

Se recomienda utilizar Grafana para los cuadros de mando. Tiene una gran variedad de funciones, incluida la compatibilidad oficial con Prometheus como fuente de datos. Puede producir una gran variedad de paneles de control, como el de la Figura 1-2. Grafana admite la comunicación con varios servidores Prometheus, incluso dentro de un mismo panel de control.

Reglas de grabación y alertas

Aunque PromQL y el motor de almacenamiento son potentes y eficientes, agregar métricas de miles de máquinas sobre la marcha cada vez que generas un gráfico puede resultar un poco lento. Las reglas de registro permiten que las expresiones PromQL se evalúen periódicamente y que sus resultados se ingieran en el motor de almacenamiento.

Las reglas de alerta son otra forma de reglas de registro. También evalúan expresiones PromQL regularmente, y cualquier resultado de esas expresiones se convierte en alertas. Las alertas se envían al Gestor de Alertas.

Gestión de alertas

El Alertmanager recibe alertas de los servidores de Prometheus y las convierte en notificaciones. Las notificaciones pueden incluir correo electrónico, aplicaciones de chat como Slack, y servicios como PagerDuty.

El Alertmanager hace algo más que convertir ciegamente las alertas en notificaciones de forma individual. Las alertas relacionadas pueden agregarse en una sola notificación, estrangularse para reducir las tormentas de buscapersonas,¹¹ y se pueden configurar diferentes salidas de enrutamiento y notificación para cada uno de tus diferentes equipos. Las alertas también pueden silenciarse, tal vez para posponer un problema del que ya tienes conocimiento de antemano cuando sabes que está programado un mantenimiento.

El papel del Alertmanager se limita a enviar notificaciones; para gestionar las respuestas humanas a las incidencias debes utilizar servicios como PagerDuty y sistemas de tickets.

Consejo

Las alertas y sus umbrales se configuran en Prometheus, no en el Alertmanager.

Almacenamiento a largo plazo

Dado que Prometheus almacena los datos sólo en la máquina local, estás limitado por la cantidad de espacio en disco que quepa en esa máquina.¹² Aunque normalmente sólo te interesan los datos del día más reciente, para planificar la capacidad a largo plazo, es deseable un periodo de retención más largo.

Prometheus no ofrece una solución de almacenamiento en clúster para almacenar datos en varias máquinas, pero hay API de lectura y escritura remotas que permiten que otros sistemas se enganchen y asuman este papel. Esto permite ejecutar consultas PromQL de forma transparente tanto con datos locales como remotos.

Lo que Prometeo no es

Ahora que ya tienes una idea de dónde encaja Prometheus en el panorama más amplio del monitoreo y cuáles son sus componentes principales, veamos algunos casos de uso para los que Prometheus no es una opción especialmente buena.

Como sistema basado en métricas, Prometheus no es adecuado para almacenar registros de eventos o eventos individuales. Tampoco es la mejor opción para datos de alta cardinalidad, como direcciones de correo electrónico o nombres de usuario.

Prometheus está diseñado para el monitoreo operativo, donde las pequeñas imprecisiones y las condiciones de carrera debidas a factores como la programación del núcleo y los raspados fallidos son un hecho de la vida. Prometheus hace concesiones y prefiere darte datos que sean correctos en un 99,9% a que tu monitorización se rompa esperando datos perfectos. Por tanto, en aplicaciones que impliquen dinero o facturación, Prometheus debe utilizarse con precaución.

En el próximo capítulo te mostraremos cómo ejecutar Prometheus y hacer un poco demonitoreo básico.

¹ Kubernetes fue el primer miembro.

² Junto al formato de texto simple, se ha creado una versión más estandarizada, ligeramente diferente, llamada OpenMetrics, a partir del formato de texto Prometheus.

³ En realidad, el monitoreo de la temperatura de máquinas y centros de datos no es infrecuente. Incluso hay algunos usuarios que utilizan Prometheus para controlar el tiempo por diversión.

⁴ Brian tiene buenos recuerdos de cuando configuró MRTG a principios de la década de 2000, escribiendo scripts para informar sobre la temperatura y el uso de la red en mis ordenadores domésticos.

⁵ OTel es un nombre informal para OpenTelemetry.

⁶ En el momento de escribir esto, los desarrolladores de una cumbre de desarrolladores de Prometheus han decidido que el servidor Prometheus soportará el protocolo OTel de forma nativa en el futuro, pero no hay una decisión firme sobre cuándo y cómo ocurrirá.

⁷ Comparable a la frecuencia de 100 Hz del tiempo de ejecución de Go o incluso de 10.000 Hz en Chromium.

⁸ Las direcciones de correo electrónico también suelen ser información personal identificable (IPI), lo que conlleva problemas de cumplimiento y privacidad que es mejor evitar en el monitoreo.

⁹ El término ConstMetric es coloquial, y procede de la función MustNewConstMetric de la biblioteca cliente Go, utilizada para producir métricas por los exportadores escritos en Go.

¹⁰ La etiqueta EC2 Name es el nombre para mostrar una instancia EC2 en la consola web de EC2.

¹¹ Un aviso es una notificación a un ingeniero de guardia que se espera que investigue o solucione rápidamente. Aunque puedes recibir un aviso a través de un radiolocalizador tradicional, hoy en día es más probable que llegue a tu teléfono móvil en forma de SMS, notificación o llamada telefónica. Una tormenta de avisos es cuando recibes una serie de avisos en rápida sucesión.

¹² Sin embargo, las máquinas modernas pueden almacenar muchos datos localmente, por lo que un sistema de almacenamiento en clúster separado puede no ser necesario para ti.

Get Prometeo: Up & Running, 2ª Edición now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Prometeo: Up & Running, 2ª Edición by Julien Pivotto, Brian Brazil