Descripción general
Para los sistemas con escalabilidad elástica y alta disponibilidad, generalmente hay una gran cantidad de datos de indicadores que deben recopilarse y almacenarse.¿Cómo crear una solución de monitoreo para tal sistema? Este artículo describe cómo construir un sistema de monitoreo usando Thanos+Prometheus+Grafana.
Descripción general de la capacidad del clúster
historia del usuario
Hasta enero de este año, había estado monitoreando clústeres de Kubernetes con una solución de monitoreo de nivel empresarial que también se usaba para APM. Se siente natural de usar, se integra con Kubernetes muy fácilmente con ajustes menores y puede integrar APM y métricas de infraestructura.
Si bien esta solución de monitoreo puede recopilar y almacenar datos fácilmente, el uso de métricas para crear alertas tiene importantes limitaciones de consulta . A menudo, las alertas que recibimos son diferentes de las que se muestran en el tablero. Sin mencionar que tenemos 6 clústeres y la cantidad de métricas recopiladas y almacenadas es muy alta, lo que aumenta en gran medida nuestro costo económico.
Después de considerarlo un poco, nos dimos cuenta de que continuar usando esta solución de monitoreo haría más daño que bien. ¡Es hora de reemplazar nuestra solución de vigilancia! Pero, ¿qué producto o herramienta usar? Grafana es la mejor opción para herramientas de visualización , pero nuestro "backend" necesita tener escalabilidad elástica y alta disponibilidad ¿Qué herramienta debemos usar?
Si usa OpenTSDB puramente, la instalación requiere demasiado trabajo y esfuerzo; el Prometheus independiente no proporciona capacidades de replicación y necesita equiparlo con varias bases de datos; TimeScaleDB se ve bien, pero no soy muy bueno usando PostgreSQL.
Después de experimentar con algunas de las soluciones anteriores, revisé el sitio web de CNCF y ¡finalmente encontré a Thanos ! Satisface todas nuestras necesidades: retención de datos a largo plazo, replicable, altamente disponible, adecuado para microservicios, ¡tiene una visión global de todos los clústeres utilizando la misma base de datos!
arquitectura
No tenemos almacenamiento persistente disponible en nuestro clúster (todos los servicios permanecen sin estado), por lo que el enfoque sidecar predeterminado de Prometheus + Thanos no está disponible y el almacenamiento de métricas debe colocarse fuera del clúster. Además, los grupos están aislados entre sí, no es posible vincular los componentes de Thanos a un conjunto específico de grupos y los grupos deben monitorearse desde "afuera".
En resumen, considerando la alta disponibilidad y la posibilidad de que Thanos se ejecute en una máquina virtual, nuestra arquitectura final es la siguiente:
Como se muestra en la figura, tenemos una arquitectura de múltiples centros de datos. Cada uno de estos centros cuenta con un conjunto de servidores Grafana + Query , un conjunto de servidores de almacenamiento y tres servidores de Recepción (la mitad del número de clústeres).
La base de datos utilizada por Grafana también tiene un AWS RDS. Esta base de datos no tiene que ser enorme (para mantener bajos los costos) y nuestro equipo no necesita administrar MySQL.
Entre todos los componentes proporcionados por Thanos, implementamos 4 de ellos:
-
Recibir : responsable de TSDB, también administra la replicación entre todos los servidores que ejecutan la recepción y la carga de bloques TSBD en S3.
-
Consulta : Responsable de consultar la base de datos de recepción.
-
Almacenar : lee S3 para métricas a largo plazo que ya no se almacenan en recepción.
-
Compactador : gestiona la reducción de resolución de datos y la compresión de bloques TSDB almacenados en S3.
integración de datos
La ingestión de datos para todos los clústeres es administrada por un Prometheus Pod dedicado que se ejecuta dentro del clúster . Recopila métricas de la placa de control (servidor de API, controlador y planificador), clúster etcd y pods dentro del clúster con métricas relacionadas con la infraestructura y el propio Kubernetes (Kube-proxy, Kubelet, Node Exporter, State Metrics, Metrics Server, y otros Pods con anotaciones de raspado).
Luego, Prometheus Pod envía la información a uno de los servidores de recepción que administran la TSDB con la configuración de almacenamiento remoto.
ingesta de datos
Todos los datos se envían a un solo servidor y luego se replican en otros servidores. La dirección DNS que utiliza Prometheus es un GSLB de DNS que sondea cada servidor de recepción y equilibra la resolución de DNS entre los servidores en buen estado, compartiendo la carga entre todos los servidores porque la resolución de DNS solo proporciona una IP para cada consulta de DNS.
Se debe enfatizar que los datos deben enviarse a una sola instancia de recepción y dejar que administre la replicación, enviar la misma métrica hará que la replicación falle y se comporte mal .
En este nivel, las métricas también se cargan en un depósito S3 para la retención a largo plazo. Recibir carga un bloque cada 2 horas (cuando se cierra cada bloque TSDB), y estas métricas se pueden usar para consultas usando el componente Store.
También puede establecer el tiempo de retención de los datos locales. En este caso, todos los datos locales se conservan durante 30 días para uso diario y resolución de problemas, lo que agiliza las consultas .
Los datos de más de 30 días solo están disponibles en S3 y se conservan hasta 1 año para evaluación y comparación a largo plazo.
consulta de datos
Los datos se recopilan y almacenan en el receptor para su consulta. Esta parte también está configurada para estar disponible en varios centros de datos.
Con cada servidor que ejecuta Grafana y Query, si uno (o ambos) se cae, podemos identificarlo más fácilmente y eliminarlo del balanceador de carga. En Grafana, la fuente de datos está configurada como host local, por lo que siempre usa Query local para obtener datos.
Para la configuración de la consulta, debe conocer todos los servidores (Receiver y Store) que almacenan métricas. El componente de consulta sabe qué servidores están en línea y puede recopilar métricas de ellos.
consulta de datos
También gestiona la deduplicación, ya que consulta todos los servidores y configura la replicación, todas las métricas tienen múltiples copias. --query.replica-label=QUERY.REPLICA-LABELEsto se puede hacer usando etiquetas y parámetros de consulta ( ) asignados a las métricas . Con estas configuraciones, el componente de consulta sabe si las métricas recopiladas de Receiver y Store están duplicadas y usa solo un punto de datos.
datos a largo plazo
Como se mencionó anteriormente, los datos se guardan localmente hasta por 30 días, todo lo demás se almacena en S3. Esto reduce la cantidad de espacio requerido en el receptor y reduce los costos, ya que el almacenamiento de bloques es más costoso que el almacenamiento de objetos. Sin mencionar que consultar datos de más de 30 días no es muy común y se usa principalmente para el historial de uso de recursos y la previsión.
consulta remota de datos
La tienda también mantiene una copia local del índice para cada fragmento de TSDB almacenado en el depósito S3, por lo que si necesita consultar más de 30 días de datos, sabe qué fragmentos descargar y usar para entregar los datos.
Situación de los datos
Considerando todos los clústeres, el esquema de monitoreo:
-
Supervisé 6 clústeres de Kubernetes;
-
Métricas recopiladas de 670 servicios;
-
246 servidores fueron monitoreados usando Node Exporter;
-
Recopile alrededor de 27w indicadores por minuto;
-
Ingerir aproximadamente 7,3 GB de datos por día, o aproximadamente 226,3 GB de datos por mes;
-
Creó 40 tableros dedicados para los componentes de Kubernetes;
-
Se crean 116 alarmas en Grafana.
Para la tarifa mensual, con la mayoría de los componentes ejecutándose en las instalaciones, el costo se redujo en un 90,61 % , de $38 421,25 a $3608,99 por mes, lo que incluye los costos del servicio de AWS.
Resumir
Tomó alrededor de un mes configurar y configurar la arquitectura anterior, incluida la prueba de otras soluciones, la validación de la arquitectura, la implementación, la activación de la recopilación en el clúster y la creación de todos los paneles.
En la primera semana, los beneficios fueron evidentes. El monitoreo de clústeres se ha vuelto más fácil, los tableros se pueden crear y personalizar rápidamente, la recopilación de métricas es casi plug-and-play, la mayoría de las aplicaciones exportan métricas en formato Prometheus y las recopilan automáticamente en función de las anotaciones.
Además, se puede lograr un control de permisos de equipo más preciso integrando el LDAP de Grafana. Los desarrolladores y SRE tienen acceso a una gran cantidad de paneles con métricas relevantes sobre su espacio de nombres, ingreso, etc.