Короткий ответ

ICMP доказывает только «узел отвечает на echo», не что HTTPS, LDAP, RDP или SQL живы. На каждый критичный сервис — свой item: net.tcp.service[https,zabbix.example,443], net.tcp.service[ldap,dc,389], HTTP agent с кодом 200 и временем ответа. ICMP — дополнительный слой и корень зависимостей (умер шлюз — не звонить про 40 сервисов). Агент ZBX: агент недоступен. SNMP-железо: SNMP. TLS срок: сертификаты. Карта: зависимости.

Проверки с 10.0.20.50 или с proxy в том же сегменте, откуда «правда» для пользователей. Хост-пример WS-042.

Симптомы и как отличить

Типичная картина:

  • дежурный верит зелёному icmpping, пользователи без почты;
  • ночью ICMP flap на Wi-Fi филиала, сотни PROBLEM;
  • simple check с сервера в обход NAT, пользователи идут иначе;
  • agent.ping есть, IIS нет — смешали доступность ОС и приложения.

Отличия слоёв:

СлойItemЧто не доказывает
L3icmppingпорт/приложение
TCPnet.tcp.serviceHTTP 500 внутри
HTTPhttp agent / web.pageбизнес-логика
Applogin probe— ближе к синтетике

Возможные причины

  1. Только ICMP шаблона.
  2. TCP check с 10.0.20.50 в backend, пользователи на VIP — разные пути.
  3. Нет зависимости от шлюза.
  4. Интервал 1s, ложные timeout.
  5. UDP сервис проверяют TCP (DNS только 53/tcp).
  6. Health URL без auth возвращает 200 на «maintenance html».
  7. Редко: IPv6 клиенты, мониторинг только A-запись.

Диагностика

1. Что уже есть на WS-042 / сайте

Latest data: icmpping, agent.ping, net.tcp.service, HTTP. Если только ping — дыра.

2. Сверка пути

С 10.0.20.50:

ping -c 3 WS-042
nc -vz WS-042 443
curl -sS -o /dev/null -w '%{http_code}\n' https://zabbix.example/

Если curl 200, а item HTTP смотрит http://10.0.20.50/ без Host — вы мониторите не тот vhost.

3. Simple check vs agent

net.tcp.service simple check выполняется сервером/proxy Zabbix, не агентом на WS-042. Это плюс (видите как клиент из сегмента мониторинга). Минус: не видите bind только localhost. Для localhost-сервиса — ключ агента net.tcp.port[127.0.0.1,3306] на самом хосте.

4. ICMP с сервера

# fping часто использует Zabbix pinger
which fping

Нет fping — item icmp может быть unsupported. Ставьте пакет, не отключайте весь шаблон.

Решение

Сценарий A. Минимальный пакет на веб

  1. ICMP (Warning, не единственный Disaster).
  2. net.tcp.service[https,{HOST.CONN},443] .
  3. HTTP agent: URL https://zabbix.example/, required string или status code 200, timeout 5–10s.
  4. Отдельно cert expiry.

Триггер HTTP важнее ping. Зависимость: HTTP зависит от «host unreachable» если ICMP есть; если ICMP запрещён — зависимость от TCP 443.

Сценарий B. AD / Windows

Не один ping DC. LDAP 389/636, DNS 53 UDP+TCP, Kerberos 88. См. Windows. Simple check с 10.0.20.50 в VLAN клиентов, не только с DC на себя.

Сценарий C. Филиал за NAT

Проверки с proxy в филиале: иначе вы мониторите VPN-концентратор, не сервер. Агентный agent.ping = ОС. Сервис — TCP с proxy.

Сценарий D. DNS как сервис

# не путать с TCP 53
nc -vz -u DC01 53

Item net.udp.service[dns,{HOST.CONN},53] / net.dns по документации ключей вашей версии. TCP-only проверка DNS недостаточна для клиентов UDP.

Сценарий E. Пороги времени ответа

icmppingsec и HTTP time > 2s — Warning деградации, не ждать полного down. Не last() без окна — пороги по духу те же: база, hysteresis.

После добавления:

sudo zabbix_server -R config_cache_reload

Как проверить, что проблема устранена

Остановите на стенде nginx, ping оставьте: должен открыться PROBLEM HTTP/443, не только «всё зелёное». Остановите агент: ZBX down, HTTP ещё может быть жив если смотрите simple check — это ожидаемо, два сигнала. Зависимость шлюза: down шлюза — один корневой алерт. Action log для Disaster сервиса.

systemctl status zabbix-server zabbix-agent2 --no-pager

Если не помогло

  • Проверка идёт на IP, сертификат/Host другой — SNI/Host header.
  • Simple check timeout из-за очереди pinger — очередь.
  • Гео: мониторинг из ДЦ, проблема у провайдера клиентов — нужен внешний probe (отдельный proxy), Zabbix изнутри не всевидящий.

Профилактика

  • Чеклист услуги: ICMP + TCP + прикладной код ответа.
  • Не добавлять VIP без item на VIP.
  • Документировать, откуда идёт probe.
  • Карта зависимостей до включения шумных шаблонов.

Нарисуйте путь пользователя: DNS, VIP или балансир, backend вроде WS-042. Probe бьёт в VIP тем же именем, что клиент, плюс отдельный probe backend, если нужно отличить смерть LB от смерти IIS. ICMP до backend не отвечает на вопрос, открывается ли касса.

Сбой провайдера у клиентов Zabbix из ДЦ не увидит. Если это риск бизнеса, нужен второй proxy снаружи, а не усложнение ping внутри. Не требуйте от 10.0.20.50 всеведения Интернета.

UDP DNS, TCP LDAP и HTTPS — разные item. Открытый порт не равен живому протоколу. Для HTTP обязателен код ответа и желательно фрагмент тела, иначе техническая заглушка с 200 останется зелёной.

Запишите в runbook, откуда идёт probe: 10.0.20.50, филиальный proxy или оба. Смена NAT без смены simple check даёт ложный down или ложный up. Для WS-042 держите ICMP как Warning-корень и TCP/HTTP как критерий услуги. Пользовательский сценарий «открыть сайт» важнее зелёного ping.

FAQ

agent.ping vs icmpping

agent.ping — процесс агента. icmpping — echo IP. Разные. Для «ОС жива без агента» ICMP. Для «мониторинг жив» агент. Для «касса работает» HTTP.

Можно ли обойтись без ICMP?

Да, если политика запрещает echo. Тогда корень зависимостей — TCP default порт или агент.

web.page.regexp устарел?

В 6.0/7.0 часто HTTP agent удобнее. Не плодите оба на один URL.

Проверка «с самого WS-042» localhost 443

Доказывает bind, не ACL снаружи. Нужен probe с 10.0.20.50.

UDP 161 для доступности SNMP-устройства

snmpwalk/snmp item, не ping alone. См. SNMP статью.

Слишком частый HTTP ломает приложение?

Интервал 1–2 мин для availability хватает. 1s — вы DDoS сами себя.