Con el continuo desarrollo y crecimiento de las empresas, la cantidad de servidores en línea también está aumentando, por lo que también aumentará la probabilidad de fallas en el software y el hardware empresarial. En la situación anterior, cuando el host o la aplicación de la empresa es anormal, si la empresa no tiene un sistema de monitoreo relativamente completo y poderoso, causará la interrupción del negocio de la empresa, y esta pérdida es enorme para la empresa.

Autor: Edward Li, ingeniero de desarrollo de inteligencia en la nube. Con muchos años de experiencia en operación y mantenimiento y Devops , está comprometido con la investigación e implementación de la dirección nativa de la nube .

Introducción al Monitoreo

Con la llegada de los microservicios, los sistemas de monitoreo se han vuelto aún más importantes. Cuando los desarrolladores escriben un programa a una escala relativamente pequeña, elegirán escribir un script o un programa pequeño para el monitoreo; cuando la escala de la aplicación de servicio propia de una empresa es relativamente grande, se adoptará una solución de monitoreo comercial adecuada para su propio sistema comercial. Cloud Wisdom es un proveedor líder de soluciones de mantenimiento y operación comercial inteligente de pila completa en China, y sus productos incluyen monitoreo de tesoros, tesoros en perspectiva y otro software comercial. Además, algunas empresas elegirán algunas soluciones de monitoreo de código abierto, como Zabbix, Prometheus, etc. En este artículo, explicaremos cómo elegir una solución de monitoreo adecuada en la era nativa de la nube.

Finalidad del seguimiento

Establecer un sistema de monitoreo sólido puede lograr los siguientes objetivos:

Alarma: cuando el sistema ocurre o está a punto de fallar, el sistema de monitoreo debe responder rápidamente y notificar al administrador, de modo que el problema se pueda tratar rápidamente o se pueda prevenir la ocurrencia del problema con anticipación para evitar el impacto en el negocio;
Análisis de tendencias a largo plazo: llevar a cabo un análisis de tendencias a largo plazo de los indicadores de seguimiento a través de la recopilación y estadísticas continuas de datos de muestra de seguimiento;
Análisis comparativo: ¿Cuál es la diferencia en el uso de recursos operativos de las dos versiones del sistema? ¿Cómo varía la concurrencia y la carga del sistema con diferentes capacidades? A través del monitoreo, el sistema se puede rastrear y comparar fácilmente;
Análisis y ubicación de fallas: cuando ocurre un problema, es necesario investigarlo y solucionarlo. A través del análisis de diferentes datos históricos y de monitoreo, se puede encontrar y resolver la causa raíz;
Visualización de datos: a través del tablero visual, puede obtener directamente información intuitiva, como el estado de ejecución del sistema, el uso de recursos y el estado de ejecución del servicio.

dimensiones del seguimiento

Las dimensiones del seguimiento incluyen principalmente los siguientes aspectos:

Capa de red: incluida la supervisión de protocolos de red (http, dns, tcp, icmp) y hardware de red (enrutadores, conmutadores, etc.);
Capa de host: supervisa principalmente el uso de recursos como CPU, MEM y almacenamiento;
Capa de contenedor: principalmente monitorea el uso de CPU, MEM, almacenamiento y otros recursos;
Capa de aplicación: principalmente monitoreo de retraso, error, QPS, estado interno, etc.;
Capa de middleware: principalmente monitorea el uso de recursos y el estado del servicio;
Capa de herramientas de orquestación: supervisa principalmente el uso de recursos del clúster, la programación, etc.

Cuatro indicadores de seguimiento de oro

Golden Signals es un resumen de la experiencia de Google en una gran cantidad de monitoreo distribuido. Los cuatro indicadores dorados pueden ayudar a medir problemas como la experiencia del usuario final, la interrupción del servicio y el impacto comercial a nivel de servicio. El enfoque principal está en los siguientes cuatro tipos de métricas: latencia, tráfico, errores y saturación:

Latencia: El tiempo que se tarda en atender una solicitud. Registrar el tiempo que demoran todas las solicitudes del usuario, con énfasis en distinguir entre el tiempo de demora de una solicitud exitosa y el tiempo de demora de una solicitud fallida;
Tráfico: Monitorea el tráfico actual del sistema para medir las necesidades de capacidad del servicio. El tráfico puede significar diferentes cosas para diferentes tipos de sistemas. Por ejemplo, en una API REST HTTP, el tráfico suele ser solicitudes HTTP por segundo;
Errores: Supervise todas las solicitudes de error que se producen en el sistema actual y mida la tasa a la que se producen errores en el sistema actual. Algunos de los errores son explícitos (p. ej., error HTTP 500) y otros son implícitos (p. ej., respuesta HTTP 200, pero el proceso comercial real sigue fallando). Para algunas excepciones dentro del sistema, es posible que deba agregar estadísticas de enlace directamente desde el servicio y obtenerlas;
Saturación: Mide la saturación del servicio actual. El énfasis principal está en los recursos limitados que más afectan el estado del servicio. Porque normalmente, cuando estos recursos se saturan, el rendimiento del servicio bajará significativamente. Al mismo tiempo, la saturación también se puede usar para hacer predicciones sobre el sistema. Por ejemplo, "¿Es probable que el disco esté lleno en 4 horas?".

