Стек мониторинга живёт на ВМ log (10.11.11.12), уведомления уходят в свой корпоративный чат
на ВМ zulip (10.11.11.14).
| Компонент | Назначение |
|---|---|
| Zabbix | доступность узлов, железо, метрики; интерфейс переведён на русский |
| Grafana | просмотр логов и дашборды |
| Loki | хранилище логов (глубина 90 дней) |
| rsyslog | приём syslog от сетевого оборудования и серверов |
Сырые логи дополнительно лежат простыми текстовыми файлами (независимо от базы Loki) — даже если
индекс Loki когда-нибудь потеряет данные, необработанные логи останутся.
Под мониторингом: оба MikroTik-роутера (хаб и филиал), BMC/iDRAC сервера, и сами линукс-ВМ
инфраструктуры (агент Zabbix). Роутеры и BMC отправляют логи и метрики по SNMP — доступ по SNMP
ограничен ровно одним адресом (самим сервером логов), а стандартное публичное SNMP-сообщество на
оборудовании закрыто на чтение.
Имя каталога, куда складываются логи конкретного источника, берётся из самого текста
syslog-сообщения, а не из DNS. MikroTik не передаёт собственное имя, поэтому сервер логов
резолвит присылающий адрес сам — а значит на сервере логов должны быть явные записи соответствия
адрес→имя для каждого источника, иначе логи улетают в каталог с техническим именем вместо
понятного.
И Zabbix, и Grafana настроены слать алерты в один канал «Алерты» корпоративного чата — оба пути
проверены сквозными тестовыми сообщениями. Раньше у Grafana уведомления были настроены на email,
который никуда не доходил (не настроен почтовый релей) — теперь оба сервиса используют веб-хуки
напрямую в чат.
Особенность локализации: сама «обвязка» сообщений (служебные англоязычные слова уведомлений)
осталась на английском намеренно — это зашито в код интеграции чата, трогать который решили не
нужно. А вот содержательная часть — уровень важности, текст «проблема/решено» — переведены на
русский средствами настроек самого Zabbix, без правки кода.
Скрытая грабля вебхуков мониторинга: статус "успешно" от системы мониторинга далеко не всегда
означает, что сообщение реально дошло до получателя — многие webhook-интеграции сами проглатывают
ошибки доставки, чтобы не заваливать основной лог. Если сообщения не приходят, а статус
показывает успех — нужно включать отдельную диагностику самого модуля отправки, а не полагаться
на общий статус.
Организация развёрнута как отдельный чат-сервер, публикуется наружу через общий фронт hub.
Почтовые уведомления (приглашения новых пользователей по email) пока не работают — почтовый
релей не настроен, используется только вебхук-сценарий уведомлений от мониторинга.
Сервис со своим встроенным веб-сервером (как у Zulip) может форсировать HTTPS с собственным
самоподписанным сертификатом. Если внешний общий фронт при этом проксирует на него по обычному
HTTP, получается бесконечный цикл редиректов. Лечится явным указанием сервису не форсировать
HTTPS самому (раз TLS уже терминируется на общем фронте) и явным указанием, какому адресу
(общему фронту) доверять как источнику запросов.
Бот @aliafarm_bot шлёт те же алерты (Zabbix), что и Zulip, параллельно. api.telegram.org
из сети офиса недоступен не из-за блокировки IP/порта, а потому что провайдерский DPI режет
TLS-соединения по полю SNI api.telegram.org в ClientHello — независимо от того, к какому
IP и порту оно идёт. Поэтому просто "прокинуть трафик на другой IP" не сработало.
Решение: на стороннем сервере sezam (95.181.174.217, отдельный от «Алии» хост) добавлен
reverse-proxy (Caddy, домен tgapi.aliafarm.ru, самоподписанный сертификат), который сам открывает
настоящее HTTPS до Telegram — клиент из офиса ни разу не произносит api.telegram.org на пути
до заграницы, DPI нечего блокировать. Подробности и схема — aliya/network/docs/telegram-proxy.md.
Zabbix: отдельный media type «Telegram (Алия)» + action «Telegram» (встроенный шаблон Zabbix
«Telegram» не подошёл — жёстко ходит на api.telegram.org без возможности подменить домен).
Тексты алертов на русском, тот же приём с {ALERT.MESSAGE}, что и в Zulip.
Три триггера на хосте rb5009-lenina в Zabbix (severity High), уходят автоматически в оба канала:
pppoe-out1 (одновременно >50 Мбит/с и десятикратныйПороги подобраны «с запасом» вслепую — реальная ёмкость канала неизвестна (PPPoE не отдаёт
скорость по SNMP), фон на момент настройки был почти нулевой (CPU 1-2%, трафик <1 Мбит/с).
Живым трафиком триггеры не проверялись — генерировать нагрузку на рабочий WAN офиса ради
теста не стали. Если пороги окажутся неточными (молчат при реальной атаке или наоборот
срабатывают на легитимные пики вроде бэкапов/видеозвонков) — поправить в Zabbix, значения
и обоснование — aliya/network/docs/log-node.md.
Бот @aliafarm_bot шлёт те же алерты (Zabbix), что и Zulip, параллельно. api.telegram.org
из сети офиса недоступен не из-за блокировки IP/порта, а потому что провайдерский DPI режет
TLS-соединения по полю SNI api.telegram.org в ClientHello — независимо от того, к какому
IP и порту оно идёт. Поэтому просто "прокинуть трафик на другой IP" не сработало.
Решение: на стороннем сервере sezam (95.181.174.217, отдельный от «Алии» хост) добавлен
reverse-proxy (Caddy, домен tgapi.aliafarm.ru, самоподписанный сертификат), который сам открывает
настоящее HTTPS до Telegram — клиент из офиса ни разу не произносит api.telegram.org на пути
до заграницы, DPI нечего блокировать. Подробности и схема — aliya/network/docs/telegram-proxy.md.
Zabbix: отдельный media type «Telegram (Алия)» + action «Telegram» (встроенный шаблон Zabbix
«Telegram» не подошёл — жёстко ходит на api.telegram.org без возможности подменить домен).
Тексты алертов на русском, тот же приём с {ALERT.MESSAGE}, что и в Zulip.
Три триггера на хосте rb5009-lenina в Zabbix (severity High), уходят автоматически в оба канала:
pppoe-out1 (одновременно >50 Мбит/с и десятикратныйПороги подобраны «с запасом» вслепую — реальная ёмкость канала неизвестна (PPPoE не отдаёт
скорость по SNMP), фон на момент настройки был почти нулевой (CPU 1-2%, трафик <1 Мбит/с).
Живым трафиком триггеры не проверялись — генерировать нагрузку на рабочий WAN офиса ради
теста не стали. Если пороги окажутся неточными (молчат при реальной атаке или наоборот
срабатывают на легитимные пики вроде бэкапов/видеозвонков) — поправить в Zabbix, значения
и обоснование — aliya/network/docs/log-node.md.