Cree un clúster web de alta disponibilidad basado en Nginx+Keepalived e implemente monitoreo y alarmas

Construir servidores relacionados

Planifique la dirección IP y el diagrama de arquitectura del clúster, y apague todos los SELINUX y firewalls

# 关闭SELINUX
sed -i '/^SELINUX=/ s/enforcing/disabled/' /etc/selinux/config
# 关闭防火墙
service firewalld stop
systemctl disable firewalld

web1	192.168.40.21	backendweb
web2	192.168.40.22	backendweb
web3	192.168.40.23	backendweb
lb1	192.168.40.31	equilibrador de carga 1
lb2	192.168.40.32	equilibrador de carga 2
dns, prometeo	192.168.40.137	Servidor DNS, servidor de monitoreo
nfs	192.168.40.138	servidor NFS

configuración del servidor DNS

Instalar paquete de enlace

yum install bind* -y

Iniciar proceso nombrado

[root@elk-node2 selinux]# service named start
Redirecting to /bin/systemctl start named.service
[root@elk-node2 selinux]# ps aux | grep named
named     44018  0.8  3.2 391060 60084 ?        Ssl  15:15   0:00 /usr/sbin/named -u named -c /etc/named.conf
root      44038  0.0  0.0 112824   980 pts/0    S+   15:15   0:00 grep --color=auto named

Modifique el archivo /etc/resolv.conf, agregue una línea y configure el servidor de nombres de dominio para esta máquina

nameserver 127.0.0.1

prueba. Analizado con éxito

[root@elk-node2 selinux]#  nslookup 
> www.qq.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
www.qq.com      canonical name = ins-r23tsuuf.ias.tencent-cloud.net.
Name:   ins-r23tsuuf.ias.tencent-cloud.net
Address: 121.14.77.221
Name:   ins-r23tsuuf.ias.tencent-cloud.net
Address: 121.14.77.201
Name:   ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:97c:2f:3003::77
Name:   ins-r23tsuuf.ias.tencent-cloud.net
Address: 240e:97c:2f:3003::6a

Utilice esta máquina como servidor de nombres de dominio para que otras máquinas puedan acceder a ella y modificar /etc/named.conf

listen-on port 53 {
    
     any; };
listen-on-v6 port 53 {
    
     any; };
allow-query     {
    
     any; };

Reiniciar servicio

service named restart

De esta forma, otras máquinas pueden utilizar la máquina 192.168.40.137 para la resolución de nombres de dominio.

configuración del servidor WEB

Configurar IP estática

entrar /etc/sysconfig/network-scripts/al directorio

Modifique el archivo ifcfg-ens33 para garantizar la comunicación mutua.

configuración web1IP

BOOTPROTO="none"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.40.21
PREFIX=24
GATEWAY=192.168.40.2
DNS1=114.114.114.114                       

configuración web2IP

BOOTPROTO="none"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.40.22
PREFIX=24
GATEWAY=192.168.40.2
DNS1=114.114.114.114    

configuración web3IP

BOOTPROTO="none"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.40.23
PREFIX=24
GATEWAY=192.168.40.2
DNS1=114.114.114.114    

Compilar e instalar nginx

Para compilar e instalar nginx, puedes leer mi blog sobre cómo iniciar y detener la instalación de Nginx.

Una vez completada la instalación, el acceso al navegador se realiza correctamente.

Configuración del equilibrador de carga

Utilice nginx para equilibrar la carga

lb1

Configurar IP estática

BOOTPROTO="none"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.40.31
PREFIX=24
GATEWAY=192.168.40.2
DNS1=114.114.114.114

Modifique los archivos en el directorio de instalación nginx.confy agregue lo siguiente

Carga de capa 7:> el flujo ascendente está en el bloque http y se reenvía según el protocolo http.

