Prometheus supervisa la encuesta de arquitectura de Kubernetes-1

antecedentes

Debido al vigoroso desarrollo de la contenedorización y los microservicios, Kubernetes básicamente ha unificado la solución de administración de contenedores.Cuando usamos Kubernetes para la administración en contenedores, el monitoreo integral de Kubernetes se ha convertido en el primer problema que debemos explorar. Necesitamos monitorear el ingreso, el servicio, la implementación, el pod ... y otros servicios de kubernetes, para que podamos captar el estado interno del clúster de Kubernetes en cualquier momento.

Este artículo es el primero de la serie de supervisión de Prometheus, y el propósito también es muy claro: su objetivo es encontrar un conjunto de marcos que se puedan utilizar para la supervisión de clústeres de kubernetes.

Encuesta del programa de monitoreo de K8s

• 1 、 asesor + InfluxDB + Grafana

• 2 、 Heapster + InfluxDB + Grafana

• 3 、 Promethus + kube-state-metrics + Grafana

• Grafana :
  DashBoard de código abierto, el backend admite una variedad de bases de datos, como: Influxdb, Prometheus ..., hay muchos complementos y funciones poderosas. Muy adecuado para exhibición.

• InfluxDB :
  base de datos de series de tiempo de código abierto con alto rendimiento

• cAdvisor :
  una herramienta de supervisión de contenedores de Google, que también es una herramienta de recopilación de recursos de contenedores integrada en Kubelet. Recopila automáticamente la ocupación de recursos de la CPU, la memoria, la red y el sistema de archivos del contenedor nativo, y proporciona API nativas de cAdvisor. Comience con kubelet --ca went-port = 1
  

• Heapster :
  debido a que cAdvisor solo proporciona ocupación de recursos de contenedor independiente, Heapster brinda monitoreo de recursos para todo el clúster (antes de kubernetes 1.11, hpa obtiene datos de heapster) y admite el almacenamiento de datos persistente en InfluxDB

• Promethues :
  Proporciona una potente recopilación de datos, almacenamiento de datos, visualización de datos, alarmas, etc. Nace para soportar perfectamente kubernetes, el segundo miembro de la Fundación CNCF, el primero es Kubernetes. Y muchas ideas en Prometheus provienen del sistema de monitoreo interno de Google, Borgmon, que se puede decir que es el ahijado de Google.

• kube-state-metrics se usa aquí como un exportador de prometheus, proporcionando datos de monitoreo de implementación, daemonset, cronjob y otros servicios. Es proporcionado oficialmente por kubernestes y está estrechamente integrado con prometheus.
  Más información sobre kube-state-metrics: https://github.com/kubernetes/kube-state-metrics

Ventajas de Prometheus

Prometheus y kubernetes se aman

Google ahijado, mantenimiento por una gran fábrica, y el punto más importante es el soporte perfecto para Kubernetes

Definición de especificación

Prometheus define un buen estándar para el monitoreo en la capa de la aplicación, solo la aplicación proporciona una interfaz para obtener registros.

Prometheus puede implementar la supervisión en todos los niveles, de la siguiente manera

• Capa de infraestructura: supervise los recursos de cada servidor host (incluido el nodo Kubernetes y el nodo que no es Kubernetes), como la CPU, la memoria, el rendimiento de la red y el uso del ancho de banda, la E / S del disco y el uso del disco y otros indicadores.
• Capa de middleware: supervise el middleware implementado de forma independiente fuera del clúster de Kubernetes, como MySQL, Redis, RabbitMQ, ElasticSearch, Nginx, etc.
• Clúster de Kubernetes: supervise los indicadores clave del propio clúster de Kubernetes
• Aplicaciones implementadas en clústeres de Kubernetes: supervise las aplicaciones implementadas en clústeres de Kubernetes

En base a los tres puntos anteriores, finalmente elegí usar Prometheus para monitorear el clúster de Kubernetes.

Arquitectura de supervisión de clústeres de Kubernetes

