Прошу помощи с пониманием концепции сервисов в Заббиксе
Добрый день.
Прошу помощи в понимании выстраивания сервисов в Заббиксе.
У меня возникают затруднения именно концептуального характера, особенно при попытке увязать зависимости сервисов и состояния триггеров на хостах.
Т.е. не могу представить мониторинга сервиса в таком виде, чтобы по источнику проблемы техническому специалисту было понятно, в чём конкретно проблема. Это вроде бы и есть основной смысл мониторинга сервисов.
Конечная цель: Сервис, состояние и причины проблем которого понятны как менеджерам, так и техническим специалистам.
TL;DR: Как построить зависимость сервисов таким образом, чтобы состояние сервиса А зависело от состояния сервиса Б и от проблем с сервисом А?
Упрощённая схема сервиса на рисунке ниже.
Ноды и фронт - отдельные узлы, опрашиваются прокси-серверами, проверки внешние с точки зрения узлов Заббикса (тип элементов данных - HTTP-агент).
Оценка состояния сервиса:
При отказе одной из нод сервис качество сервиса деградирует, но он работоспособен.
Точка входа - фронт, при проблеме с доступностью фронта сервис не предоставляется, вне зависимости от состояния нод.
Для простоты примем, что интересует работа сервиса MS Exchange OWA (помимо MAPI, EWS, AutoDiscover, MS-ActiveSync). Сервис OWA, как и все вышеперечисленные, зависит от работы HTTP-сервера на нодах и доступности HTTP на фронтенде.
На нодах бэка и на фронте используются триггеры "HTTP unavailable" и "OWA unavailable".
"OWA unavailable" зависит от "HTTP unavailable", т.е. при недоступности HTTP проблема по триггеру OWA будет подавлена.
С технической точки зрения всё замечательно, для персонала сразу понятно где и в чём проблема, если просто наблюдать за узлами Заббикса.
Затруднения возникают при попытке перевода мониторинга в плоскость мониторинга сервиса (услуги).
С технической точки зрения OWA зависит от HTTP, т.е. недоступен HTTP - недоступен и OWA.
Вот именно тут и возникает проблема при выстраивании зависимостей сервисов.
Вариант 1:
В этом случае теги проблем можно указать только для HTTP, как для сервиса самого нижнего уровня. Если HTTP недоступен, то состояние сервиса OWA будет оцениваться корректно.
Если HTTP доступен, а OWA - не доступен, то в данном случае определить это по тегам проблем невозможно, если проблема с HTTP не содержит теги, указывающие на проблемы с OWA. Но чисто логически тегировать проблемы с HTTP проблемами, не относящимися конкретно к HTTP - это неправильно.
Ещё тут такое замечание. С точки зрения Заббикса в данной схеме HTTP является "дочерним" по отношению к HTTP, т.е. состояние HTTP влияет на OWA.
Но технически всё ровно наоборот: OWA является "дочерним" по отношению к HTTP, т.к. работает поверх него. Если хотите, это 7+ уровень модели OSI.
Вариант 2:
В этом случае по тегам проблем самых "нижних" сервисов можно определить их состояние, но тогда теряется из зависимость с технической точки зрения. Т.е. нужно отключать зависимости триггеров, и технический работник, зайдя в обзор хоста, увидит россыпь триггеров вместо одного, самого главного триггера. Даже если зависимости не отключать, то получаем усложнение правил расчёта состояния сервиса. Да, за всё надо платить.
В моём понимании представление сервиса не должно логически различаться с представлением его технических аспектов. Т.е. если OWA зависит от HTTP технически, то и логически в сервисе это должно быть отображено именно как зависимость.
Проблема реализации состоит в том, что состояние OWA зависит как от HTTP, так и от доступности OWA. Т.е. сервис OWA должен оцениваться как по состоянию дочернего сервиса HTTP, так и по состоянию тегов проблем с OWA, что в Заббиксе невозможно в рамках одного сервиса.
Схема ниже позволит это реализовать, но выглядит она как бред и охота это сразу в помойку выкинуть, потомку что это явно костыль и фактически сервис представлен два раза.
Как быть, что делать? В чём моя ошибка в понимании концепции сервисов Заббикса?
Не стоит пытаться смешивать бизнес-логику и техническое представление? Тогда как на основе состояния сервисов алертить технарям? Или же технарям нужно алертить не по сервису, а по проблемам из триггеров?
Тогда "услуги" - это только для бизнеса и технарям вообще про это знать не нужно?
Я вижу свою проблему именно тут - не уловил сути решения, поэтому все мои решения выглядят сложными, и к тому же не работают. Красота в простоте.
Прошу помощи в понимании выстраивания сервисов в Заббиксе.
У меня возникают затруднения именно концептуального характера, особенно при попытке увязать зависимости сервисов и состояния триггеров на хостах.
Т.е. не могу представить мониторинга сервиса в таком виде, чтобы по источнику проблемы техническому специалисту было понятно, в чём конкретно проблема. Это вроде бы и есть основной смысл мониторинга сервисов.
Конечная цель: Сервис, состояние и причины проблем которого понятны как менеджерам, так и техническим специалистам.
TL;DR: Как построить зависимость сервисов таким образом, чтобы состояние сервиса А зависело от состояния сервиса Б и от проблем с сервисом А?
Упрощённая схема сервиса на рисунке ниже.
Ноды и фронт - отдельные узлы, опрашиваются прокси-серверами, проверки внешние с точки зрения узлов Заббикса (тип элементов данных - HTTP-агент).
Оценка состояния сервиса:
При отказе одной из нод сервис качество сервиса деградирует, но он работоспособен.
Точка входа - фронт, при проблеме с доступностью фронта сервис не предоставляется, вне зависимости от состояния нод.
Для простоты примем, что интересует работа сервиса MS Exchange OWA (помимо MAPI, EWS, AutoDiscover, MS-ActiveSync). Сервис OWA, как и все вышеперечисленные, зависит от работы HTTP-сервера на нодах и доступности HTTP на фронтенде.
На нодах бэка и на фронте используются триггеры "HTTP unavailable" и "OWA unavailable".
"OWA unavailable" зависит от "HTTP unavailable", т.е. при недоступности HTTP проблема по триггеру OWA будет подавлена.
С технической точки зрения всё замечательно, для персонала сразу понятно где и в чём проблема, если просто наблюдать за узлами Заббикса.
Затруднения возникают при попытке перевода мониторинга в плоскость мониторинга сервиса (услуги).
С технической точки зрения OWA зависит от HTTP, т.е. недоступен HTTP - недоступен и OWA.
Вот именно тут и возникает проблема при выстраивании зависимостей сервисов.
Вариант 1:
В этом случае теги проблем можно указать только для HTTP, как для сервиса самого нижнего уровня. Если HTTP недоступен, то состояние сервиса OWA будет оцениваться корректно.
Если HTTP доступен, а OWA - не доступен, то в данном случае определить это по тегам проблем невозможно, если проблема с HTTP не содержит теги, указывающие на проблемы с OWA. Но чисто логически тегировать проблемы с HTTP проблемами, не относящимися конкретно к HTTP - это неправильно.
Ещё тут такое замечание. С точки зрения Заббикса в данной схеме HTTP является "дочерним" по отношению к HTTP, т.е. состояние HTTP влияет на OWA.
Но технически всё ровно наоборот: OWA является "дочерним" по отношению к HTTP, т.к. работает поверх него. Если хотите, это 7+ уровень модели OSI.
Вариант 2:
В этом случае по тегам проблем самых "нижних" сервисов можно определить их состояние, но тогда теряется из зависимость с технической точки зрения. Т.е. нужно отключать зависимости триггеров, и технический работник, зайдя в обзор хоста, увидит россыпь триггеров вместо одного, самого главного триггера. Даже если зависимости не отключать, то получаем усложнение правил расчёта состояния сервиса. Да, за всё надо платить.
В моём понимании представление сервиса не должно логически различаться с представлением его технических аспектов. Т.е. если OWA зависит от HTTP технически, то и логически в сервисе это должно быть отображено именно как зависимость.
Проблема реализации состоит в том, что состояние OWA зависит как от HTTP, так и от доступности OWA. Т.е. сервис OWA должен оцениваться как по состоянию дочернего сервиса HTTP, так и по состоянию тегов проблем с OWA, что в Заббиксе невозможно в рамках одного сервиса.
Схема ниже позволит это реализовать, но выглядит она как бред и охота это сразу в помойку выкинуть, потомку что это явно костыль и фактически сервис представлен два раза.
Как быть, что делать? В чём моя ошибка в понимании концепции сервисов Заббикса?
Не стоит пытаться смешивать бизнес-логику и техническое представление? Тогда как на основе состояния сервисов алертить технарям? Или же технарям нужно алертить не по сервису, а по проблемам из триггеров?
Тогда "услуги" - это только для бизнеса и технарям вообще про это знать не нужно?
Я вижу свою проблему именно тут - не уловил сути решения, поэтому все мои решения выглядят сложными, и к тому же не работают. Красота в простоте.
Comment