Escribí un artículo antes, presentando cómo Nginx monitorea el tráfico de cada servidor , principalmente agregando un módulo de estado de terceros para ver el estado de todos los servidores y el flujo ascendente. Luego, la gente siempre pregunta si hay una manera de monitorear el flujo ascendente y alertar , así que lo presentaré hoy., Métodos completos de monitoreo y advertencia upstream
Aplicación: Nginx / Tengine
模块 ： ngx_http_upstream_check_module
Seguimiento: zabbix
Alerta: Enterprise WeChat / Dingding
Debido a que el upstream de nginx es pasivo por defecto y no será monitoreado activamente, el módulo upstream_check de tengine se usa directamente aquí
Si es tengine, siempre que sea la versión 1.4 o superior, el módulo se abrirá de forma predeterminada. Si es nginx, debe volver a compilar nginx y agregar el módulo. El método de compilación no tiene mucho que decir aquí. Descargue el código fuente y agréguelo con --add-module Simplemente compile
El módulo upstream_check proporciona una función activa de verificación del estado del servidor back-end. Aquí hay algunas instrucciones proporcionadas por el módulo
controlar
Sintaxis: intervalo de verificación = milisegundos [caída = cuenta] [subida = cuenta] [tiempo de espera = milisegundos] [default_down = true | false] [type = tcp | http | ssl_hello | mysql | ajp] [puerto = check_port] Predeterminado: intervalo = 30000 caída = 5 subida = 2 tiempo de espera = 1000 default_down = true type = tcp Contexto: upstream
Este comando puede activar la función de verificación de estado del servidor back-end. El significado de los parámetros después del comando es:
intervalo : el intervalo de los paquetes de verificación de estado enviados al backend
fall (fall_count) : si el número de fallos consecutivos alcanza fall_count, el servidor se considera inactivo
Rise (Rise_count) : si el número de éxitos consecutivos alcanza Rise_count, el servidor se considera
tiempo de espera agotado : el tiempo de espera de la solicitud de estado del back-end.
default_down : establece el estado inicial del servidor, si es verdadero, significa que el predeterminado está inactivo
type : el tipo de paquete de verificación de estado, ahora admite los siguientes tipos múltiples
tcp: conexión tcp simple, si la conexión es exitosa, el backend es normal
ssl_hello: envíe un paquete de saludo SSL inicial y acepte el paquete de saludo SSL del servidor
http: envíe una solicitud HTTP y juzgue si el backend está activo por el estado del paquete de respuesta del backend
mysql: conéctese al servidor mysql y juzgue si el backend está activo al recibir el paquete de saludo del servidor
ajp: envía el paquete Cping del protocolo AJP al backend y juzga si el backend está activo al recibir el paquete Cpong
puerto : especifique el puerto de verificación del servidor back-end. Puede especificar el puerto del servidor back-end que es diferente del servicio real. Por ejemplo, el back-end proporciona una aplicación en el puerto 443. Puede verificar el estado del puerto 80 para determinar el estado del back-end. El valor predeterminado es 0, lo que significa que el puerto es el mismo que el puerto de servicio real proporcionado por el servidor backend. Esta opción aparece en Tengine-1.4.0
check_keepalive_requests
Sintaxis: check_keepalive_requests request_num Predeterminado: 1 Contexto: ascendente
Este comando puede configurar el número de solicitudes enviadas por una conexión. El valor predeterminado es 1, lo que significa que Tengine cerrará la conexión después de completar una solicitud.
check_http_send
Sintaxis: check_http_send http_packet Predeterminado: "GET / HTTP / 1.0" Contexto: ascendente
Este comando puede configurar el contenido de la solicitud enviada por el paquete de verificación de estado de http. Para reducir la cantidad de datos transmitidos, se recomienda el método "HEAD". Cuando se usa una conexión larga para la verificación de estado, el encabezado de la solicitud de mantener vivo debe agregarse al comando, como: "HEAD / HTTP / 1.1 \ r \ nConexión: keep-alive \ r \ n \ r \ n" . Al mismo tiempo, en el caso de utilizar el método "GET", el tamaño de la uri de solicitud no debe ser demasiado grande para garantizar que la transmisión se pueda completar en 1 intervalo, de lo contrario se considerará como un servidor back-end. o anomalía de la red por parte del módulo de verificación de estado
check_http_expect_alive
Sintaxis: check_http_expect_alive [http_2xx | http_3xx | http_4xx | http_5xx] Predeterminado: http_2xx | http_3xx Contexto: ascendente
Este comando especifica el estado correcto de la respuesta HTTP. De forma predeterminada, el estado de 2XX y 3XX se considera correcto.
check_shm_size
Sintaxis: check_shm_size size Predeterminado: 1M Contexto: http
El estado de la verificación de estado de todos los servidores back-end se almacena en la memoria compartida. Este comando puede establecer el tamaño de la memoria compartida. El valor predeterminado es 1 M, si tiene más de 1000 servidores y se produce un error durante la configuración, es posible que deba ampliar el tamaño de la memoria
comprobar estado
Sintaxis: check_status [html | csv | json] Predeterminado: check_status html Contexto: ubicación
显示服务器的健康状态页面。该指令需要在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掉就会触发规则，将告警信息通过告警媒介发送到企业微信，当然你也可以是钉钉或短信，看你自己配置的告警媒介
恢复后通知：