http {
    
    
   ……
    upstream lb1{
    
     # 后端真实的IP地址，在http块里
    ip_hash; # 使用ip_hash算法或least_conn;最小连接
    # 权重 192.168.40.21 weight=5;
	server 192.168.40.21;；
    server 192.168.40.22;
    server 192.168.40.23;
    }
    server {
    
    
        listen       80;
        ……
        location / {
    
    
	    #root   html; 注释掉，因为只是做代理，不是直接访问
        #index  index.html index.htm;
 		proxy_pass http://lb1; # 代理转发    
        }

Carga de capa 4:> el bloque de transmisión está al mismo nivel que el bloque http, el reenvío se basa en el puerto IP+

stream {
    
    
  upstream lb1{
    
    
        
  }
    server {
    
    
        listen 80; # 基于80端口转发
        proxy_pass lb1;
  }
  upstream dns_servers {
    
    
		least_conn;
		server 192.168.40.21:53;
        server 192.168.40.22:53;
        server 192.168.40.23:53;     
        }
        server {
    
    
        listen 53 udp; # 基于53端口转发
        proxy_pass dns_servers;
   }
}

Recargar nginx

nginx -s reload

El algoritmo de sondeo se utiliza de forma predeterminada, puede ver el efecto

lb2

Configurar IP estática

BOOTPROTO="none"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.40.32
PREFIX=24
GATEWAY=192.168.40.2
DNS1=114.114.114.114

Modifique los archivos en el directorio de instalación nginx.confy agregue lo siguiente

Carga de capa 7:> el flujo ascendente está en el bloque http y se reenvía según el protocolo http.

http {
    
    
   ……
    upstream lb2{
    
     # 后端真实的IP地址，在http块里
    ip_hash; # 使用ip_hash算法或least_conn;最小连接
    # 权重 192.168.40.21 weight=5;
	server 192.168.40.21;；
    server 192.168.40.22;
    server 192.168.40.23;
    }
    server {
    
    
        listen       80;
        ……
        location / {
    
    
	    #root   html; 注释掉，因为只是做代理，不是直接访问
        #index  index.html index.htm;
 		proxy_pass http://lb2; # 代理转发    
        }

Recargar nginx

nginx -s reload

Problema: el servidor back-end no conoce la dirección IP real a la que se accede, solo conoce la dirección IP del balanceador de carga, ¿cómo solucionarlo?

artículo de referencia

       Utilice la variable $remote_addrpara obtener la dirección IP del cliente, asígnela al X-Real-IPcampo y luego vuelva a cargarla

nginx -s reload

Todos los registros de modificación del servidor backend para obtener el valor de este campo

Comprobar si obtener la IP real del cliente

Pregunta: ¿Cuál es la diferencia entre la carga de Capa 4 y la carga de Capa 7?

artículo de referencia

1. 四层负载均衡（Layer 4 Load Balancing）: El equilibrio de carga de cuatro capas es una forma de realizar el equilibrio de carga en la capa de transporte (es decir, la capa de red). En el equilibrio de carga de cuatro capas, el dispositivo de equilibrio de carga 源IP地址、目标IP地址、源端口号、目标端口号reenvía la solicitud al servidor correspondiente de acuerdo con información como. Básicamente, solo se preocupa por las propiedades básicas de la conexión de red y no tiene conocimiento del contenido ni del protocolo de la solicitud.

   Las ventajas del equilibrio de carga de cuatro capas son la velocidad rápida y la alta eficiencia, y es adecuado para manejar una gran cantidad de conexiones de red, como los protocolos TCP y UDP. Sin embargo, tiene una comprensión limitada del contenido de la solicitud y no puede personalizar las estrategias de reenvío de acuerdo con las necesidades específicas de aplicaciones específicas.

2. 七层负载均衡（Layer 7 Load Balancing）: El equilibrio de carga de siete capas es un método de equilibrio de carga en la capa de aplicación. En el equilibrio de carga de siete capas, el dispositivo de equilibrio de carga puede profundizar en el protocolo de la capa de aplicación (como HTTP, HTTPS) para comprender el contenido y las características de la solicitud y reenviar inteligentemente la solicitud de acuerdo con la solicitud URL、请求头、会话信息等因素.

   El equilibrio de carga de Capa 7 puede implementar estrategias de reenvío más flexibles y personalizadas. Por ejemplo, las solicitudes se pueden distribuir a diferentes servidores backend según los nombres de dominio, las rutas URL, la información específica en los encabezados de las solicitudes, etc. Esto es útil cuando se trata de aplicaciones web, servicios API, etc. que tienen reglas y necesidades de enrutamiento específicas.

El equilibrio de carga de cuatro capas se basa principalmente en los atributos de conexión de red de la capa de transporte, lo cual es adecuado para escenarios de conexión de red a gran escala y de alta concurrencia, mientras que el equilibrio de carga de siete capas proporciona una comprensión profunda de las solicitudes en la capa de aplicación. y es adecuado para el reenvío según el contenido y las características de la solicitud Escenarios para el reenvío inteligente. En las aplicaciones reales, según las necesidades específicas y los tipos de aplicaciones, puede elegir un método de equilibrio de carga adecuado o combinar los dos para lograr un mejor rendimiento y escalabilidad.

Configuración de alta disponibilidad

Utilice keepalived para lograr alta disponibilidad

       Ambos balanceadores de carga están instalados con keepalived y la comunicación entre ellos se realiza a través del protocolo VRRP. Para conocer la introducción del protocolo VRRP, consulte el artículo.

yum install keepalived

Configuración VIP única

       Ingrese al directorio donde se encuentra el archivo de configuración /etc/keepalived/, edite el archivo de configuración keepalived.conf e inicie una instancia de vrrp

configuración lb1

vrrp_instance VI_1 {
    
        #启动一个实例
    state MASTER	    #角色为master
    interface ens33     #网卡接口
    virtual_router_id 150#路由id
    priority 100        #优先级
    advert_int 1        #宣告信息 间隔1s
    authentication {
    
        #认证信息
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
     #虚拟IP，对外提供服务
        192.168.40.51
    }
}

configuración lb2

vrrp_instance VI_1 {
    
    
    state BACKUP #角色为backup
    interface ens33
    virtual_router_id 150
    priority 50  #优先级比master要低
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.51
    }
}

Inicie keepalived y podrá ver el VIP en el equilibrador de carga con la máxima prioridad.

service keepalived start

Configuración doble VIP

       Ingrese al directorio donde se encuentra el archivo de configuración /etc/keepalived/, edite el archivo de configuración keepalived.conf e inicie dos vrrp para proporcionar servicios externos para mejorar el uso.

configuración lb1

vrrp_instance VI_1 {
    
        #启动一个实例
    state MASTER       #角色为master
    interface ens33     #网卡接口
    virtual_router_id 150#路由id
    priority 100        #优先级
    advert_int 1        #宣告信息
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.51 # 对外提供的IP
    }
}
vrrp_instance VI_2 {
    
       #启动第二个实例
    state BACKUP      #角色为backup
    interface ens33     #网卡接口
    virtual_router_id 160#路由id
    priority 50         #优先级
    advert_int 1        #宣告信息
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.52 # 对外提供的IP
    }
}

configuración lb2

vrrp_instance VI_1 {
    
    
    state BACKUP  #角色为backup
    interface ens33
    virtual_router_id 150
    priority 50
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.51
    }
}
vrrp_instance VI_2 {
    
    
    state MASTER  #角色为master
    interface ens33
    virtual_router_id 160
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.52
    }
}