Sistema de Monitoreo Prometeo

Prometheus es una solución de monitoreo de código abierto y un marco de alerta y monitoreo de sistemas de código abierto. Se utiliza para recopilar y agregar métricas como datos de series temporales, se desarrolló como un proyecto comunitario de código abierto y se lanzó oficialmente en 2015.

Ventajas de Prometeo

Halo nativo de la nube: es amigable con el soporte de Kubernetes (tendencia).Como Kubernetes ha establecido una posición de liderazgo en la programación y administración de contenedores, Prometheus también se ha convertido en el estándar para el monitoreo de contenedores de Kubernetes;
Potente lenguaje de consulta: Prometheus tiene integrado un potente lenguaje de consulta de datos, PromQL. La consulta y agregación de datos de monitoreo se puede realizar a través de PromQL. Al mismo tiempo, PromQL también se usa en visualización de datos (como Grafana) y alertas;
Mecanismo de descubrimiento dinámico del servicio: actualmente se admiten Kubernetes, Consul, Etcd, etc., lo que puede reducir la carga de trabajo de la configuración manual por parte del personal de operación y mantenimiento (especialmente importante en entornos de contenedores);
Extensible: partición funcional (fragmentación) + conjunto de federación (federación) se puede extender;
Fácil de integrar: el uso de Prometheus puede crear rápidamente servicios de monitoreo y puede ser muy conveniente para integrar en la aplicación. Clientes de colección ricos (oficiales, de terceros, personalizados);
Eficiente y fácil de administrar: la implementación multiplataforma es compatible con millones de métricas de monitoreo y cientos de miles de puntos de datos por segundo.

Arquitectura Prometeo

Servidor Prometheus: la recuperación obtiene regularmente datos de métricas de objetivos descubiertos dinámicamente por el servicio a través del servidor HTTP. Cada objetivo de obtención debe exponer una interfaz de servicio HTTP (que cumpla con la especificación de Prometheus) para obtener regularmente con Prometheus. Los datos de monitoreo recopilados se conservan y almacenan en TSDB;
Consulta de PromQL: puede usar PromQL para consultar varios datos de indicadores a través de Prometheus WebUi, Api Clients o Grafana;
Empuje de alarma: envía las alarmas que exceden el umbral después del cálculo al Alertmanager.Después de una mayor agrupación, supresión y silencio, el Alertmanager las envía a un canal de alarma más rico;
Objetivo de recopilación: el objetivo recopilado puede ser una variedad de exportadores oficiales o una interfaz de tres partes que implementa la especificación de Prometheus (como la interfaz de métricas de Nacos y Arrangodb), como PushGateway, etc.

Tipo de indicador

Contador: un contador que solo aumenta y no disminuye, útil para almacenar información como la cantidad de solicitudes HTTP atendidas o el tiempo de CPU utilizado;
Indicador: un tablero que se puede aumentar o disminuir, este indicador se enfoca en el estado actual del sistema de reacción;
Resumen: El resumen se usa para registrar el tamaño promedio de algo, tal vez el tiempo que se tardó en calcular o el tamaño del archivo procesado. El resumen muestra dos datos relacionados: recuento (la cantidad de veces que ocurrió el evento) y suma. (el tamaño total de todos los eventos);
Histograma: El indicador Histograma refleja directamente el número de muestras en diferentes intervalos, y el intervalo está definido por el archivo de etiqueta. Los histogramas se denominan histogramas principales o histogramas, y se utilizan principalmente para contar una distribución de valores de indicadores. Cubo: establezca el intervalo del eje horizontal, solo establezca el límite superior pero no el límite inferior. Se utiliza principalmente para contar la distribución de solicitudes que consume mucho tiempo.

Exportador común

Los exportadores comúnmente utilizados en la comunidad incluyen principalmente los siguientes:

Tareas y ejemplos

Agregando la siguiente configuración en el archivo de configuración prometheus.yml:

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

objetivo de la colección

