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í.
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:
- 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í:
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:
- job_name: 'bwdockermonitoring'
honor_labels: true
static_configs:
- targets: ['phenix-test-project-svc.default.svc.cluster.local:9095']
labels:
group: 'prod'
Por esta configuración de Kubernetes
- job_name: 'bwce-metrics'
scrape_interval: 5s
metrics_path: /metrics/
scheme: http
kubernetes_sd_configs:
- role: endpoints
namespaces:
names:
- default
relabel_configs:
- source_labels: [__meta_kubernetes_service_label_app]
separator: ;
regex: (.*)
replacement: $1
action: keep
- source_labels: [__meta_kubernetes_endpoint_port_name]
separator: ;
regex: prom
replacement: $1
action: keep
- source_labels: [__meta_kubernetes_namespace]
separator: ;
regex: (.*)
target_label: namespace
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_pod_name]
separator: ;
regex: (.*)
target_label: pod
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_service_name]
separator: ;
regex: (.*)
target_label: service
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_service_name]
separator: ;
regex: (.*)
target_label: job
replacement: 1
action: replace
- separator: ;
regex: (.*)
target_label: endpoint
replacement: $1
action: replace
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.
scrape_interval: 5s metrics_path: /metrics/ scheme: http
Esto dice que vamos a ejecutar el proceso de scrape en un intervalo de 5 segundos, usando http en la ruta /metrics/
Y luego, tenemos una sección de relabel_config:
- source_labels: [__meta_kubernetes_service_label_app]
separator: ;
regex: (.*)
replacement: $1
action: keep
- source_labels: [__meta_kubernetes_endpoint_port_name]
separator: ;
regex: prom
replacement: $1
action: keep
Eso significa que nos gustaría mantener esa etiqueta para prometheus:
- source_labels: [__meta_kubernetes_namespace]
separator: ;
regex: (.*)
target_label: namespace
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_pod_name]
separator: ;
regex: (.*)
target_label: pod
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_service_name]
separator: ;
regex: (.*)
target_label: service
replacement: $1
action: replace
- source_labels: [__meta_kubernetes_service_name]
separator: ;
regex: (.*)
target_label: job
replacement: 1
action: replace
- separator: ;
regex: (.*)
target_label: endpoint
replacement: $1
action: replace
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”
