En publicaciones anteriores, describimos cómo configurar Prometheus para trabajar con tus aplicaciones de TIBCO BusinessWorks Container Edition, y puedes leer más al respecto aquí.
Prometheus Monitoring for Microservices using TIBCO
We’re living a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies. This time I’d like to […]
En esa publicación, describimos que había varias formas de actualizar a Prometheus sobre los servicios que están listos para monitorear. Y elegimos la más simple en ese momento que era la configuración de static_config, lo que significa:
No te preocupes Prometheus, te haré saber la IP que necesitas monitorear y no necesitas preocuparte por nada más.
Y esto es útil para una prueba rápida en un entorno local cuando quieres probar rápidamente tu configuración de Prometheus o quieres trabajar en la parte de Grafana para diseñar el mejor tablero posible para manejar tus necesidades.
Pero, esto no es muy útil para un entorno de producción real, aún más, cuando estamos hablando de un clúster de Kubernetes donde los servicios están subiendo y bajando continuamente con el tiempo. Entonces, para resolver esta situación, Prometheus nos permite definir diferentes tipos de formas para realizar este enfoque de «descubrimiento de servicios». En la documentación oficial de Prometheus, podemos leer mucho sobre las diferentes técnicas de descubrimiento de servicios, pero a un nivel alto, estas son las principales técnicas de descubrimiento de servicios disponibles:
Configuration | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
azure_sd_configs: Descubrimiento de Servicios de Azure
consul_sd_configs: Descubrimiento de Servicios de Consul
dns_sd_configs: Descubrimiento de Servicios de DNS
ec2_sd_configs: Descubrimiento de Servicios de EC2
openstack_sd_configs: Descubrimiento de Servicios de OpenStack
file_sd_configs: Descubrimiento de Servicios de Archivo
gce_sd_configs: Descubrimiento de Servicios de GCE
kubernetes_sd_configs: Descubrimiento de Servicios de Kubernetes
marathon_sd_configs: Descubrimiento de Servicios de Marathon
nerve_sd_configs: Descubrimiento de Servicios de Nerve de AirBnB
serverset_sd_configs: Descubrimiento de Servicios de Serverset de Zookeeper
triton_sd_configs: Descubrimiento de Servicios de Triton
static_config: IP/DNS Estático para la configuración. Sin Descubrimiento de Servicios.
E incluso, si todas estas opciones no son suficientes para ti y necesitas algo más específico, tienes una API disponible para extender las capacidades de Prometheus y crear tu propia técnica de Descubrimiento de Servicios. Puedes encontrar más información al respecto aquí:
Implementing Custom Service Discovery | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
Pero este no es nuestro caso, para nosotros, el Descubrimiento de Servicios de Kubernetes es la elección correcta para nuestro enfoque. Así que, vamos a cambiar la configuración estática que teníamos en la publicación anterior:
Como puedes ver, esto es bastante más complejo que la configuración anterior, pero no es tan complejo como podrías pensar a primera vista, revisémoslo por diferentes partes.
- role: endpoints
namespaces:
names:
- default
Dice que vamos a usar el rol para los endpoints que se crean bajo el namespace por defecto y vamos a especificar los cambios que necesitamos hacer para encontrar los endpoints de métricas para Prometheus.
Eso significa que queremos hacer un reemplazo del valor de la etiqueta y podemos hacer varias cosas:
Renombrar el nombre de la etiqueta usando el target_label para establecer el nombre de la etiqueta final que vamos a crear basado en las source_labels.
Reemplazar el valor usando el parámetro regex para definir la expresión regular para el valor original y el parámetro replacement que va a expresar los cambios que queremos hacer a este valor.
Así que, ahora después de aplicar esta configuración cuando despleguemos una nueva aplicación en nuestro clúster de Kubernetes, como el proyecto que podemos ver aquí:
Automáticamente vamos a ver un objetivo adicional en nuestra configuración de job-name “bwce-metrics”
In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here.
Prometheus Monitoring for Microservices using TIBCO
We’re living a world with constant changes and this is even more true in the Enterprise Application world. I’ll not spend much time talking about things you already know, but just say that the microservices architecture approach and the PaaS solutions have been a game-changer for all enterprise integration technologies. This time I’d like to […]
In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that moment that was the static_config configuration which means:
Don’t worry Prometheus, I’ll let you know the IP you need to monitor and you don’t need to worry about anything else.
And this is useful for a quick test in a local environment when you want to test quickly your Prometheus set up or you want to work in the Grafana part to design the best possible dashboard to handle your need.
But, this is not too useful for a real production environment, even more, when we’re talking about a Kubernetes cluster when services are going up & down continuously over time. So, to solve this situation Prometheus allows us to define a different kind of ways to perform this “service discovery” approach. In the official documentation for Prometheus, we can read a lot about the different service discovery techniques but at a high level these are the main service discovery techniques available:
Configuration | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
azure_sd_configs: Azure Service Discovery
consul_sd_configs: Consul Service Discovery
dns_sd_configs: DNS Service Discovery
ec2_sd_configs: EC2 Service Discovery
openstack_sd_configs: OpenStack Service Discovery
file_sd_configs: File Service Discovery
gce_sd_configs: GCE Service Discovery
kubernetes_sd_configs: Kubernetes Service Discovery
marathon_sd_configs: Marathon Service Discovery
nerve_sd_configs: AirBnB’s Nerve Service Discovery
serverset_sd_configs: Zookeeper Serverset Service Discovery
triton_sd_configs: Triton Service Discovery
static_config: Static IP/DNS for the configuration. No Service Discovery.
And even, it all these options are not enough for you and need something more specific you have an API available to extend the Prometheus capabilities and create your own Service Discovery technique. You can find more info about it here:
Implementing Custom Service Discovery | Prometheus
An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
But this is not our case, for us, the Kubernetes Service Discovery is the right choice for our approach. So, we’re going to change the static configuration we had in the previous post:
As you can see this is quite more complex than the previous configuration but it is not as complex as you can think at first glance, let’s review it by different parts.
- role: endpoints
namespaces:
names:
- default
It says that we’re going to use role for endpoints that are created under the default namespace and we’re going to specify the changes we need to do to find the metrics endpoints for Prometheus.
That means that we want to do a replace of the label value and we can do several things:
Rename the label name using the target_label to set the name of the final label that we’re going to create based on the source_labels.
Replace the value using the regex parameter to define the regular expression for the original value and the replacement parameter that is going to express the changes that we want to do to this value.
So, now after applying this configuration when we deploy a new application in our Kubernetes cluster, like the project that we can see here:
Automatically we’re going to see an additional target on our job-name configuration “bwce-metrics”