Reinicie keepalived y podrá ver VIP en ambos balanceadores de carga.

service keepalived start

       Escriba un script check_nginx.shpara monitorear si Nginx se está ejecutando. Si Nginx se bloquea, no tiene sentido activar keepalived. Consume recursos y requiere un ajuste oportuno del estado activo y en espera.

#!/bin/bash
if [[ $(netstat -anplut| grep nginx|wc -l) -eq 1 ]];then
        exit 0
else
        exit 1
        # 关闭keepalived
        service keepalived stop
fi

permiso concedido

chmod +x check_nginx.sh 

       El script no se ejecutó correctamente. Hubo un problema al verificar el registro /var/log/messages. Resultó que no había espacio entre el nombre del script y los corchetes...

Configuración de lb1 después de agregar el script

! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     [email protected]
     [email protected]
     [email protected]
   }
   notification_email_from [email protected]
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
  #vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
vrrp_script chk_nginx {
    
    
script "/etc/keepalived/check_nginx.sh" # 外部脚本执行位置，使用绝对路径
interval 1
weight -60 # 修改后权重的优先值要小于backup
}

vrrp_instance VI_1 {
    
        #启动一个实例
    state MASTER
    interface ens33     #网卡接口
    virtual_router_id 150#路由id
    priority 100        #优先级
    advert_int 1        #宣告信息
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.51
    }
