Prometheus ha incluido una nueva capacidad en la versión 2.32.0 para optimizar el enfoque de un solo panel de vidrio 

A partir de la nueva versión próxima de Prometheus v2.32.0, tendremos una nueva característica importante a nuestra disposición: el Modo Agente. Y hay una fantástica publicación en el blog anunciando esta característica de uno de los rockstars del equipo de Prometheus: Bartlomiej Plotka, que recomiendo leer. Agregaré una sección de referencia al final del artículo. Intentaré resumir algunos de los puntos más relevantes aquí.

Otra publicación sobre Prometheus, el sistema de monitoreo más crítico en las arquitecturas nativas de la nube de hoy en día, tiene su origen en el sistema de monitoreo Borgmon creado por Google en tiempos antiguos (alrededor del período 2010–2014).

Basado en esta importancia, su uso ha estado creciendo increíblemente y fortaleciendo su relación con el ecosistema de Kubernetes. Hemos llegado a un punto en que Prometheus es la opción predeterminada para el monitoreo en prácticamente cualquier escenario que tenga una carga de trabajo relacionada con Kubernetes; algunos ejemplos son los que se muestran a continuación:

• Prometheus es la opción predeterminada, incluyendo el Sistema de Monitoreo de Openshift
• Prometheus tiene un Servicio Gestionado de Amazon a su disposición para ser utilizado en sus cargas de trabajo.
• Prometheus está incluido en la Arquitectura de Referencia para Despliegues Nativos de la Nube de Azure.

Debido a esta popularidad y crecimiento, muchos casos de uso diferentes han planteado algunas mejoras que se pueden realizar. Algunos de ellos están relacionados con casos de uso específicos como el despliegue en el borde o proporcionar una vista global, o un solo panel de vidrio.

Hasta ahora, si tengo varios despliegues de Prometheus, monitoreo un subconjunto específico de sus cargas de trabajo debido a que residen en diferentes redes o porque hay varios clústeres, puede confiar en la capacidad de escritura remota para agregar eso en un enfoque de vista global.

La Escritura Remota es una capacidad que ha existido en Prometheus desde su creación. Las métricas que Prometheus está recopilando se pueden enviar automáticamente a un sistema diferente utilizando sus integraciones. Esto se puede configurar para todas las métricas o solo un subconjunto. Pero incluso con todo esto, están avanzando en esta capacidad, por lo que están introduciendo el modo Agente.

El Modo Agente optimiza el caso de uso de escritura remota configurando la instancia de Prometheus en un modo específico para realizar este trabajo de manera optimizada. Ese modelo implica la siguiente configuración:

• Desactivar consultas y alertas.
• Cambiar el almacenamiento local por un TSDB WAL personalizado

Y lo notable es que todo lo demás es igual, por lo que seguiremos utilizando la misma API, descubriendo capacidades y configuración relacionada. ¿Y qué te proporcionará todo esto? Veamos los beneficios que obtendrás al hacerlo:

• Eficiencia: El TSDB WAL personalizado mantendrá solo los datos que no pudieron ser enviados al lugar de destino; tan pronto como tenga éxito, eliminará esa pieza de datos.
• Escalabilidad: Mejorará la escalabilidad, permitiendo una escalabilidad horizontal más fácil para la ingesta. Esto se debe a que este modo agente desactiva algunas de las razones por las que la autoestabilidad es compleja en el modo servidor normal de Prometheus. Una carga de trabajo con estado hace que la escalabilidad sea compleja, especialmente en escenarios de reducción de escala. Así que este modo llevará a una carga de trabajo «más sin estado» que simplificará este escenario y estará cerca del sueño de un sistema de ingesta de métricas de autoescalabilidad.

Esta característica está disponible como una bandera experimental en la nueva versión, pero ya fue probada con los trabajos de Grafana Labs, especialmente en el lado del rendimiento.

Si deseas ver más detalles sobre esta característica, te recomendaría echar un vistazo al siguiente artículo: https://prometheus.io/blog/2021/11/16/agent/

Prometheus has included a new capability in the 2.32.0 release to optimize the single pane of glass approach

From the new upcoming release of Prometheus v2.32.0, we will have an important new feature at our disposal: the Agent Mode. And there is a fantastic blog post announcing this feature from our of the rockstar from the Prometheus team: Bartlomiej Plotka, that I recommend reading. I will add a reference section at the end of the article. I will try to summarise some of the most relevant points here.

Another post about Prometheus, the most critical monitoring system in nowadays cloud-native architectures, has its inception in the Borgmon monitoring system created by Google in ancient times (around the 2010–2014 period).

Based on this importance, its usage has been growing incredibly and making its relationship with the Kubernetes ecosystem stronger. We have reached a point that Prometheus is the default option for monitoring in pretty much any scenario that has a Kubernetes workload related to it; some examples are the ones shown below:

• Prometheus is the default option, including the Openshift Monitoring System
• Prometheus has an Amazon Managed Service at your disposal to be used for your workloads.
• Prometheus is included in the Reference Architecture for Cloud-Native Azure Deployments.

Because of this popularity and growth, many different use-cases have raised some improvements that can be done. Some of them are related to specific use-cases such as edge deployment or providing a global view, or a single pane of glass.

Until now, if I have several Prometheus deployments, monitor a specific subset of your workloads because of their resides on different networks or because there are various clusters, you can rely on the remote write capability to aggregate that into a global view approach.

Remote Write is a capability that has existed in Prometheus since its inception. The metrics that Prometheus is scraping can be sent automatically to a different system using their integrations. This can be configured for all the metrics or just a subset. But even with all of these, they are jumping ahead on this capability, which is why they are introducing the Agent mode.

Agent Mode optimizes the remote write use case configuring the Prometheus instance in a specific mode to do this job in an optimized way. That model implies the following configuration:

• Disable querying and alerting.
• Switch the local storage with a customized TSDB WAL

And the remarkable thing is that everything else is the same, so we will still use the same API, discover capabilities, and related configuration. And what all of this will provide to you? Let’s take a look at the benefits you will get of doing so:

• Efficiency: Customised TSDB WAL will keep only the data that could not be sent to the target location; as soon as it succeeds, it will remove that piece of data.
• Scalability: It will improve scalability, enabling easier horizontal scalability for ingestion. This is because this agent mode disables some of the reasons auto-stability is complex in normal server-mode Prometheus. A stateful workload makes scalability complex, especially in scale-down scenarios. So this mode will lead to a “more-stateless” workload that will simplify this scenario and be close to the dream of an auto-scalability metric ingestion system.

This feature is available as an experimental flag in the new release, but this was already tested with Grafana Labs’ works, especially on the performance side.

If you want to take a look at more details about this feature, I would recommend taking a look at the following article: https://prometheus.io/blog/2021/11/16/agent/