Surveillance et alarme Nginx Upstream

J'ai écrit un article avant, présentant comment Nginx surveille le trafic de chaque serveur , principalement en ajoutant un module d'état tiers pour afficher l'état de tous les serveurs et en amont. Ensuite, les gens demandent toujours s'il existe un moyen de surveiller en amont et d'alerter , je vais donc le présenter aujourd'hui., Compléter les méthodes de surveillance et d'alerte en amont


Application: Nginx / Tengine

模块 : ngx_http_upstream_check_module

Surveillance: zabbix

Alerte: Entreprise WeChat / Dingding


Parce que l'amont de nginx est passif par défaut et ne sera pas activement surveillé, le module upstream_check de tengine est utilisé directement ici


Si vous êtes tengine, tant qu'il s'agit de la version 1.4 ou supérieure, le module sera ouvert par défaut. Si vous êtes nginx, vous devez recompiler nginx et ajouter le module. La méthode de compilation n'est pas grand-chose à dire ici. Téléchargez le code source et ajoutez-le avec --add-module Compilez simplement


Le module upstream_check fournit une fonction active de vérification de l'état du serveur back-end. Voici quelques instructions fournies par le module


  • Chèque

Syntaxe: check interval = millisecondes [fall = count] [rise = count] [timeout = millisecondes] [default_down = true | false] [type = tcp | http | ssl_hello | mysql | ajp] [port = check_port] 
Par défaut: interval = 30000 fall = 5 rise = 2 timeout = 1000 default_down = true type = tcp 
Contexte: amont
 
 

Cette commande peut activer la fonction de vérification de l'état du serveur principal. La signification des paramètres après la commande est:

interval : l' intervalle des paquets de contrôle de santé envoyés au backend

fall (fall_count) : si le nombre d'échecs consécutifs atteint fall_count, le serveur est considéré comme arrêté

rise (rise_count) : si le nombre de succès consécutifs atteint rise_count, le serveur est considéré comme
expiration du délai d' expiration : le délai d'expiration de la demande de santé du back-end

default_down : définit l'état initial du serveur, s'il est vrai, cela signifie que la valeur par défaut est en panne

type : le type de package de vérification de l' état, prend désormais en charge les types multiples suivants

  • tcp: connexion tcp simple, si la connexion est réussie, le backend est normal

  • ssl_hello: envoyer un package SSL Hello initial et accepter le package SSL Hello du serveur

  • http: Envoyez une requête HTTP et évaluez si le backend est actif par l'état du paquet de réponse du backend

  • mysql: connectez-vous au serveur mysql et jugez si le backend est actif en recevant le paquet de salutation du serveur

  • ajp: Envoyez le paquet Cping du protocole AJP au backend, et jugez si le backend est vivant en recevant le paquet Cpong

port : spécifiez le port de vérification du serveur principal. Vous pouvez spécifier le port du serveur principal qui est différent du service réel. Par exemple, le serveur principal fournit une application sur le port 443. Vous pouvez vérifier le port état du port 80 pour déterminer la santé du back-end. La valeur par défaut est 0, ce qui signifie que le port est le même que le port de service réel fourni par le serveur principal. Cette option apparaît dans Tengine-1.4.0


  • check_keepalive_requests

Syntaxe: check_keepalive_requests request_num 
Par défaut: 1 
Contexte: amont

Cette commande peut configurer le nombre de requêtes envoyées par une connexion. La valeur par défaut est 1, ce qui signifie que Tengine fermera la connexion après avoir effectué une requête.


  • check_http_send

Syntaxe: check_http_send http_packet 
Par défaut: "GET / HTTP / 1.0" 
Contexte: en amont

Cette commande peut configurer le contenu de la demande envoyée par le package de vérification de l'état http. Afin de réduire la quantité de données transmises, la méthode "HEAD" est recommandée. Lorsqu'une connexion longue est utilisée pour la vérification de l'état, l'en-tête de la demande keep-alive doit être ajouté à la commande, tel que: "HEAD / HTTP / 1.1 \ r \ nConnexion: keep-alive \ r \ n \ r \ n" . Dans le même temps, dans le cas de l'utilisation de la méthode "GET", la taille de l'URI de la requête ne doit pas être trop grande pour garantir que la transmission puisse être effectuée dans un délai d'un intervalle, sinon elle sera considérée comme un serveur back-end ou anomalie du réseau par le module de vérification de l'état


  • check_http_expect_alive

Syntaxe: check_http_expect_alive [http_2xx | http_3xx | http_4xx | http_5xx] 
Par défaut: http_2xx | 
Contexte http_3xx : en amont

Cette commande spécifie l'état de réussite de la réponse HTTP. Par défaut, l'état de 2XX et 3XX est considéré comme sain.


  • check_shm_size

Syntaxe: check_shm_size size 
Par défaut: 1M 
Contexte: http

L'état de vérification de l'état de tous les serveurs principaux est stocké dans la mémoire partagée. Cette commande peut définir la taille de la mémoire partagée. La valeur par défaut est 1M, si vous avez plus de 1000 serveurs et qu'une erreur se produit lors de la configuration, vous devrez peut-être augmenter la taille de la mémoire


  • check_status

Syntaxe: check_status [html | csv | json] 
Par défaut: check_status html 
Contexte: location

显示服务器的健康状态页面。该指令需要在http块中配置。在Tengine-1.4.0以后,你可以配置显示页面的格式。支持的格式有: html、csv、 json。默认类型是html。你也可以通过请求的参数来指定格式,假设‘/status’是你状态页面的URL, format参数改变页面的格式

比如:

/status?format=html
/status?format=csv
/status?format=json

下面是一个HTML状态页面的例子(server number是后端服务器的数量,generation是Nginx reload的次数。Index是服务器的索引,Upstream是在配置中upstream的名称,Name是服务器IP,Status是服务器的状态,Rise是服务器连续检查成功的次数,Fall是连续检查失败的次数,Check type是检查的方式,Check port是后端专门为健康检查设置的端口)

图片

下面是json格式

图片


监控数据就是从这里获取,在zabbix的agent中添加脚本如下:

json
urllib3

():
    url = http = urllib3.PoolManager()
    up_status = http.request(url).data.decode()
    up_status = json.loads(up_status)
    upstreams = []
    upserver up_status[][]:
        status = {: upserver[]: upserver[]: upserver[]: upserver[]: upserver[]: upserver[]}
        upstreams.append(status)
    result = { : upstreams}

    result

__name__ == :
    :
        (call_api())
    e:
        (e)

这里主要是把status返回的数据处理成zabbix需要的格式,因为我是用zabbix自动发现功能,所以这里直接写成遍历server,执行脚本输出如下:

图片

数据收集就没问题了,接着在zabbix中添加自动发现规则

图片

接着添加监控项原型图片

监控项原型主要是获取upstream后端server状态,接着添加触发器

图片

监控很简单,就添加完了,当upstream后端server状态down掉就会触发规则,将告警信息通过告警媒介发送到企业微信,当然你也可以是钉钉或短信,看你自己配置的告警媒介

图片

恢复后通知:

图片


Je suppose que tu aimes

Origine blog.51cto.com/15080021/2654494
conseillé
Classement