track_script {
    
     # 脚本名要有空格
chk_nginx # 调用脚本
}

}

vrrp_instance VI_2 {
    
        #启动一个实例
    state BACKUP
    interface ens33     #网卡接口
    virtual_router_id 170#路由id
    priority 50         #优先级
    advert_int 1        #宣告信息
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.40.52
    }
}

La configuración de lb2 es la misma que la de lb1, simplemente coloque el código ejecutado por el script en la parte maestra de lb2.

       进行nginx测试，发现双vip能够在nginx关闭的状态同时关闭keepalived并进行vip漂移

       Artículo de referencia sobre el uso de notificar (también puede lograr el efecto de cierre keepalived)

notify的用法：
  notify_master:当前节点成为master时，通知脚本执行任务(一般用于启动某服务，比如nginx,haproxy等)
  notify_backup:当前节点成为backup时，通知脚本执行任务(一般用于关闭某服务，比如nginx,haproxy等)
  notify_fault：当前节点出现故障，执行的任务; 
  例：当成为master时启动haproxy,当成为backup时关闭haproxy
  notify_master "/etc/keepalived/start_haproxy.sh start"
  notify_backup "/etc/keepalived/start_haproxy.sh stop"

Pregunta: ¿Qué es el cerebro dividido y cuáles son las posibles causas?

       El fenómeno del cerebro dividido se refiere a 主备服务器之间的通信故障una situación que hace que dos nodos piensen que son el nodo maestro al mismo tiempo y compitan por los siguientes motivos:

1. Partición de red: en un clúster que utiliza keepalived, si la red está particionada y la comunicación entre el nodo maestro y el nodo de respaldo se interrumpe, puede ocurrir un fenómeno de cerebro dividido.
2. ID de ruta virtual inconsistentes: los ID de ruta virtual se utilizan para identificar de forma única los nodos activos y de respaldo. Si la configuración de ID de ruta virtual es inconsistente, se producirán conflictos entre diferentes nodos, lo que puede hacer que los nodos se anuncien como nodos activos al mismo tiempo. , provocando un fenómeno de cerebro dividido.
3. 认证密码不一样：当认证密码不一致时，节点之间的通信将受阻，可能导致节点无法正常进行状态同步和故障切换，从而引发脑裂现象的发生。
4. 节点运行状态不同步：当主节点和备份节点之间的状态同步过程中出现错误或延迟，导致节点状态不一致，可能会引发脑裂现象。
5. 信号丢失：keepalived使用心跳机制检测节点状态，如果由于网络延迟或其他原因导致心跳信号丢失，可能会误判节点状态，从而引发脑裂现象。

问题：keepalived的三个进程？

1. Keepalived 主进程：负责加载并解析 Keepalived 配置文件，创建和管理 VRRP 实例，并监控实例状态。它还处理与其他 Keepalived 进程之间的通信。
2. Keepalived VRRP 进程：这是负责实现虚拟路由冗余协议功能的进程。每个启动的 VRRP 实例都会有一个对应的 VRRP 进程。它负责定期发送 VRRP 通告消息，监听其他节点发送的通告消息，并根据配置的优先级进行故障转移。
3. Keepalived Check Script 进程：这个进程用于执行用户定义的健康检查脚本。通过此进程，可以执行自定义的脚本来检测服务器的健康状态，并根据脚本的返回结果来更改 VRRP 实例的状态或触发故障转移。

NFS服务器配置

       使用nfs，让后端服务器到nfs服务器里获取数据，将nfs的服务器挂载到web服务器上，保证数据一致性。

配置静态IP

BOOTPROTO="none"
IPADDR=192.168.40.138
GATEWAY=192.168.40.2
DNS2=114.114.114.114
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"       