Prometheus ya es compatible con varios mecanismos integrados de detección de servicios. Los desarrolladores pueden configurarlo a través de la sección scrape_config en el archivo de configuración de Prometheus. Prometheus actualizará continuamente la lista de objetivos de rastreo dinámico, detendrá automáticamente el rastreo de instancias antiguas y comenzará a rastrear instancias nuevas. Prometheus es especialmente adecuado para ejecutarse bajo el clúster de Kubernetes y puede descubrir automáticamente objetivos de monitoreo. Bajo Kubernetes, Promethues admite principalmente 5 modos de detección de servicios al integrarse con la API de Kubernetes, a saber: Nodo, Servicio, Pod, Puntos finales, Ingreso.

Solución de supervisión de clústeres de Kubernetes

cAdvisor: cAdvisor es la herramienta de análisis de rendimiento y monitoreo de recursos de contenedores de código abierto de Google. Está especialmente diseñado para contenedores y admite contenedores Docker. Actualmente está integrado en el componente kubelet.
kube-state-metrics: kube-state-metrics genera métricas de estado sobre objetos de recursos, como Implementación, Nodo y Pod, al escuchar el servidor API. Cabe señalar que kube-state-metrics simplemente proporciona datos de métricas y no lo almacena Estos datos de métricas, por lo que podemos usar Prometheus para obtener estos datos y almacenarlos. El enfoque principal está en algunos metadatos relacionados con el negocio, como la implementación, el pod, el estado de la réplica, etc.
metrics-server: metrics-server también es una herramienta de agregación de datos de recursos de todo el clúster, que es un sustituto de Heapster.Del mismo modo, metrics-server solo muestra datos y no proporciona servicios de almacenamiento de datos. La principal preocupación es la implementación de API de medición de recursos, como CPU, descriptores de archivos, memoria, latencia de solicitud y otros indicadores.

Visualización de datos Grafana

Tipo de panel de datos

Serie temporal: visualización de datos de gráficos de barras, áreas y líneas basados en el tiempo;
Bar Chart: visualización de clasificación de datos;
Stat: para visualización de datos relacionados con estadísticas de datos;
Indicador: una visualización que muestra el valor actual en relación con los valores mínimo y máximo;
Tabla: el contenido de los datos se muestra en el diseño de la tabla;
Gráfico circular: Visualización del panel de gráfico circular;
Mapa de calor: muestra la distribución de valores.

Alta disponibilidad de Prometheus

Escenario de disponibilidad

En Prometheus, cuando una instancia cuelga, se elimina automáticamente del LB y también tiene la función de equilibrio de carga, lo que puede reducir la presión sobre Prometheus. Sin embargo, este modo tiene deficiencias obvias, es decir, no resuelve los problemas de consistencia y persistencia de datos.Dado que Prometheus es un método Pull, incluso si varias instancias capturan los mismos indicadores de monitoreo, no se puede garantizar que los valores capturados sean consistente. Además, habrá algunos problemas de retraso de la red en el proceso de uso real, por lo que causará el problema de la inconsistencia de los datos. Sin embargo, para escenarios de monitoreo y alarma, generalmente no se requiere una consistencia de datos sólida, por lo que este método es aceptable desde una perspectiva comercial. El escenario de disponibilidad de Prometheus es adecuado para escenarios en los que la escala de monitoreo no es grande y solo es necesario guardar datos de monitoreo de período corto.

Escenario de persistencia de datos

Después de configurar el almacenamiento remoto para Prometheus, no hay necesidad de preocuparse por la pérdida de datos Incluso cuando una instancia de Prometheus falla o se pierden datos, se pueden recuperar a través de los datos almacenados de forma remota.

clúster federado

Cuando una sola instancia de Promthues no puede manejar una gran cantidad de tareas de recopilación, los desarrolladores pueden usar el enfoque basado en clúster federado de Prometheus para dividir las tareas de monitoreo en diferentes instancias de Prometheus. Los desarrolladores pueden dividir diferentes tipos de tareas de recopilación en diferentes instancias de Prometheus para su ejecución y realizar fragmentación funcional. Por ejemplo, un Prometheus es responsable de recopilar datos de indicadores de nodos, otro Prometheus es responsable de recopilar datos de indicadores de monitoreo relacionados con el negocio de la aplicación y, finalmente, el capa superior Los datos se agregan a través de Prometheus.

Cabe señalar que cuando el número de destinos en una sola tarea de recopilación es demasiado grande, se puede considerar la partición funcional a nivel de instancia. Divida las tareas de recopilación de datos de supervisión de diferentes instancias de una tarea en diferentes instancias de Prometheus.

Arquitectura de alta disponibilidad

