Сервис в Pandora FMS - это совокупность ресурсов информационных технологий (Information Technology, сокращенно IT) на основе их функциональных возможностей.
Сервисом может быть, например, официальный сайт компании, Customer Relationship Management (CRM), приложение поддержки или даже все принтеры компании или в доме. Сервисы PFMS - это логические группы, включающие хосты, маршрутизаторы, коммутаторы, брандмауэры, веб-узлы и даже другие Сервисы.
Pandora FMS представляет Сервисы как совокупность контролируемых элементов (Модули, Агенты или другие Сервисы) индивидуальное состояние которых определенным образом влияет на глобальную функциональность предоставляемого Сервиса. Более подробную информацию вы можете получить в обучающем видео «Мониторинг Сервисов в Pandora FMS».
Базовый мониторинг в Pandora FMS заключается в сборе метрик из различных источников, представляя их в виде систем контроля (называемых Модулями). Мониторинг на основе сервисов позволяет группировать предыдущие элементы таким образом, что, играя с определенными правилами, основанными на накоплении отказов, можно контролировать группы элементов различных типов и их взаимосвязь в более крупном и общем сервисе.
Таким образом, мониторинг Сервисов позволяет проверить общее состояние всех служб. Вы можете узнать, предоставляется ли сервис нормально (зеленый цвет), ухудшается ли он (желтый цвет) или не предоставляется (красный цвет).
Сервисы мониторинга представлены в рамках трех категорий: обычный режим, по важности и по цепочке каскадных событий.
В этом режиме необходимо только указать, какие элементы являются критическими, а какие нет.
Только элементы, помеченные как критические, будут учитываться при расчетах, и только critical
статус этих элементов будет иметь значение.
critical
, служба переходит в состояние предупреждения. warning
.critical
, служба переходит в статус critical
.Пример:
Случай 1:
critical
.critical
.warning
.
Результат: Сервис в состоянии warning
, потому что принтер не находится в критическом состоянии, маршрутизатор находится в критическом
состоянии представляет только 50% критических элементов, сервер Apache не находится в критическом состоянии и не вносит вклад в оценку.
Случай 2:
critical
.critical
.critical
.
Результат: Сервис в состоянии critical
(принтер все еще не имеет никакого значения).
Случай 3:
normal
.critical
.normal
.Результат: Статус сервиса будет normal, поскольку ни один из ключевых элементов не является critical (опять же, принтер по-прежнему не имеет никакого значения).
Необходимость мониторинга Сервисов как чего-то «абстрактного» возникает при столкновении со следующим вопросом:
Что произойдет с моим приложением, если элемент, который по сути критическим не является, перестанет работать?
Чтобы разрешить все эти сомнения, в Pandora FMS появляется функция мониторинга через Сервисы, которая помогает:
Для этого необходимо отслеживать каждый элемент, который может негативно повлиять на наше приложение.
Через Консоль Pandora FMS следует определить Дерево Сервиса, в котором необходимо указать элементы, влияющие на приложения или приложения, а также степень их влияния.
Все элементы, которые мы добавляем в деревья сервисов, соответствуют информации, над которой уже проводится мониторинг, либо в виде модулей, конкретных агентов или других сервисов.
Для обозначения степени влияния состояний каждого элемента на общее состояние используется система суммы важности, так что наиболее важные из них (с большим весом) будут более значимы для перевода глобального состояния всего сервиса в неправильное состояние раньше, чем менее важные элементы (с меньшим весом).
Необходимо проводить мониторинг Веб-приложения, сбалансированного с помощью нескольких резервных элементов. Инфраструктура, на которой основано приложение, состоит в данном примере из следующих элементов:
Нашей целью является узнать, правильно ли работает веб-приложение, т.е. окончательная оценка наших клиентов заключается в том, что приложение получает, обрабатывает и возвращает запросы в строго установленные сроки.
Если бы один из двадцати серверов Apache был отключен от сети, из-за такого большого количества резервирования, было бы разумно оповестить, предупредить всех сотрудников? Каково правило предупреждения?
Можно сделать вывод, что Pandora FMS должна предупреждать только в случае отказа очень важного элемента (например, маршрутизатора) или если несколько серверов Apache одновременно отключатся, но какое их количество? Чтобы определить это, необходимо присвоить весовые значения списку компонентов, описанному выше:
Коммутаторы и маршрутизаторы
По 5 баллов, если они находятся в critical
и 3 балла, если они находятся в warning
.
Серверы Web
1,2 балла каждому в состоянии critical
, мы не наблюдаем статус warning
.
Серверы WebLogic
2 балла каждому в состоянии critical
.
Cluster MySQL
5 балла каждому в состоянии critical
и 3 балла в статусе warning
.
Тип элемента | Приписывание веса | |||
---|---|---|---|---|
Normal | Warning | Critical | Unknown | |
Router | 0 | 3 | 5 | 5 |
Switch | 0 | 3 | 5 | 5 |
Apache server | 0 | 0 | 1,2 | 1,2 |
WebLogic server | 0 | 0 | 2 | 2 |
MySQL server | 0 | 3 | 5 | 5 |
Поскольку в нормальной ситуации сумма весов равна нулю, поэтому в данном примере установлено, что порог статуса warning
должен быть больше 4, а для состояния critical
больше 6:
Конфигурация Сервиса | ||
---|---|---|
Normal | Warning | Critical |
0 | >=4 | >=6 |
Сценарии сбоев:
critical
): поскольку все остальное в норме и вносит нулевой вклад, общая сумма будет 1,2, а поскольку 1,2 < 4 (порог warning
), Служба все еще в нормальном состоянии (статус normal
).critical
> первый вносит 1,2 балла, а второй - 2,0 балла, что в сумме составляет 3,2; это все еще меньше, чем 4, поэтому Служба все еще в порядке, предупреждение или какие-то действия не требуются.warning
, работа все еще происходит и может не требовать немедленных технических действий, но ясно, что в инфраструктуре возникла проблема.critical
, и он вызывает новую ситуацию: он добавляет 5 баллов к сумме весов и превышает порог критичности, установленный на уровне 6; Сервис является критическим, Сервис не предоставляется и необходимы немедленные технические действия.В последней ситуации Pandora FMS оповестит соответствующую рабочую группу (операторов, техников и т.д.).
Вы можете получить интересную информацию о Мониторинге Сервисов в блоге Pandora FMS
Сервис Корень - это служба, которая не является частью другого Сервиса. Эта логическая концепция позволяет быстрее осуществлять мониторинг, сокращая очереди на выполнение работ.
Аналогично, и основываясь на этой концепции, когда сервис, определенный в узле Pandora FMS, появляется как элемент сервиса Корень в Метаконсоли, именно сервер Метаконсоли будет оценивать его, обновляя значения, хранящиеся в узле.
Это обеспечивает более эффективную распределенную логику и позволяет реализовать каскадную систему защиты на основе сервисов..
Сервисы в Metaconsole позволяют добавлять в качестве элементов сервиса как другие сервисы, так и модули и/или агенты, поскольку в предыдущих версиях разрешалось добавлять только узловые сервисы.
Компонент PredictionServer должен быть включен, чтобы использовать Сервисы.
Компонент PredictionServer должен быть запущен, и должна быть установлена версия Enterprise Pandora Server.
Сервисы могут представлять:
Значения Сервиса рассчитываются с помощью Сервера прогнозирования. (PredictionServer).
После того как все устройства находятся под наблюдением, добавьте в каждый Сервис все модули, агенты или подслужбы, необходимые для наблюдения за Сервисом. Например, для мониторинга сервиса онлайн-Магазина вам нужен модуль для его содержимого, Сервис, который будет проводить мониторинг состояния коммуникаций, и т.д.
Чтобы создать новый сервис, перейдите в раздел Topology Maps > Services.
Появится вид дерева со всеми Сервисами.
Для создания нового сервиса нажмите на кнопку Create Service и заполните появившуюся форму:
Name
Это должно быть уникальное имя, позволяющее идентифицировать Службу.
Description
Обязательно. Это описание, вместо названия, появляется на карте Сервиса, при просмотре таблицы Сервиса и в Widget Сервисов.
Group
Группа, к которой принадлежит сервис, полезно в ограничениях ACL.
Agent to store data
Сервис хранит данные в специальных модулях данных (а именно в модулях прогнозирования). Необходимо ввести агента, который будет контейнером для этих модулей, и в то же время он будет содержать сигналы тревоги (см. следующие шаги).
Примечание: Обратите внимание, что интервал, в котором будут выполняться все вычисления сервисных модулей, зависит от интервала агента, сконфигурированного как контейнер.
Mode
Метод расчета весов элементов. Он может иметь 2 значения:
Unknown elements as critical
Позволяет указать, что элементы в неизвестном состоянии вносят свой вес, как если бы они были элементом в критическом состоянии.
Режим smart доступен только начиная с версии 7.0 NG 748 Pandora FMS.
Режимы автоматический и простой предыдущих версий станут ручными при применении MR 40 в обновлении версии.
Favorite
Создайте прямую ссылку в боковом меню, и вы сможете фильтровать Сервисы при просмотре на основе этого критерия.
Quiet
Активирует бесшумный режим работы Службы, чтобы она не генерировала предупреждения или события.
Cascade protection enabled
Активирует каскадную защиту на элементах Сервиса. Не должны генерироваться предупреждения или события, если они принадлежат Сервису (или подслужбе), который находится в критическом состоянии.
Calculate continuos SLA
Активирует создание модулей SLA и значений SLA для текущего Сервиса. Он используется в случаях, когда количество необходимых Сервисов настолько велико, что это может повлиять на производительность.
Если вы отключите эту последнюю опцию, после создания Сервиса удалится история данных этих модулей, таким образом, вы потеряете информацию.
SLA interval
Период времени для расчета эффективного SLA сервиса.
SLA limit
Порог состояния OK сервиса, который будет считаться положительным SLA в течение периода времени, настроенного в предыдущем поле.
Alerts
В этом разделе вы должны выбрать шаблоны, которые Сервис будет иметь для запуска оповещения, когда служба переходит в состояние предупреждения, критическое, неизвестное или когда SLA службы не соблюдается.
После правильного заполнения формы регистрируется пустой Сервис, который необходимо заполнить своими элементами. В форме редактирования Сервиса выберите вкладку 'Конфигурация элементов'.
Нажмите на кнопку Add element, и появится всплывающее окно с формой. Форма будет немного отличаться, если сервис находится в режиме smart или в режимеmanual.
Description
Необязательный текст, который будет использоваться для представления элемента в карте сервиса. Если не указано, то используется имя модуля, агента или сервиса (в зависимости от добавленного элемента).
Type
Выберите Сервис, Модуль или Агент; если вы находитесь в режиме Smart, также появится тип Dynamic (динамический).
Agent
Система поиска агентов (видна, если элемент для создания или редактирования имеет тип Агент или Модуль).
Module
Выпадающий список с модулями Агента, ранее выбранными в поисковой системе (виден только при редактировании или создании элемента для модуля типа Сервис).
Сервис
Выпадающий список сервисов для создания элемента (виден только в том случае, если создаваемый или редактируемый элемент имеет тип Сервис).
Вы всегда должны помнить, что сервисы, которые появляются в выпадающем списке, не являются родителями сервиса, это необходимо для отображения правильной древовидной структуры зависимости между сервисами.
Следующие поля доступны только для сервисов в ручном режиме:
critical
> Вес, который элемент добавит к сервису, находясь в критическом состоянии.warning
> Вес, который элемент добавит к сервису, находясь в состоянии предупреждения.unknown
> Вес, который элемент добавит к сервису, находясь в неизвестном состоянии.normal
> Вес, который элемент добавит к сервису, находясь в нормальном состоянии.Для расчета статуса сервиса вес каждого из его элементов суммируется на основе его статуса, и если он превышает пороговые значения, установленные в сервисе для предупреждения или критического состояния, статус сервиса изменяется на предупредительный или критический в зависимости от ситуации.
В сервисах в интеллектуальном режиме (Smart), поскольку для элементов не определены веса, способ расчета их состояния следующий:
Режим Dynamic
Следующие поля доступны только для элементов типа Dynamic (сервисы в режиме Smart):
Matching object types
Выпадающий список для выбора того, будут ли элементы, для которых будут оцениваться динамические правила и которые будут частью сервиса, агентами или модулями.
Filter by group
Правило для указания группы, к которой должен принадлежать элемент, чтобы быть частью сервиса.
Having agent name
Правило для указания имени Агента, которым должен обладать элемент, чтобы быть частью Сервиса. Указывается текст, который является частью имени желаемого Агента.
Having module name
Правило для указания имени модуля, который должен иметь элемент, чтобы быть частью Сервиса. Указывается текст, который является частью названия нужного модуля.
Use regular expresions selector
Если вы включите эту опцию, будет использоваться механизм поиска через Регулярные Выражения (regex или regexp) но в соответствии с тем, как MySQL обрабатывает регулярные выражения.
Having custom field name
Правило для указания имени пользовательского поля, которое элемент должен иметь, чтобы быть частью сервиса. Указывается текст, который является частью названия желаемого пользовательского поля.
Having custom field value
Правило для указания значения пользовательского поля, которое элемент должен иметь, чтобы быть частью сервиса. Указывается текст, который должен быть частью значения желаемого пользовательского поля.
Вы должны поместить текст в оба поля, чтобы он учитывался при поиске в пользовательских полях.
Начиная с версии NG 752 можно добавлять поиск в дополнительных пользовательских полях, которые будут выбраны, если они соответствуют любой из заданных пар ключевых слов.
Пример
Если вы решите отфильтровать Агентов группы Servers, чье имя Агента содержит Firewall
и имя модуля содержит Network
, вы можете получить следующий результат.
Пример
Если бы конфигурация динамического элемента была следующей.
Все модули, имя которых включает «Host Alive», которые находятся в агенте, имя которого включает «SW»,в группе «Servers», с пользовательским полем, имя которого включает «Department» и значение которого также включает «Systems», будут использоваться как элементы сервиса.
Динамические элементы не подвержены каскадной защите Сервисов.
async_data
).async_proc
).async_data
).Это список операций, который показывает все созданные сервисы, и к которым пользователь имеет право доступа в Консоли Pandora FMS. Нажмите на Операция > Мониторинг и внутри него Сервисы.
Каждая строка представляет собой Сервис:
Group
Иконка группы, к которой принадлежит сервис и которую может видеть пользователь.
Critical
Пороговое значение сумм веса для присваивания сервису критического статуса.
Warning
Пороговое значение сумм веса для присваивания сервису предупреждающего статуса.
Value
Значение сумм веса элементов, которые содержат сервис.
Статус
Значок, отображающий статус сервиса. Существуют три возможных состояния, обычно представленные следующими цветами:
SLA
Значение SLA с одним из следующих возможных значений:
Этот вид доступен при нажатии на название сервиса в списке всех служб или через вкладку со значком лупы в заголовке названия сервиса.
Pandora FMS отобразит страницу, подобную той, что показана на следующем снимке экрана:
Список элементов, составляющих Сервис, расположен внизу:
Type
Значок, представляющий тип элемента: строительный блок для модулей, сложенные блоки для агента или значок сетевой диаграммы для служб.
Name
Текст, содержащий имя агента, или имя агента и модуля, или имя службы. Все они содержат ссылку на соответствующий вид операции.
Weight critical
Значение связанного веса, когда элемент находится в критическом состоянии. Следующие три столбца (Warning weight, Weight Unknown и Weight OK) соответствуют последовательно предупреждению, неизвестный и нормальный./p>
Data
Значение элемента, которое в зависимости от типа может быть:
Статус
Значок, представляющий одним из кодированных цветов статус элемента.
Обратите внимание, что расчет сервисов производится сервером PredictionServer, поэтому данные рассчитываются за периоды времени. Поэтому может случиться так, что при добавлении элементов они обновляются только тогда, когда сервис пересчитывается сервером.
Этот вид отображает сервис, позволяя быстро увидеть, как модули, агенты или подслужбы влияют на мониторинг сервиса. Даже в подслужбах можно увидеть влияние при расчете статуса по сумме весов.
Возможными узлами являются:
Узел Модуля
Изображается с помощью значка графика heartbeat. Этот узел всегда является конечным или листовым узлом, из которого не выходят другие узлы.
Узел Агента
Представлен значком коробки процессора. Это также конечный узел, из которого не будут выходить другие узлы.
Узел Сервиса
Представлен иконой скрещенных молотка и гаечного ключа. Поскольку это Сервис, он должен содержать элементы, представленные в виде выходящих из него ветвей.
Цвет Узлов и соединительных стрелок зависит от статуса узла в соответствии с кодировкой: зеленый ОК, красный критический, желтый предупреждающий или серый неизвестный статус.
Внутри узла вы будете иметь:
Кроме того, на каждый элемент дерева можно нажать, а конечным пунктом является оперативный просмотр каждого из них.
Когда служба находится в режиме simple, рядом с каждым критическим элементом появится красный восклицательный знак.
В визуальной консоли вы можете добавить сервисы в качестве еще одного элемента для отображения на карте.
Создание элемента Сервиса на карте - это такой же процесс, как и для остальных элементов Визуальной карты, но палитра опций будет следующей:
Управление:
Следует отметить, что элемент сервиса, в отличие от других элементов визуальной карты, не может быть связан с другими визуальными картами, и всегда ссылка визуальной консоли, на которую можно нажать, имеет в качестве целевого вида карту сервиса в древовидном режиме, описанный выше.
Этот вид позволяет визуализировать сервисы в форме дерева.
Каждый уровень показывает количество элементов, охваченных каждым сервисом или агентом.
Сервисы, не относящиеся к другому уровню, всегда будут отображаться на первом уровне. В случае дочерней службы она будет отображаться вложенной в родительскую.
Ограничение разрешений ACL применяется только к первому уровню.
Плановые отключения пересчитывают значение отчетов SLA с учетом того, что пересчет разрешен “назад во времени” с плановыми отключениями, добавленными ретроспективно (эту опцию необходимо активировать глобально в общей настройке). В случае отчета SLA сервиса, если имеется запланированное отключение, которое затрагивает один или несколько элементов сервиса, считается, что запланированное отключение затрагивает весь сервис, поскольку влияние отключения на сервис в целом не может быть определено.
Важно отметить, что это происходит на уровне отчетов, деревья сервисов и информация, которую они представляют в визуальной консоли, не изменяются в отношении запланированных остановок, созданных после их предполагаемого выполнения. Эти значения % выполнения сервиса рассчитываются в режиме реального времени на основе исторических данных самого сервиса, а не на основе отчета, который можно “подготовить”.
С другой стороны, важно знать, как рассчитывается % выполнения сервиса:
Расчет весов в простом режиме
В простом режиме веса рассматриваются немного по-другому, так как существует только критический вес и возможность впасть в два состояния, помимо нормального. Каждому элементу присваивается вес, равный 1 для критических и 0 для остальных состояний, и каждый раз, когда в элементы сервисов вносятся изменения, весовые коэффициенты сервиса пересчитываются. Вес warning сервиса незначителен, он имеет значение 0,5 всегда, потому что если он установлен в 0, услуга всегда будет, по крайней мере, в в состоянии warning, но вес warning не используется в простом режиме. Критический вес рассчитывается так, чтобы он был равен половине суммы критических весов элементов, которая равна 1. Если есть 3 элемента, то критический вес сервиса равен 1,5, и тогда сервер должен проверить, превышен или равен ли критический вес, чтобы перевести сервис в критический или предупреждающий статус.
Расчет весов в соответствии с их важностью
Предположим, существует сервис, определяемая 95-процентным соответствием в 1-часовом интервале. Представьте таблицу значений, где t - время, x - % соответствие уровня сервиса (SLA), а s - соответствие или несоответствие сервиса (1 - соответствует, 0 - не соответствует). Через 1 час у нас будет ровно 12 образцов (при условии интервала в 5 минут).
Предположим случай, когда сервис работает хорошо в течение первых 11 проб (первые 55 минут), а на 60-й минуте выходит из строя, мы получим следующие значения:
t | s | x --------+-------+-------- 1 1 100 2 1 100 3 1 100 4 1 100 5 1 100 6 1 100 7 1 100 8 1 100 9 1 100 10 1 100 11 1 100 12 0 91,6
Этот случай легко рассчитать, % рассчитывается в зависимости от количества образцов, в t3, например, есть 3 общих образца, с тремя образцами, которые соответствуют сервису, 100%, в то время как в t12, у нас есть 12 образцов и 11 действительных: 11/12.
Предположим, что он находится в середине пробы и постепенно восстанавливается.
t | s | x --------+-------+-------- 1 1 100 2 1 100 3 1 100 4 1 100 5 1 100 6 0 83,3 7 1 85,7 8 1 87,5 9 1 88,8 10 1 90 11 1 90,9 12 1 91,6
Пока все похоже на предыдущий пункт, но давайте посмотрим, что произойдет, если мы продолжим движение во времени:
t | s | x --------+-------+-------- 13 1 91,6 14 1 91,6 15 1 91,6 16 1 91,6 17 1 91,6 18 1 100 19 1 100 ....
Здесь мы видим неинтуитивное поведение, поскольку объем достоверных образцов продолжает быть 11 для временного окна до t18, где единственное достоверное значение оставляется, так что при t18 соответствие становится 100%. Этот диапазон между 91,6 и 100 объясняется размером окна. Чем длиннее окно (обычно при расчете SLA это день, неделя или месяц), тем менее резкой будет эскалация.
Можно динамически отключать эти элементы Сервиса. Это позволяет избежать лавины предупреждений для каждого элемента, принадлежащего сервису или подслужбе.
Когда функция 'каскадная защита сервиса' активирована, выполняется действие, связанное с шаблоном, который был настроен для корневого сервиса, таким образом информируя об элементах, которые имеют неправильный статус в рамках сервиса.
Важно отметить, что эта система позволяет использовать оповещения для элементов, которые становятся критическими в рамках сервиса, даже если общее состояние сервиса является правильным.
Каскадная защита сервиса точно предупреждает о выходе из строя корневых элементов независимо от глубины определенного сервиса.
В приведенном примере мы видим, что один из элементов сервиса находится в критическом состоянии. Даже если основной сервис остается в правильном состоянии, он предупредит нас о состоянии неправильных элементов, запустив оповещение, связанное с элементом, находящимся в кризисе.
В рамках одного сервиса мы можем иметь неограниченное количество подслужб (путей). В версиях, предшествующих OUM725, Pandora FMS оповещала, указывая статус сервиса (нормальный, критический, предупреждение и т.д.). Насиная с версии OUM725, доступен новый макрос, который укажет на корневую причину состояния сервиса.
Чтобы использовать его, мы добавим следующий текст в шаблон, который мы связали с сервисом:
Тело оповещения: образец сообщения Цепочка событий, приведших к такому состоянию службы, выглядит следующим образом: _rca_
В итоге будет получен результат, аналогичный приведенному ниже:
Тело оповещения: образец сообщения Цепочка событий, приведших к такому состоянию службы, выглядит следующим образом: [Aplicación Web -> HW -> Apache server 3] [Aplicación Web -> HW -> Apache server 4] [Aplicación Web -> HW -> Apache server 10] [Aplicación Web -> DB Instances -> MySQL_base_1] [Aplicación Web -> DB Instances -> MySQL_base_5] [Aplicación Web -> Balanceadores -> 192.168.10.139]
Глядя на этот вывод, мы можем интерпретировать, что:
Эта дополнительная информация позволяет уточнить причину состояния сервиса, сокращая расследование причин аварии.
Сервисы- это логические группы, которые являются частью бизнес-структуры организации. По этой причине группировка сервисов может иметь определенный смысл, поскольку во многих случаях между ними могут существовать зависимости, образуя, например, общий сервис (компания) и несколько более частных сервисов (корпоративный веб, коммуникации и т.д.). Чтобы сгруппировать службы, необходимо создать как общую или верхнюю службу, так и нижние службы, которые будут добавлены к ней, чтобы создать логическую древовидную структуру.
Эти группировки помогают нам, например, создавать визуальные карты, настраивать оповещения, применять политики мониторинга и т.д. Таким образом, мы можем создавать оповещения, которые предупреждают, когда компания находится в критическом состоянии, потому что сотрудники отдела продаж не могут выполнять свою работу, или когда один из сайтов не работает на полную мощность из-за технических проблем с его ERP-сервисом.
Для более четкого понимания что такое группировки сервисов ниже приведены два примера.
Вариант использования, в котором проводит мониторинг состояния Сервиса мониторинга Pandora FMS, состоящий из службы Apache, службы MySQL, сервера Pandora и Tentacle, с соответствующими весами важности.
Каждый из этих элементов, в свою очередь, представляет собой Сервис с различными компонентами, образуя, посредством группировки Сервисов, древовидную структуру.
В этом случае общая служба Pandora FMS достигнет статуса critical
при достижении веса 2, и статуса warning
при весе 1. Как видно, четыре компонента имеют разный вес в службе Pandora FMS:
warning
, показывая предупреждение в службе Pandora FMS.warning
, например, из-за чрезмерной загрузки процессора, продвигая предупреждение в общую службу Pandora FMS.warning
сервис Pandora FMS.warning
в общей службе.Сервисы- это логические группы, которые являются частью бизнес-структуры организации. Поэтому может иметь смысл - и быть полезным - группировать сервисы вместе, так как иногда сервисы по отдельности не имеют полного смысла. Чтобы сгруппировать службы, просто добавьте их в качестве элемента к родительской службе, создав таким образом новую логическую группировку.
В следующем примере у нас есть кластер хранилища в HA. Для этого случая была выбрана система из двух параллельно работающих файловых серверов, каждый из которых контролирует процент и состояние ряда дисков, обслуживающих определенные отделы, создавая таким образом древовидную структуру сгруппированных сервисов.
Согласно этой структуре, порог критичности сервиса хранения данных компании будет достигнут только в случае отказа обоих файловых серверов, поскольку это полностью остановит сервис, в то время как отказ только одного из них приведет лишь к ухудшению работы сервиса.
На следующем изображении показана конфигурация весов, присвоенных двум основным элементам сервиса хранения:
На следующем изображении мы видим конфигурацию содержимого и веса сгруппированной службы FS01. Здесь элементы будут иметь определенный вес в соответствии с их критичностью, а именно:
warning
, ак как это данные Да/Нет, зависящие от состояния.warning
.warning
, так что это критически повлияет на службу FS01, только если по крайней мере два диска находятся в критическом состоянии или все четыре диска в состоянии warning.