安装软件包

yum -y install rpcbind nfs-utils

启动服务，先启动rpc服务，再启动nfs服务

# 启动rpc服务
[root@nfs ~]# service rpcbind start
Redirecting to /bin/systemctl start rpcbind.service
[root@nfs ~]# systemctl enable rpcbind
# 启动nfs服务
[root@nfs ~]# service nfs-server start
Redirecting to /bin/systemctl start nfs-server.service
[root@nfs ~]# systemctl enable nfs-server

新建共享目录

新建/data/share/，自己写一个index.html查看效果

mkdir -p /data/share/

编辑配置文件vim /etc/exports

/data/share/ 192.168.40.0/24(rw,no_root_squash,all_squash,sync)

其中：

• /data/share/：共享文件目录
• 192.168.40.0/24：表示接受来自以 192.168.40.0 开头的IP地址范围的请求。
• (rw)：指定允许对目录进行读写操作。
• no_root_squash：指定不对root用户进行权限限制。它意味着在客户端上以root用户身份访问时，在服务器上也将以root用户身份进行访问。
• all_squash：指定将所有用户映射为匿名用户。它意味着在客户端上以任何用户身份访问时，在服务器上都将以匿名用户身份进行访问。
• sync：指定文件系统同步方式。sync 表示在写入操作完成之前，将数据同步到磁盘上。保障数据的一致性和可靠性，但可能会对性能产生影响。

重新加载nfs，让配置文件生效

systemctl reload nfs
exportfs -rv

web服务器挂载

       3台web服务器只需要安装rpcbind服务即可，无需安装nfs或开启nfs服务。

yum install rpcbind -y

web服务器端查看nfs服务器共享目录

[root@web1 ~]# showmount -e 192.168.40.138
Export list for 192.168.40.138:
/data/share 192.168.40.0/24
[root@web2 ~]# showmount -e 192.168.40.138
Export list for 192.168.40.138:
/data/share 192.168.40.0/24
[root@web3 ~]# showmount -e 192.168.40.138
Export list for 192.168.40.138:
/data/share 192.168.40.0/24

进行挂载，挂载到Nginx网页目录下

[root@web1 ~]# mount 192.168.40.138:/data/share /usr/local/shengxia/html
[root@web2 ~]# mount 192.168.40.138:/data/share /usr/local/shengxia/html
[root@web3 ~]# mount 192.168.40.138:/data/share /usr/local/shengxia/html

设置开机自动挂载nfs文件系统

vim /etc/rc.local
# 将这行直接接入/etc/rc.local文件末尾
mount -t nfs 192.168.40.138:/data/share /usr/local/shengxia/html

同时给/etc/rc.d/rc.local可执行权限

chmod /etc/rc.d/rc.local

看到这个效果就表示成功了

监控服务器配置

       下载prometheus和exporter进行监控，安装可以看我这篇博客
Prometheus、Grafana、cAdvisor的介绍、安装和使用

安装node-exporter

       prometheus安装好之后，在每个服务器都安装node-exporter，监控服务器状态 下载

       除了本机192.168.40.137以外，所有的服务器都下载，演示一个案例。其他服务器相同操作

解压文件

[root@web1 exporter]# ls
node_exporter-1.5.0.linux-amd64.tar.gz
[root@web1 exporter]# tar xf node_exporter-1.5.0.linux-amd64.tar.gz 
[root@web1 exporter]# ls
node_exporter-1.5.0.linux-amd64  node_exporter-1.5.0.linux-amd64.tar.gz

新建目录

[root@web1 exporter]# mkdir -p /node_exporter

复制node_exporter下的文件到指定的目录

[root@web1 exporter]# cp node_exporter-1.5.0.linux-amd64/* /node_exporter

在/root/.bashrc文件下修改PATH环境变量，将这行加到文件末尾，刷新一下

PATH=/node_exporter/:$PATH
source /root/.bashrc

放到后台启动运行

[root@web1 exporter]# nohup node_exporter --web.listen-address 192.168.40.21:8899 &

出现这个页面即成功