Antes de discutir la arquitectura de monitoreo de Prometheus en detalle, veamos algunas cuestiones prácticas

1. ¿Qué pasa si hay varios clústeres de Kubernetes?

2. ¿Cómo lidiar con los datos de monitoreo de múltiples clústeres de Kubernetes?

3. ¿Cómo se deben concentrar y eliminar las alarmas?

Afortunadamente, estos problemas no son difíciles para Prometheus. Al final, adoptamos la arquitectura Prometheus + kube-state-metrics + Alertmanager + Grafana para hacer el monitoreo del clúster de Kubernetes. La arquitectura específica del sistema de monitoreo es la siguiente

Usando esta arquitectura, los tres problemas mencionados anteriormente ya no serán un problema.

Detallado

Grupo K8s:

El cluster-1 / -2 / -3 de k8s es el cluster que necesita ser monitoreado, que es el cluster empresarial. Se implementa un Prometheus dentro de cada clúster, que se compone principalmente de dos partes: prometheus-server + kube-state-metrics.

prometheus-server: use una cuenta con permisos RBAC para recopilar información de monitoreo existente (de hecho, obtenida de ca went) e información de nodo en el clúster.

kube-state-metrics: se utiliza aquí como exportador de prometheus. Porque prometheus no puede obtener la información de supervisión de Implementación, Trabajo, CronJob en el clúster.
Al implementar kube-state-metrics, svc debe traer una anotación: prometheus.io/scrape:'true '(Esto es muy importante）

Resumen de seguimiento

El resumen de monitoreo es en realidad un servidor Prometheus, que se utiliza para resumir y administrar los datos de monitoreo dispersos en varios lugares.

La idea central es utilizar el mecanismo de federación de Prometheus para extraer datos de otros clústeres. De esta manera, el prometheus de otros clústeres solo necesita almacenar datos durante un corto período de tiempo y luego almacenarlos durante un tiempo prolongado después de la agregación; al mismo tiempo, también puede realizar juicios de alarma y visualización de datos de manera unificada.

Ejemplo de la Federación oficial de Prometheus

- job_name: 'federate'
  scrape_interval: 15s

  honor_labels: true
  metrics_path: '/federate'

  params:
    'match[]':
      - '{job="prometheus"}'
      - '{__name__=~"prometheus_job:.*"}'

  static_configs:
    - targets:
      - 'source-prometheus-1:9090'
      - 'source-prometheus-2:9090'
      - 'source-prometheus-3:9090'

El Prometheus al que pertenece esta configuración extraerá datos de monitoreo de los extremos / federate de los tres Prometheus, source-prometheus-1 ~ 3. El parámetro match [] especifica que solo se extraen las métricas con la etiqueta job = "prometheus o las métricas cuyo nombre comienza con prometheus_job.

Panel de visualización

El panel de visualización es un Grafana, que admite el uso de Prometheus como fuente de datos para visualización gráfica.

Manejo de alarmas

La alarma está utilizando el módulo Altermanager proporcionado oficialmente por Prometheus. El módulo Alermanager recibe información de alarma de Prometheus-Server y luego realiza operaciones como resumir, blindar y alarmar. Alertmanager admite correo electrónico, wechat, webhook, slack, etc., que son muy ricos. Pero aquí está el módulo Send_msg desarrollado por sí mismo.

Envío de mensajes

El módulo de envío de mensajes de desarrollo propio integra correo electrónico, WeChat, DingTalk, SMS y otros métodos. De hecho, no solo se enviarán mensajes cuando se emita una alarma, sino que el envío de mensajes también se utilizará en otros lugares.

Una vez que la arquitectura de supervisión está clara, el siguiente paso es implementar el proceso de supervisión. Para conocer los pasos de implementación específicos, consulte el segundo artículo de la "Serie Prometheus".

Final

Este artículo también es el primero de la serie "Supervise perfectamente el clúster de kubernetes con prometheus". Si no comprende el artículo, no dude en dejar un mensaje en segundo plano.