Han pasado casi dos meses desde que lanzamos SCUMM (Severalnines ClusterControl Unified Management and Monitoring). SCUMM utiliza Prometheus como método subyacente para recopilar datos de series temporales de exportadores que se ejecutan en instancias de bases de datos y balanceadores de carga. Este blog le mostrará cómo solucionar problemas cuando los exportadores de Prometheus no se están ejecutando, o si los gráficos no muestran datos o muestran "Sin puntos de datos".
¿Qué es Prometeo?
Prometheus es un sistema de monitoreo de código abierto con un modelo de datos dimensional, un lenguaje de consulta flexible, una base de datos de series de tiempo eficiente y un enfoque de alerta moderno. Es una plataforma de monitoreo que recopila métricas de objetivos monitoreados mediante el raspado de puntos finales HTTP de métricas en estos objetivos. Proporciona datos dimensionales, consultas potentes, excelente visualización, almacenamiento eficiente, operación simple, alertas precisas, muchas bibliotecas de clientes y muchas integraciones.
Prometheus en acción para SCUMM Dashboards
Prometheus recopila datos de métricas de los exportadores, y cada exportador se ejecuta en una base de datos o en un host de equilibrador de carga. El siguiente diagrama muestra cómo estos exportadores están vinculados con el servidor que aloja el proceso de Prometheus. Muestra que el nodo ClusterControl tiene Prometheus ejecutándose donde también ejecuta process_exporter y node_exporter.
El diagrama muestra que Prometheus se está ejecutando en el host y los exportadores de ClusterControl process_exporter y nodo_exportador también se están ejecutando para recopilar métricas de su propio nodo. Opcionalmente, puede hacer que su host ClusterControl también sea el destino en el que puede configurar HAProxy o ProxySQL.
Para los nodos de clúster anteriores (nodo1, nodo2 y nodo3), puede ejecutar mysqld_exporter o postgres_exporter, que son los agentes que extraen datos internamente en ese nodo y los pasan al servidor Prometheus y los almacenan en su propio almacenamiento de datos. Puede ubicar sus datos físicos a través de /var/lib/prometheus/data dentro del host donde está configurado Prometheus.
Cuando configura Prometheus, por ejemplo, en el host ClusterControl, debe tener abiertos los siguientes puertos. Ver a continuación:
[[email protected] share]# netstat -tnvlp46|egrep 'ex[p]|prometheu[s]'
tcp6 0 0 :::9100 :::* LISTEN 16189/node_exporter
tcp6 0 0 :::9011 :::* LISTEN 19318/process_expor
tcp6 0 0 :::42004 :::* LISTEN 16080/proxysql_expo
tcp6 0 0 :::9090 :::* LISTEN 31856/prometheusSegún el resultado, también tengo ProxySQL ejecutándose en el host testccnode en el que está alojado ClusterControl.
Problemas comunes con SCUMM Dashboards usando Prometheus
Cuando los paneles están habilitados, ClusterControl instalará e implementará binarios y exportadores como node_exporter, process_exporter, mysqld_exporter, postgres_exporter y daemon. Estos son los conjuntos comunes de paquetes para los nodos de la base de datos. Cuando estos están configurados e instalados, los siguientes comandos daemon se activan y ejecutan como se ve a continuación:
[[email protected] bin]# ps axufww|egrep 'exporte[r]'
prometh+ 3604 0.0 0.0 10828 364 ? S Nov28 0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+ 3605 0.2 0.3 256300 14924 ? Sl Nov28 4:06 \_ process_exporter
prometh+ 3838 0.0 0.0 10828 564 ? S Nov28 0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+ 3839 0.0 0.4 44636 15568 ? Sl Nov28 1:08 \_ node_exporter
prometh+ 4038 0.0 0.0 10828 568 ? S Nov28 0:00 daemon --name=mysqld_exporter --output=/var/log/prometheus/mysqld_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/mysqld_exporter.pid --user=prometheus -- mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_status
prometh+ 4039 0.1 0.2 17368 11544 ? Sl Nov28 1:47 \_ mysqld_exporter --collect.perf_schema.eventswaits --collect.perf_schema.file_events --collect.perf_schema.file_instances --collect.perf_schema.indexiowaits --collect.perf_schema.tableiowaits --collect.perf_schema.tablelocks --collect.info_schema.tablestats --collect.info_schema.processlist --collect.binlog_size --collect.global_status --collect.global_variables --collect.info_schema.innodb_metrics --collect.slave_statusPara un nodo de PostgreSQL,
[[email protected] vagrant]# ps axufww|egrep 'ex[p]'
postgres 1901 0.0 0.4 1169024 8904 ? Ss 18:00 0:04 \_ postgres: postgres_exporter postgres ::1(51118) idle
prometh+ 1516 0.0 0.0 10828 360 ? S 18:00 0:00 daemon --name=process_exporter --output=/var/log/prometheus/process_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/process_exporter.pid --user=prometheus -- process_exporter
prometh+ 1517 0.2 0.7 117032 14636 ? Sl 18:00 0:35 \_ process_exporter
prometh+ 1700 0.0 0.0 10828 572 ? S 18:00 0:00 daemon --name=node_exporter --output=/var/log/prometheus/node_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/node_exporter.pid --user=prometheus -- node_exporter
prometh+ 1701 0.0 0.7 44380 14932 ? Sl 18:00 0:10 \_ node_exporter
prometh+ 1897 0.0 0.0 10828 568 ? S 18:00 0:00 daemon --name=postgres_exporter --output=/var/log/prometheus/postgres_exporter.log --env=HOME=/var/lib/prometheus --env=PATH=/usr/local/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin --env=DATA_SOURCE_NAME=postgresql://postgres_exporter:[email protected]:5432/postgres?sslmode=disable --chdir=/var/lib/prometheus --pidfile=/var/run/prometheus/postgres_exporter.pid --user=prometheus -- postgres_exporter
prometh+ 1898 0.0 0.5 16548 11204 ? Sl 18:00 0:06 \_ postgres_exporterTiene los mismos exportadores que para un nodo MySQL, pero difiere solo en postgres_exporter ya que este es un nodo de base de datos PostgreSQL.
Sin embargo, cuando un nodo sufre una interrupción de energía, un bloqueo del sistema o un reinicio del sistema, estos exportadores dejarán de funcionar. Prometheus informará que un exportador está inactivo. ClusterControl toma muestras del propio Prometheus y solicita los estados del exportador. Por lo tanto, actúa sobre esta información y reiniciará el exportador si está inactivo.
Sin embargo, tenga en cuenta que los exportadores que no se han instalado a través de ClusterControl, no se reiniciarán después de un bloqueo. La razón es que no son monitoreados por systemd o un demonio que actúa como un script de seguridad que reiniciaría un proceso en caso de bloqueo o apagado anormal. Por lo tanto, la captura de pantalla a continuación mostrará cómo se ve cuando los exportadores no se están ejecutando. Ver a continuación:
y en PostgreSQL Dashboard, tendrá el mismo icono de carga con la etiqueta "Sin puntos de datos" en el gráfico. Ver a continuación:
Por lo tanto, estos pueden solucionarse a través de varias técnicas que seguirán en las siguientes secciones.
Resolución de problemas con Prometheus
Los agentes de Prometheus, conocidos como exportadores, utilizan los siguientes puertos:9100 (node_exporter), 9011 (process_exporter), 9187 (postgres_exporter), 9104 (mysqld_exporter), 42004 (proxysql_exporter) y el propio 9090, que es propiedad de Prometheus. proceso. Estos son los puertos para estos agentes que utiliza ClusterControl.
Para comenzar a solucionar los problemas del SCUMM Dashboard, puede comenzar verificando los puertos abiertos desde el nodo de la base de datos. Puede seguir las listas a continuación:
-
Compruebe si los puertos están abiertos
por ejemplo
## Use netstat and check the ports [[email protected] vagrant]# netstat -tnvlp46|egrep 'ex[p]' tcp6 0 0 :::9100 :::* LISTEN 5036/node_exporter tcp6 0 0 :::9011 :::* LISTEN 4852/process_export tcp6 0 0 :::9187 :::* LISTEN 5230/postgres_exporPuede haber una posibilidad de que los puertos no estén abiertos debido a un firewall (como iptables o firewalld) que bloquea la apertura del puerto o el demonio de proceso en sí no se está ejecutando.
-
Use curl desde el monitor host y verifique si el puerto está accesible y abierto.
por ejemplo
## Using curl and grep mysql list of available metric names used in PromQL. [[email protected] prometheus]# curl -sv mariadb_g01:9104/metrics|grep 'mysql'|head -25 * About to connect() to mariadb_g01 port 9104 (#0) * Trying 192.168.10.10... * Connected to mariadb_g01 (192.168.10.10) port 9104 (#0) > GET /metrics HTTP/1.1 > User-Agent: curl/7.29.0 > Host: mariadb_g01:9104 > Accept: */* > < HTTP/1.1 200 OK < Content-Length: 213633 < Content-Type: text/plain; version=0.0.4; charset=utf-8 < Date: Sat, 01 Dec 2018 04:23:21 GMT < { [data not shown] # HELP mysql_binlog_file_number The last binlog file number. # TYPE mysql_binlog_file_number gauge mysql_binlog_file_number 114 # HELP mysql_binlog_files Number of registered binlog files. # TYPE mysql_binlog_files gauge mysql_binlog_files 26 # HELP mysql_binlog_size_bytes Combined size of all registered binlog files. # TYPE mysql_binlog_size_bytes gauge mysql_binlog_size_bytes 8.233181e+06 # HELP mysql_exporter_collector_duration_seconds Collector time duration. # TYPE mysql_exporter_collector_duration_seconds gauge mysql_exporter_collector_duration_seconds{collector="collect.binlog_size"} 0.008825006 mysql_exporter_collector_duration_seconds{collector="collect.global_status"} 0.006489491 mysql_exporter_collector_duration_seconds{collector="collect.global_variables"} 0.00324821 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.innodb_metrics"} 0.008209824 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.processlist"} 0.007524068 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tables"} 0.010236411 mysql_exporter_collector_duration_seconds{collector="collect.info_schema.tablestats"} 0.000610684 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.eventswaits"} 0.009132491 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_events"} 0.009235416 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.file_instances"} 0.009451361 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.indexiowaits"} 0.009568397 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tableiowaits"} 0.008418406 mysql_exporter_collector_duration_seconds{collector="collect.perf_schema.tablelocks"} 0.008656682 mysql_exporter_collector_duration_seconds{collector="collect.slave_status"} 0.009924652 * Failed writing body (96 != 14480) * Closing connection 0Idealmente, encontré este enfoque factible para mí porque puedo grep y depurar desde la terminal fácilmente.
-
¿Por qué no usar la interfaz de usuario web?
-
Prometheus expone el puerto 9090 que utiliza ClusterControl en nuestros paneles SCUMM. Aparte de esto, los puertos que exponen los exportadores también se pueden usar para solucionar problemas y determinar los nombres de métricas disponibles usando PromQL. En el servidor donde se ejecuta Prometheus, puede visitar http://
:9090/targets . La siguiente captura de pantalla lo muestra en acción:
y al hacer clic en "Puntos finales", puede verificar las métricas tan bien como en la siguiente captura de pantalla:
En lugar de usar la dirección IP, también puede verificar esto localmente a través de localhost en ese nodo específico, como visitar http://localhost:9104/metrics en una interfaz de interfaz de usuario web o usando cURL.
Ahora, si volvemos a los “Objetivos ”, puede ver la lista de nodos donde puede haber un problema con el puerto. Las razones que podrían causar esto se enumeran a continuación:
- El servidor está caído
- No se puede acceder a la red o los puertos no están abiertos debido a que se está ejecutando un firewall
- El daemon no se está ejecutando donde
_exporter no está funcionando. Por ejemplo, mysqld_exporter no se está ejecutando.
-
Cuando estos exportadores se están ejecutando, puede iniciar y ejecutar el proceso usando daemon dominio. Puede consultar los procesos en ejecución disponibles que usé en el ejemplo anterior o que mencioné en la sección anterior de este blog.
¿Qué pasa con esos gráficos "sin puntos de datos" en mi tablero?
SCUMM Dashboards presenta un escenario de caso de uso general que MySQL usa comúnmente. Sin embargo, existen algunas variables cuando la invocación de dicha métrica podría no estar disponible en una versión particular de MySQL o un proveedor de MySQL, como MariaDB o Percona Server.
Permítanme mostrar un ejemplo a continuación:
Este gráfico se tomó en un servidor de base de datos que se ejecuta en una versión 10.3.9-MariaDB-log MariaDB Server con wsrep_patch_version de la instancia wsrep_25.23. Ahora la pregunta es, ¿por qué no se carga ningún punto de datos? Bueno, cuando consulté el nodo por un estado de edad del punto de control, revela que está vacío o que no se encontró ninguna variable. Ver a continuación:
MariaDB [(none)]> show global status like 'Innodb_checkpoint_max_age';
Empty set (0.000 sec)No tengo idea de por qué MariaDB no tiene esta variable (háganoslo saber en la sección de comentarios de este blog si tiene la respuesta). Esto contrasta con Percona XtraDB Cluster Server donde existe la variable Innodb_checkpoint_max_age. Ver a continuación:
mysql> show global status like 'Innodb_checkpoint_max_age';
+---------------------------+-----------+
| Variable_name | Value |
+---------------------------+-----------+
| Innodb_checkpoint_max_age | 865244898 |
+---------------------------+-----------+
1 row in set (0.00 sec)Sin embargo, lo que esto significa es que puede haber gráficos que no tengan puntos de datos recopilados porque no se recopilan datos en esa métrica en particular cuando se ejecutó una consulta de Prometheus.
Sin embargo, un gráfico que no tiene puntos de datos no significa que su versión actual de MySQL o su variante no lo soporte. Por ejemplo, hay ciertos gráficos que requieren ciertas variables que deben configurarse correctamente o habilitarse.
La siguiente sección mostrará cuáles son estos gráficos.
Gráfico de reducción de la condición del índice (ICP)
Este gráfico ha sido mencionado en mi blog anterior. Se basa en una variable global de MySQL llamada innodb_monitor_enable. Esta variable es dinámica, por lo que puede configurarla sin un reinicio completo de su base de datos MySQL. También requiere innodb_monitor_enable =module_icp o puede establecer esta variable global en innodb_monitor_enable =all. Por lo general, para evitar tales casos y confusiones sobre por qué dicho gráfico no muestra ningún punto de datos, es posible que deba usar todos pero con cuidado. Puede haber cierta sobrecarga cuando esta variable está activada y configurada para todos.
Gráficos de esquema de rendimiento de MySQL
Entonces, ¿por qué estos gráficos muestran "No hay puntos de datos"? Cuando crea un clúster usando ClusterControl usando nuestras plantillas, de forma predeterminada definirá las variables performance_schema. Por ejemplo, se establecen estas variables a continuación:
performance_schema = ON
performance-schema-max-mutex-classes = 0
performance-schema-max-mutex-instances = 0Sin embargo, si performance_schema =OFF, entonces esa es la razón por la cual los gráficos relacionados mostrarían "Sin puntos de datos".
Pero tengo performance_schema habilitado, ¿por qué otros gráficos siguen siendo un problema?
Bueno, todavía hay gráficos que requieren que se establezcan múltiples variables. Esto ya se ha tratado en nuestro blog anterior. Por lo tanto, debe establecer innodb_monitor_enable =all y userstat=1. El resultado se vería así:
Sin embargo, observo que en la versión de MariaDB 10.3 (particularmente 10.3.11), establecer performance_schema=ON completará las métricas necesarias para el Tablero de esquema de rendimiento de MySQL. Esta es una gran ventaja porque no tiene que configurar innodb_monitor_enable=ON, lo que agregaría una sobrecarga adicional en el servidor de la base de datos.
Solución avanzada de problemas
¿Hay alguna solución de problemas avanzada que pueda recomendar? ¡Sí hay! Sin embargo, necesita algunas habilidades de JavaScript, al menos. Dado que SCUMM Dashboards que usan Prometheus se basa en gráficos altos, la forma en que las métricas que se usan para las solicitudes de PromQL se pueden determinar a través del script app.js que se muestra a continuación:
Entonces, en este caso, estoy usando DevTools de Google Chrome e intenté buscar Performance Schema Waits (Events) . ¿Cómo puede ayudar esto? Bueno, si miras los objetivos, verás:
targets: [{
expr: 'topk(5, rate(mysql_perf_schema_events_waits_total{instance="$instance"}[$interval])>0) or topk(5, irate(mysql_perf_schema_events_waits_total{instance="$instance"}[5m])>0)',
legendFormat: "{{event_name}} "
}]
Ahora, puede usar la métrica solicitada, que es mysql_perf_schema_events_waits_total. Puede verificar eso, por ejemplo, yendo a http://
¡Recuperación automática de ClusterControl al rescate!
Por último, la pregunta principal es, ¿existe una manera fácil de reiniciar los exportadores fallidos? ¡Sí! Mencionamos anteriormente que ClusterControl observa el estado de las exportaciones y las reinicia si es necesario. En caso de que note que SCUMM Dashboards no carga gráficos normalmente, asegúrese de tener habilitada la Recuperación automática. Vea la imagen a continuación:
Cuando está habilitado, esto asegurará que los
También es posible reinstalar o reconfigurar los exportadores.
Conclusión
En este blog, vimos cómo ClusterControl usa Prometheus para ofrecer SCUMM Dashboards. Proporciona un poderoso conjunto de funciones, desde datos de monitoreo de alta resolución y gráficos enriquecidos. Ha aprendido que con PromQL, puede determinar y solucionar problemas en nuestros paneles SCUMM, lo que le permite agregar datos de series temporales en tiempo real. También puede generar gráficos o ver a través de la consola todas las métricas que se han recopilado.
También aprendió a depurar nuestros paneles SCUMM, especialmente cuando no se recopilan puntos de datos.
Si tiene preguntas, agregue sus comentarios o háganoslo saber a través de nuestros foros de la comunidad.