编写prometheus.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.40.137:9090"]
  - job_name: "nfs"
    static_configs:
      - targets: ["192.168.40.138:8899"]
  - job_name: "lb1"
    static_configs:
      - targets: ["192.168.40.31:8899"]
  - job_name: "lb2"
    static_configs:
      - targets: ["192.168.40.32:8899"]
  - job_name: "web1"
    static_configs:
      - targets: ["192.168.40.21:8899"]
  - job_name: "web2"
    static_configs:
      - targets: ["192.168.40.22:8899"]
  - job_name: "web3"
    static_configs:
      - targets: ["192.168.40.23:8899"]

重新启动prometheus

[root@dns-prom prometheus]# service prometheus restart

看到这个页面就表示监控成功了

安装alertmanager和钉钉插件

下载

[root@dns-prom prometheus]# wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
[root@dns-prom prometheus]# wget https://github.com/timonwong/prometheus-webhook-dingtalk/releases/download/v1.4.0/prometheus-webhook-dingtalk-1.4.0.linux-amd64.tar.gz

解压

[root@dns-prom prometheus]# tar xf alertmanager-0.23.0-rc.0.linux-amd64.tar.gz 
[root@dns-prom prometheus]# mv alertmanager-0.23.0-rc.0.linux-amd64 alertmanager
[root@dns-prom prometheus]# tar xf prometheus-webhook-dingtalk-1.4.0.linux-amd64.tar.gz 
[root@dns-prom prometheus]# mv prometheus-webhook-dingtalk-1.4.0.linux-amd64 prometheus-webhook-dingtalk

获取机器人webhook

获取允许访问的IP，使用curl ifconfig.me可以获得

[root@dns-prom alertmanager]# curl ifconfig.me
222.244.215.17

Modificar plantilla de alerta de DingTalk

#位置：/lianxi/prometheus/prometheus-webhook-dingtalk/contrib/templates/legacy/template.tmpl
[root@dns-prom legacy]# cat template.tmpl
{
    
    {
    
     define "ding.link.title" }}{
    
    {
    
     template "legacy.title" . }}{
    
    {
    
     end }}
{
    
    {
    
     define "ding.link.content" }}
{
    
    {
    
     if gt (len .Alerts.Firing) 0 -}}
告警列表:
{
    
    {
    
     template "__text_alert_list" .Alerts.Firing }}
{
    
    {
    
    - end }}
{
    
    {
    
     if gt (len .Alerts.Resolved) 0 -}}
恢复列表:
{
    
    {
    
     template "__text_resolve_list" .Alerts.Resolved }}
{
    
    {
    
    - end }}
{
    
    {
    
    - end }}

Modifique los archivos cofig y yml, agregue el token del webhook del robot y especifique el archivo de plantilla

[root@dns-prom prometheus-webhook-dingtalk]# cat config.yml 
templates:
  - /lianxi/prometheus/prometheus-webhook-dingtalk/contrib/templates/legacy/template.tmpl # 模板路径

targets:
  webhook2:
    url: https://oapi.dingtalk.com/robot/send?access_token=你自己的token

quedará prometheus-webhook-dingtalkregistrado como servicio

[root@dns-prom system]# pwd
/usr/lib/systemd/system
[root@dns-prom system]# cat webhook-dingtalk
[Unit]
Description=prometheus-webhook-dingtalk
Documentation=https://github.com/timonwong/prometheus-webhook-dingtalk
After=network.target

[Service]
ExecStart=/lianxi/prometheus/prometheus-webhook-dingtalk/prometheus-webhook-dingtalk  --config.file=/lianxi/prometheus/prometheus-webhook-dingtalk/config.yml
Restart=on-failure

[Install]
WantedBy=multi-user.target

Servicios de carga

[root@dns-prom system]# systemctl daemon-reload

Comienza el servicio

[root@dns-prom system]# service webhook-dingtalk start
Redirecting to /bin/systemctl start webhook-dingtalk.service

Escribir administrador de alertas

Modificar alertmanager.ymlarchivos

global:
  resolve_timeout: 5m