Sidecar: conéctese a Prometheus y exponga Prometheus a la puerta de enlace de consulta (Querier/Query) para consultas en tiempo real, y cargue datos de Prometheus en el almacenamiento en la nube para almacenamiento a largo plazo;
Querier/Query: implementa la API de Prometheus y agrega datos de los componentes subyacentes (como el componente sidecar Sidecar o la puerta de enlace de almacenamiento Store Gateway);
Store Gateway: exponga el contenido de los datos en el almacenamiento en la nube;
Compactador: comprimir y reducir la muestra de datos en el almacenamiento en la nube;
Regla: evaluar y alertar sobre los datos de seguimiento.

Querier/Query: implementa la API de Prometheus y agrega datos de los componentes subyacentes (como el componente sidecar Sidecar o la puerta de enlace de almacenamiento Store Gateway);
Store Gateway: exponga el contenido de los datos en el almacenamiento en la nube;
Compactador: comprimir y reducir la muestra de datos en el almacenamiento en la nube;
Receptor: obtenga datos del WAL de escritura remota de Prometheus (registro de escritura anticipada remota de Prometheus), expóngalos o cárguelos en el almacenamiento en la nube;
Regla: evaluar y alertar sobre los datos de seguimiento

Ventajas de Thanos

Thanos es una solución de monitorización basada en Prometheus con funciones de alta disponibilidad (HA), persistencia de almacenamiento y consulta multicluster, que incluye principalmente las siguientes ventajas:

Entrada de consulta unificada: al usar Querier como una entrada de consulta unificada, implementa la interfaz de consulta de Prometheus y StoreAPI, y puede proporcionar servicios de consulta para otros Queriers. Durante la consulta, obtendrá datos de indicador de Sidecar y Store Gateway de cada instancia de Prometheus. ;
Alta utilización del espacio: cada Prometheus en sí no almacena datos a largo plazo, y Sidecar cargará los bloques de datos persistentes de Prometheus en el almacenamiento de objetos. El Compactador comprimirá regularmente los datos a largo plazo en el almacenamiento de objetos remotos y los limpiará de acuerdo con el tiempo de muestreo para ahorrar espacio de almacenamiento;
Consulta entre clústeres: cuando necesite combinar los resultados de la consulta de varios clústeres, solo necesita agregar otra capa de Querier encima del Querier de cada clúster.Este tipo de anidamiento puede hacer que la escala del clúster se expanda sin límite;
Expansión horizontal: cuando la presión de recopilación de indicadores de Prometheus es demasiado alta, puede crear una nueva instancia de Prometheus, dividir el trabajo de recuperación en varios Prometheus y Querier agrega los resultados de varias consultas de Prometheus, lo que reduce la presión sobre un solo Prometheus;
Alta disponibilidad: Querier es un servicio sin estado que admite inherentemente el escalado horizontal y la alta disponibilidad. Store, Rule y Sidecar son servicios con estado, que también admiten alta disponibilidad en el caso de la implementación de copias múltiples, pero generarán redundancia de datos y tendrán que sacrificar espacio de almacenamiento;
Deduplicación de consultas: cada bloque de datos tendrá una etiqueta de grupo específica. Querier eliminará la etiqueta de grupo al realizar la consulta y combinará las secuencias con el mismo nombre de índice y etiqueta de acuerdo con el orden del tiempo. Aunque los datos del indicador provienen de diferentes fuentes de recopilación, solo responderá a un resultado en lugar de múltiples réplicas.

Beneficios del código abierto

Hoy, Cloud Wisdom tiene la plataforma de orquestación de visualización de datos de código abierto FlyFish. Al configurar el modelo de datos, proporciona a los usuarios cientos de componentes gráficos visuales, y la codificación cero puede lograr una gran pantalla visual genial que satisfaga sus propias necesidades comerciales. Al mismo tiempo, FlyFish también brinda capacidades de expansión flexibles, admite el desarrollo de componentes, funciones personalizadas y eventos globales y otras configuraciones, y puede garantizar un desarrollo y una entrega eficientes para escenarios de demanda complejos.

Haga clic en el enlace de la dirección a continuación e invite a todos a darle a FlyFish un Me gusta y enviar una estrella. Participe en el desarrollo de componentes y habrá más de 10 000 yuanes en efectivo esperándolo.

Dirección de GitHub: https://github.com/CloudWise-OpenSource/FlyFish

Dirección de albergue: https://gitee.com/CloudWise/fly-fish

Beneficio en efectivo de diez mil yuanes: http://bbs.aiops.cloudwise.com/t/Activity

Escanee Wechat para identificar el código QR a continuación, tenga en cuenta [Flying Fish] Únase al grupo de intercambio de desarrolladores de Flying Fish de la comunidad AIOps y comuníquese cara a cara con el proyecto FlyFish PMC ~

En la era nativa de la nube, comparación de herramientas de monitoreo populares y análisis de escenarios de uso