Práctica del sistema de monitoreo ptomrtheus para realizar la alerta temprana de microrobots empresariales

Tabla de contenido

Sobre la arquitectura de Prometeo

Implementación de prometheus HA

Involucrando componentes y versiones.

Ruta de adquisición del paquete de instalación

implementación del administrador de alertas

despliegue de grafana

implementación de nginx

---

Recientemente se ha restablecido el sistema de seguimiento de la empresa, en comparación con el sistema de seguimiento actual, Zabbix sigue siendo el que utiliza los recursos más básicos y se ha actualizado la versión, además, acaba de llegar la versión v5 de Nightingale. Se lanzó recientemente, y antes también se han realizado investigaciones, y esta última actualmente admite Prometheus como fuente de datos.

Al final elegí Prometheus porque el tiempo era escaso, dada la situación actual de la empresa era más adecuado usar Prometheus, por lo que se hizo un seguimiento de recursos básicos, puertos y capas de aplicaciones con Prometheus, si había alarmas. , el plan inicial era utilizar el robot empresarial WeChat para implementar Seguimiento Puede agregar alertas por correo electrónico.

Además de Prometheus, también hay monitoreo de apm. Después de comparar skyworing, pinpoint y cat, planeo usar pinpoint para implementarlo, que se presentará en detalle en un artículo posterior.

De lo contrario, utilice elk para recopilar registros y luego supervise algunas de las respuestas a las solicitudes de ng. Si algunos registros de back-end informan errores anormales, también serán monitoreados.

Versión Nightingale v5 que se ha investigado y practicado antes:

Sobre la arquitectura de Prometeo

La idea inicial era construir un clúster federado y usar victoriametrics, pero después de estimar el uso, resultó que no se usaría.

Una idea inicial fue esta:

En la práctica final, en realidad no hice esto. Según el escenario real, en realidad hice un HA, como se muestra a continuación:

Para Prometheus, se implementará de esta manera más adelante. Luego, con respecto a algunos agentes de cobranza y alarmas posteriores, puede ver la siguiente imagen:

Implementación de prometheus HA

Involucrando componentes y versiones.

prometheus 2.36.0nginx 1.6.2alertmanager 0.24.0grafana 8.5.3

Ruta de adquisición del paquete de instalación

prometheus：https://github.com/prometheus/prometheus/releases/download/v2.36.1/prometheus-2.36.1.linux-amd64.tar.gzalerthttps://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gzgrafanawget https://dl.grafana.com/enterprise/release/grafana-enterprise-8.5.6-1.x86_64.rpmnginx

despliegue de prometeo

Entre ellos, prometheus y alert se instalan mediante paquetes tar, nginx se instala mediante compilación, grafana se instala mediante paquetes rpm y prometheus se administra mediante systremctl.

La implementación es realmente muy simple.

cd /datatar -xvf prometheus-2.36.0.linux-amd64.tar.gzmv prometheus-2.36.0.linux-amd64 prometheusmkdir -p /data/prometheus/{log,data}

Luego modifique el archivo de configuración, puede echar un vistazo al archivo de configuración actual, que implica principalmente la configuración del trabajo y la configuración de alertas.

global:  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.  # scrape_timeout is set to the global default (10s).alerting:  alertmanagers:    - static_configs:        - targets: ['192.168.200.9:9093']rule_files:  - "rules/*_rules.yml"  # - "first_rules.yml"  # - "second_rules.yml"scrape_configs:  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.  - job_name: "prometheus"    # metrics_path defaults to '/metrics'    # scheme defaults to 'http'.    static_configs:      - targets: ["192.168.x.x:9090","192.168.x.1:9090"]  - job_name: 'linux_base'    file_sd_configs:    - refresh_interval: 1m      files:      - config_exporter.json  - job_name: blackbox_tcp    scrape_interval: 1m    metrics_path: /probe    params:      module: [tcp_connect]      file_sd_configs:    - refresh_interval: 1m      files:      - config_port.json    relabel_configs:      - source_labels: [__address__]        target_label: __param_target      - source_labels: [__param_target]        target_label: instance      - target_label: __address__        replacement: 192.168.x.2:9115

Mis archivos de configuración node_exporter y blackbox exportador están colgados afuera y admiten actualizaciones en caliente.

config_exporter.json

config_port.json

Para una configuración específica, consulte:

[  {
   
       "targets": [ "192.168.x.x:9100"],    "labels": {
   
         "env": "yw"    }  }]

Prometheus es administrado por systemctl

gato /usr/lib/systemd/system/prometheus.service

[Unit]Description=PrometheusAfter=network.target

[Service]Type=simpleEnvironment="GOMAXPROCS=4"User=rootExecReload=/bin/kill -HUP $MAINPIDExecStart=/data/prometheus/prometheus \  --config.file=/data/prometheus/prometheus.yml \  --storage.tsdb.path=/data/prometheus/data \  --storage.tsdb.retention=30d \  --web.console.libraries=/data/prometheus/console_libraries \  --web.console.templates=/data/prometheus/consoles \  --web.listen-address=0.0.0.0:9090 \  --web.read-timeout=5m \  --web.max-connections=10 \  --query.max-concurrency=20 \  --query.timeout=2m \  --web.enable-lifecyclePrivateTmp=truePrivateDevices=trueProtectHome=trueNoNewPrivileges=trueLimitNOFILE=infinityReadWriteDirectories=/data/prometheusProtectSystem=fullSyslogIdentifier=prometheusRestart=always[Install]WantedBy=multi-user.target

Después de la configuración, debe restablecer

recarga-demonio systemctl

implementación del administrador de alertas

tar -xvf alertmanager-0.24.0.linux-amd64.tar.gz

Modifique el archivo de configuración. Debido a que la alarma se envía a través del robot WeChat, se crea un servicio web a través de Python y luego se configura un enlace web para lograr esto.

route:  group_by: ['alertname']  group_wait: 30s  group_interval: 5m  repeat_interval: 1h  receiver: 'web.hook'receivers:  - name: 'web.hook'    webhook_configs:      - url: 'http://192.168.x.x:5000'inhibit_rules:  - source_match:      severity: 'critical'    target_match:      severity: 'warning'    equal: ['alertname', 'dev', 'instance']

Si se emite la alarma, probablemente se verá así:

【恢复】生产环境 blackbox_network_stats 有报警恢复告警级别: critical 告警类型: blackbox_network_stats 告警主机: 192.168.x.x:9100 告警系统: ops 告警详情: This requires immediate action! 告警状态: resolved 触发时间: 2022-06-16 11:05:48 +08:00 触发结束时间: 2022-06-16 16:06:48 +08:00

No escribiré sobre el servicio Python específico aquí. Si es necesario, puedes dejar un mensaje en segundo plano más tarde.

despliegue de grafana

En este caso es muy sencillo, despliegue directo de rpm.

rpm -ivh grafana-8.5.3-1.x86_64.rpm

Para Grafana, es más bien una pantalla de tablero, con nodos y cajas negras agregados aquí. Hay muchos ejemplos maduros en Internet que se pueden usar directamente.

implementación de nginx

Se utiliza principalmente para cargar Prometheus y también para representar algunos componentes.

Simplemente compila e instala.

En este caso, se implementó un conjunto del sistema de monitoreo más básico y se implementaron alarmas a través del robot empresarial WeChat. Lo siguiente es una implementación de clúster de Pinpoint y una implementación de clúster de ELK.

De hecho, la implementación es solo el primer paso y los usos posteriores son importantes.