route: # 告警路由配置，定义如何处理和发送告警
  receiver: webhook
  group_wait: 30s
  group_interval: 1m
  repeat_interval: 4h
  group_by: [alertname]
  routes:
  - receiver: webhook
    group_wait: 10s

receivers: # 告警接收者配置，定义如何处理和发送告警
- name: webhook 
  webhook_configs:
   ### 注意注意，我在dingtalk的配置文件里用的是webhook2，要对上
  - url: http://192.168.40.137:8060/dingtalk/webhook2/send  # 告警 Webhook URL
    send_resolved: true # 是否发送已解决的告警。如果设置为 true，则在告警解决时发送通知

quedará alertmanagerregistrado como servicio

[Unit]
Description=alertmanager
Documentation=https://prometheus.io/
After=network.target

[Service]
ExecStart=/lianxi/prometheus/alertmanager/alertmanager --config.file=/lianxi/prometheus/alertmanager/alertmanager.yml 
Restart=on-failure

[Install]
WantedBy=multi-user.target

Servicios de carga

[root@dns-prom system]# systemctl daemon-reload

Controlar

Establecer archivo de alarma

Cree una regla de alarma para el archivo reglas.yml en el directorio de Prometheus

[root@dns-prom prometheus]# pwd
/lianxi/prometheus/prometheus
[root@dns-prom prometheus]# cat rules.yml 
groups:
  - name: host_monitoring
    rules:
      - alert: 内存报警
        expr: netdata_system_ram_MiB_average{
    
    chart="system.ram",dimension="free",family="ram"} < 800
        for: 2m
        labels:
          team: node
        annotations:
          Alert_type: 内存报警
          Server: '{
    
    {$labels.instance}}'
          explain: "内存使用量超过90%，目前剩余量为：{
    
    { $value }}M"
      - alert: CPU报警
        expr: netdata_system_cpu_percentage_average{
    
    chart="system.cpu",dimension="idle",family="cpu"} < 20
        for: 2m
        labels:
          team: node
        annotations:
          Alert_type: CPU报警
          Server: '{
    
    {$labels.instance}}'
          explain: "CPU使用量超过80%，目前剩余量为：{
    
    { $value }}"
      - alert: 磁盘报警
        expr: netdata_disk_space_GiB_average{
    
    chart="disk_space._",dimension="avail",family="/"} < 4
        for: 2m
        labels:
          team: node
        annotations:
          Alert_type: 磁盘报警
          Server: '{
    
    {$labels.instance}}'
          explain: "磁盘使用量超过90%，目前剩余量为：{
    
    { $value }}G"
      - alert: 服务告警
        expr: up == 0
        for: 2m
        labels:
          team: node
        annotations:
          Alert_type: 服务报警
          Server: '{
    
    {$labels.instance}}'
          explain: "netdata服务已关闭"

Modifique el archivo prometheus.yml alertmanagerpara asociarlo con

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["192.168.40.137:9093"]

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  - "/lianxi/prometheus/prometheus/rules.yml" # 告警模板路径
  # - "first_rules.yml"
  # - "second_rules.yml"

Reinicie el servicio prometheus

[root@dns-prom prometheus]# service prometheus restart

Puedes ver los datos de seguimiento.

Simule el tiempo de inactividad del servidor, cierre web1 y active una alarma

DingTalk recibió una alerta

instalar grafana

Descargue el paquete de software Grafana del sitio web oficial de Grafana e instálelo de acuerdo con la documentación oficial.

root@dns-prom grafana]# yum install -y https://dl.grafana.com/enterprise/release/grafana-enterprise-9.5.1-1.x86_64.rpm

Iniciar grafana

[root@dns-prom grafana]# service grafana-server restart
Restarting grafana-server (via systemctl):                 [  确定  ]

Para conocer el proceso de operación específico, consulte este documento Introducción, instalación y uso de Prometheus, Grafana y cAdvisor.

Simplemente elige una buena plantilla y podrás mostrarla.

Realizar pruebas de estrés

Instale el software ab y simule la solicitud.

yum install ab -y

Simule continuamente solicitudes para comprender la cantidad de simultaneidad del clúster.