En el contenido anterior, profundizamos en cómo EasyMR aprovecha Kubernetes para la implementación. Como habrá aprendido, en la arquitectura general de EasyMR, utilizamos Prometheus para recopilar, consultar y almacenar datos de monitoreo de servicios y nodos. Al mismo tiempo, Grafana , como poderosa herramienta de visualización, muestra los datos de monitoreo en Prometheus de varias maneras.
En este artículo, analizaremos en detalle cómo recopilar dinámicamente datos de monitoreo de aplicaciones Kubernetes en EasyMR.
Puntos débiles de las soluciones de recogida tradicionales
En modo host, la configuración monitoreada por EasyMR usando Prometheus depende principalmente de static_configs y file_sd_configs. Debido a que bajo este esquema de implementación, la estabilidad de los nodos y las aplicaciones es alta y los cambios e incertidumbres involucrados son pequeños, a menos que exista una situación extrema como el tiempo de inactividad del nodo, debemos modificar manualmente la configuración del trabajo de recopilación correspondiente.
Sin embargo, en el contexto de la era nativa de la nube, el monitoreo, como parte clave de la práctica de observabilidad , ha experimentado algunos cambios importantes en comparación con el monitoreo de sistemas y aplicaciones bajo la arquitectura tradicional:
· Los microservicios y la contenedorización de aplicaciones conducen a un aumento exponencial en los objetos e indicadores de monitoreo
· El ciclo de vida de los objetos de monitoreo es más corto, lo que resulta en un aumento exponencial en la cantidad y complejidad de los datos de monitoreo.
En términos sencillos, nuestro clúster de Kubernetes tendrá muchos Nodos/Servicios/Pod y otros recursos. Estos recursos cambiarán dinámicamente a medida que cambie la escala de la demanda. La IP y el nombre del mismo Pod de aplicación también cambiarán a medida que se reinicie la aplicación. Cambios debidos a actualizaciones continuas.
Entonces, cuando se crean o actualizan los recursos de Kubernetes, será una carga de trabajo muy grande modificar las tareas de trabajo en Prometheus una por una, porque no se puede juzgar el tiempo de reinicio del Pod (Kubernetes tiene su propio programador, tal vez la CPU/CPU de el host donde se encuentra actualmente el Pod La presión de la memoria/disco es demasiado alta, el Pod puede alcanzar el límite de recursos establecido, etc., lo que provocará que el Pod se reprograme). En este contexto, necesitamos que Prometheus tenga la función de descubrimiento automático de servicios .
Descubrimiento automático del servicio Prometheus
Para el escenario anterior en el que static_configs y file_sd_configs no se pueden configurar mediante una colección estática, el propio Prometheus proporciona una solución: introducir un centro de registro de servicios . Este centro de registro contiene la información de acceso de todos los objetivos de monitoreo actuales, y Prometheus solo necesita preguntar qué objetivos de monitoreo hay. Prometheus consulta la lista de objetivos que deben monitorearse y luego sondea estos objetivos para obtener datos de monitoreo.
Prometheus admite múltiples mecanismos de descubrimiento de servicios : archivos, DNS, Consul, Kubernetes, OpenStack, EC2, etc. Este artículo toma el mecanismo de descubrimiento de servicios de Kubernetes como ejemplo para analizarlo en detalle.
En Kubernetes, Prometheus admite principalmente cinco modos de descubrimiento de servicios mediante la integración con la API de Kubernetes: nodo, servicio, pod, puntos finales e ingreso.
Diferentes modos de descubrimiento de servicios son adecuados para diferentes escenarios, por ejemplo: Node es adecuado para monitorear recursos relacionados con el host, como el estado de los componentes de Kubernetes que se ejecutan en el nodo, el estado de los contenedores que se ejecutan en el nodo, etc.; Servicio e Ingress son adecuados para escenarios de monitoreo de caja negra , como monitorear la disponibilidad y la calidad del servicio; tanto Endpoints como Pods se pueden usar para obtener datos de monitoreo de instancias de Pod , como monitorear aplicaciones implementadas por usuarios o administradores que admiten Prometheus.
Práctica de monitoreo de EasyMR para aplicaciones K8S
Prometheus utiliza el modo de extracción para obtener métricas, por lo que la interfaz /metrics debe estar expuesta para las aplicaciones de destino que deben monitorearse. A continuación, comenzamos con los pasos de implementación de Prometheus y recopilamos información de monitoreo de MySQL para describir en detalle cómo EasyMR usa el mecanismo de descubrimiento de servicios de Prometheus.
Crear archivo de configuración de Prometheus
El núcleo del descubrimiento automático de Prometheus radica en la configuración relacionada de relabel_configs: primero, configure estas etiquetas de metadatos comenzando con _ meta hasta source_labels, declare los recursos que deben coincidir, luego busque los objetos de recursos relevantes a través de reglas de coincidencia de expresiones regulares y finalmente recopile. · Realizar procesamiento secundario de los indicadores, como retención, transferencia, reemplazo y otras operaciones.
Crear cuenta de servicio/rol/enlace de roles
Dado que Prometheus necesita acceder a los recursos de Kubernetes, y Kubernetes tiene un mecanismo de control de permisos RBAC detallado , debe crear una cuenta correspondiente antes de implementar Prometheus y otorgarle permisos a la cuenta para la interfaz correspondiente. Por razones de seguridad, EasyMR solo necesita obtener los permisos del espacio de nombres correspondiente, por lo que no necesitamos los permisos globales de ClusterRole.
Crear implementación de Prometheus
Dado que Prometheus necesita almacenar datos, el PV correspondiente debe crearse con anticipación. La recomendación oficial es utilizar localpv, que no se describirá aquí. En el archivo de configuración de implementación, solo necesitamos especificar el nombre del PVC, la configuración de la clave se muestra aquí.
Principales MySQL Statefulset, MySQL Exporter, Servicio MySQL
Dado que el mismo Pod comparte red y almacenamiento, implementamos MySQL Exporter como un contenedor separado y un contenedor MySQL en el mismo Pod en la arquitectura de implementación. Solo necesitamos exponer el puerto de monitoreo de MySQL Exporter al centro de registro de Prometheus. Eso es todo, algunos Las configuraciones importantes son las siguientes:
● Conjunto de estado de MySQL
● Servicio MySQL
Agregue dos configuraciones bajo las anotaciones de la configuración del Servicio:
· prometeus.io/port: 9104
· prometheus.io/scrpae: verdadero
Ver la configuración de objetivos de Prometheus
Puede ver que Prometheus ha descubierto dinámicamente los datos de monitoreo expuestos por el servicio MySQL implementado y el estado es ARRIBA, sin intervención manual.
Ver el panel de EasyMR Grafana
Después de las operaciones anteriores, podemos ver fácilmente información rica de monitoreo de MySQL en la página EasyMR , y también se pueden completar otros servicios mediante pasos similares.
Conclusión
En la era nativa de la nube, la combinación de Promtheus + Grafana se ha convertido en una parte indispensable de las herramientas de observabilidad , pero cómo maximizar su función aún requiere que todos exploren en profundidad. En el futuro, EasyMR también realizará sus propias exploraciones en otros campos de observabilidad (registro, rastreo).
Dirección de descarga del "Informe técnico del producto Dutstack": https://www.dtstack.com/resources/1004?src=szsm
Dirección de descarga del "Libro técnico sobre prácticas de la industria de gobernanza de datos": https://www.dtstack.com/resources/1001?src=szsm
Para aquellos que quieran saber o consultar más sobre productos de big data, soluciones industriales y casos de clientes, visite el sitio web oficial de Kangaroo Cloud: https://www.dtstack.com/?src=szkyzg
Broadcom anunció la terminación del programa de socios de VMware existente , el sitio B se bloqueó dos veces, el incidente de nivel uno "3.29" de Tencent... Haciendo un balance de los diez principales incidentes de tiempo de inactividad en 2023, se lanzó Vue 3.4 "Slam Dunk", Yakult confirmó que se filtraron datos de 95G. MySQL 5.7, Moqu, Li Tiaotiao... Haciendo un balance de los proyectos y sitios web (de código abierto) que se "detendrán" en 2023 Se publica oficialmente el "Informe de desarrolladores de código abierto de China 2023" Mirando hacia atrás en el IDE de hace 30 años: solo TUI, color de fondo brillante... Julia 1.10 lanzado oficialmente Rust 1.75.0 lanzado NVIDIA lanzó GeForce RTX 4090 D especialmente para la venta en China