En este documento, se describe cómo puedes configurar un entorno que mezcle recopiladores autoimplementados con recopiladores administrados, en diferentes clústeres y proyectos de Google Cloud.
Recomendamos usar la recopilación administrada para todos los entornos de Kubernetes. Así, prácticamente se borra la sobrecarga de ejecutar recopiladores de Prometheus dentro del clúster. Puedes ejecutar recopiladores administrados y autoimplementados dentro del mismo clúster. Recomendamos usar un enfoque coherente en la supervisión, pero puedes optar por combinar métodos de implementación para algunos casos de uso específicos, como alojar una puerta de enlace de envío, como se muestra en este documento.
En el siguiente diagrama, se ilustra una configuración que usa dos proyectos de Google Cloud, tres clústeres y una combinación de recopilación administrada y autoimplementada. Si usas solo la recopilación administrada o autoimplementada, el diagrama seguirá siendo aplicable. Simplemente ignora el estilo de recopilación que no estás usando:
Para configurar y usar una configuración como la del diagrama, ten en cuenta lo siguiente:
Debes instalar cualquier exportador necesario en los clústeres. Google Cloud Managed Service para Prometheus no instala ningún exportador en tu nombre.
El proyecto 1 tiene un clúster que ejecuta una recopilación administrada, que se ejecuta como un agente de nodo. Los recopiladores se configuran con recursos PodMonitoring para recolectar destinos dentro de un espacio de nombres y con recursos ClusterPodMonitoring para recolectar destinos en un clúster. Los PodsMonitoring deben aplicarse en cada espacio de nombres en el que desees recopilar métricas. Los recursos ClusterPodMonitoring se aplican una vez por clúster.
Todos los datos recopilados en el proyecto 1 se guardan en Monarch en el proyecto 1. Estos datos se almacenan de forma predeterminada en la región de Google Cloud desde la que se emiten.
El proyecto 2 tiene un clúster que ejecuta la recopilación autoimplementada mediante el operador de Prometheus y su ejecución como un servicio independiente. Este clúster está configurado para usar ServiceMonitors o PodMonitors de operadores de Prometheus para recolectar los exportadores en Pods o VM.
El proyecto 2 también aloja un sidecar de puerta de enlace de envío para recopilar métricas de cargas de trabajo efímeras.
Todos los datos recopilados en el proyecto 2 se guardan en Monarch en el proyecto 2. Estos datos se almacenan de forma predeterminada en la región de Google Cloud desde la que se emiten.
El proyecto 1 también tiene un clúster que ejecuta Grafana y el sincronizador de fuentes de datos. En este ejemplo, estos componentes se alojan en un clúster independiente, pero se pueden alojar en cualquier clúster único.
El sincronizador de fuentes de datos está configurado para usar scoping_project_A, y su cuenta de servicio subyacente tiene los permisos de Visualizador de Monitoring para scoping_project_A.
Cuando un usuario emite consultas desde Grafana, Monarch expande scoping_project_A a sus proyectos supervisados constituyentes y muestra resultados para los proyectos 1 y 2 en todas las regiones de Google Cloud. Todas las métricas conservan sus etiquetas originales
project_idylocation(región de Google Cloud) para fines de agrupación y filtrado.
Si tu clúster no se ejecuta dentro de Google Cloud, debes configurar de forma manual las etiquetas project_id y location. Si deseas obtener información sobre cómo configurar estos valores, consulta Ejecuta Managed Service para Prometheus fuera de Google Cloud.
No federes cuando uses Managed Service para Prometheus. Para reducir la cardinalidad y los costos de la “integración” de datos antes de enviarlos a Monarch, usa la agregación local en su lugar. Para obtener más información, consulta Configura la agregación local.