Мониторинг сервисов

Вернуться в оглавление Документации Pandora FMS

Сервис в Pandora FMS - это совокупность ресурсов информационных технологий (Information Technology, сокращенно IT) на основе их функциональных возможностей.

Сервисом может быть, например, официальный сайт компании, Customer Relationship Management (CRM), приложение поддержки или даже все принтеры компании или в доме. Сервисы PFMS - это логические группы, включающие хосты, маршрутизаторы, коммутаторы, брандмауэры, веб-узлы и даже другие Сервисы.

Pandora FMS представляет Сервисы как совокупность контролируемых элементов (Модули, Агенты или другие Сервисы) индивидуальное состояние которых определенным образом влияет на глобальную функциональность предоставляемого Сервиса. Более подробную информацию вы можете получить в обучающем видео «Мониторинг Сервисов в Pandora FMS».

Базовый мониторинг в Pandora FMS заключается в сборе метрик из различных источников, представляя их в виде систем контроля (называемых Модулями). Мониторинг на основе сервисов позволяет группировать предыдущие элементы таким образом, что, играя с определенными правилами, основанными на накоплении отказов, можно контролировать группы элементов различных типов и их взаимосвязь в более крупном и общем сервисе.

Таким образом, мониторинг Сервисов позволяет проверить общее состояние всех служб. Вы можете узнать, предоставляется ли сервис нормально (зеленый цвет), ухудшается ли он (желтый цвет) или не предоставляется (красный цвет).

Сервисы мониторинга представлены в рамках трех категорий: обычный режим, по важности и по цепочке каскадных событий.

В этом режиме необходимо только указать, какие элементы являются критическими, а какие нет.

Только элементы, помеченные как критические, будут учитываться при расчетах, и только critical статус этих элементов будет иметь значение.

• Когда от 0 до 50% критических элементов находятся в состоянии critical, служба переходит в состояние предупреждения. warning.
• Когда более 50% критических элементов переходят в статус critical, служба переходит в статус critical.

Пример:

• Маршрутизатор - это критический элемент.
• Принтер - это некритический элемент.
• Сервер Apache Web - это критический элемент.

Случай 1:

• Маршрутизатор, статус critical.
• Принтер, статус critical.
• Сервер Apache, статус warning.

Результат: Сервис в состоянии warning, потому что принтер не находится в критическом состоянии, маршрутизатор находится в критическом состоянии представляет только 50% критических элементов, сервер Apache не находится в критическом состоянии и не вносит вклад в оценку.

Случай 2:

• Маршрутизатор, статус critical.
• Принтер, статус critical.
• Сервер Apache, статус critical.

Результат: Сервис в состоянии critical (принтер все еще не имеет никакого значения).

Случай 3:

• Маршрутизатор, статус normal.
• Принтер, статус critical.
• Сервер Apache, статус normal.

Результат: Статус сервиса будет normal, поскольку ни один из ключевых элементов не является critical (опять же, принтер по-прежнему не имеет никакого значения).

Необходимость мониторинга Сервисов как чего-то «абстрактного» возникает при столкновении со следующим вопросом:

Что произойдет с моим приложением, если элемент, который по сути критическим не является, перестанет работать?

Чтобы разрешить все эти сомнения, в Pandora FMS появляется функция мониторинга через Сервисы, которая помогает:

• Ограничить количество получаемых уведомлений. Вы будете получать предупреждения о ситуациях, которые ставят под угрозу надежность служб, предоставляемых компанией или организацией.
• Иметь возможность отслеживать уровень соответствия (в строках Service-level Agreement или SLA).
• Упростить визуализацию мониторинга инфраструктуры.

Для этого необходимо отслеживать каждый элемент, который может негативно повлиять на наше приложение.

Через Консоль Pandora FMS следует определить Дерево Сервиса, в котором необходимо указать элементы, влияющие на приложения или приложения, а также степень их влияния.

Все элементы, которые мы добавляем в деревья сервисов, соответствуют информации, над которой уже проводится мониторинг, либо в виде модулей, конкретных агентов или других сервисов.

Для обозначения степени влияния состояний каждого элемента на общее состояние используется система суммы важности, так что наиболее важные из них (с большим весом) будут более значимы для перевода глобального состояния всего сервиса в неправильное состояние раньше, чем менее важные элементы (с меньшим весом).

Необходимо проводить мониторинг Веб-приложения, сбалансированного с помощью нескольких резервных элементов. Инфраструктура, на которой основано приложение, состоит в данном примере из следующих элементов:

• Двамаршрутизатора в Высокой Доступности (HA).
• Двакоммутатора в HA.
• Двадцать серверов Web Apache®.
• Четыре сервера Приложений WebLogic®.
• Один cluster MySQL® с двумя узлами хранения и двумя узлами обработки SQL.

Нашей целью является узнать, правильно ли работает веб-приложение, т.е. окончательная оценка наших клиентов заключается в том, что приложение получает, обрабатывает и возвращает запросы в строго установленные сроки.

Если бы один из двадцати серверов Apache был отключен от сети, из-за такого большого количества резервирования, было бы разумно оповестить, предупредить всех сотрудников? Каково правило предупреждения?

Можно сделать вывод, что Pandora FMS должна предупреждать только в случае отказа очень важного элемента (например, маршрутизатора) или если несколько серверов Apache одновременно отключатся, но какое их количество? Чтобы определить это, необходимо присвоить весовые значения списку компонентов, описанному выше:

Коммутаторы и маршрутизаторы

По 5 баллов, если они находятся в critical и 3 балла, если они находятся в warning.

Серверы Web

1,2 балла каждому в состоянии critical, мы не наблюдаем статус warning.

Серверы WebLogic

2 балла каждому в состоянии critical.

Cluster MySQL

5 балла каждому в состоянии critical и 3 балла в статусе warning.

Поскольку в нормальной ситуации сумма весов равна нулю, поэтому в данном примере установлено, что порог статуса warning должен быть больше 4, а для состояния critical больше 6:

Сценарии сбоев:

• Веб-сервер Apache отключен (состояние critical): поскольку все остальное в норме и вносит нулевой вклад, общая сумма будет 1,2, а поскольку 1,2 < 4 (порог warning), Служба все еще в нормальном состоянии (статус normal).

• Сервер WEB и WebLogic, оба в состоянии critical> первый вносит 1,2 балла, а второй - 2,0 балла, что в сумме составляет 3,2; это все еще меньше, чем 4, поэтому Служба все еще в порядке, предупреждение или какие-то действия не требуются.

• Теперь отключены два WEB-сервера и один WebLogic : 2 x 1.2 + 1 x 2 = 4.4; в этом случае превышен порог предупреждения, поэтому состояние переходит в статус warning, работа все еще происходит и может не требовать немедленных технических действий, но ясно, что в инфраструктуре возникла проблема.

• К предыдущей ситуации мы добавляем маршрутизатор в статусе critical, и он вызывает новую ситуацию: он добавляет 5 баллов к сумме весов и превышает порог критичности, установленный на уровне 6; Сервис является критическим, Сервис не предоставляется и необходимы немедленные технические действия.

В последней ситуации Pandora FMS оповестит соответствующую рабочую группу (операторов, техников и т.д.).

Сервис Корень - это служба, которая не является частью другого Сервиса. Эта логическая концепция позволяет быстрее осуществлять мониторинг, сокращая очереди на выполнение работ.

Аналогично, и основываясь на этой концепции, когда сервис, определенный в узле Pandora FMS, появляется как элемент сервиса Корень в Метаконсоли, именно сервер Метаконсоли будет оценивать его, обновляя значения, хранящиеся в узле.

Это обеспечивает более эффективную распределенную логику и позволяет реализовать каскадную систему защиты на основе сервисов..

Сервисы в Metaconsole позволяют добавлять в качестве элементов сервиса как другие сервисы, так и модули и/или агенты, поскольку в предыдущих версиях разрешалось добавлять только узловые сервисы.

Компонент PredictionServer должен быть запущен, и должна быть установлена версия Enterprise Pandora Server.

Сервисы могут представлять:

• Модули.
• Полные Агенты.
• Другие Сервисы.

Значения Сервиса рассчитываются с помощью Сервера прогнозирования. (PredictionServer).

После того как все устройства находятся под наблюдением, добавьте в каждый Сервис все модули, агенты или подслужбы, необходимые для наблюдения за Сервисом. Например, для мониторинга сервиса онлайн-Магазина вам нужен модуль для его содержимого, Сервис, который будет проводить мониторинг состояния коммуникаций, и т.д.

Чтобы создать новый сервис, перейдите в раздел Topology Maps > Services.

Появится вид дерева со всеми Сервисами.

Для создания нового сервиса нажмите на кнопку Create Service и заполните появившуюся форму:

Name

Это должно быть уникальное имя, позволяющее идентифицировать Службу.

Description

Обязательно. Это описание, вместо названия, появляется на карте Сервиса, при просмотре таблицы Сервиса и в Widget Сервисов.

Group

Группа, к которой принадлежит сервис, полезно в ограничениях ACL.

Agent to store data

Сервис хранит данные в специальных модулях данных (а именно в модулях прогнозирования). Необходимо ввести агента, который будет контейнером для этих модулей, и в то же время он будет содержать сигналы тревоги (см. следующие шаги).

Mode

Метод расчета весов элементов. Он может иметь 2 значения:

• Smart: Вес и элементы, входящие в состав Сервиса, рассчитываются автоматически на основании установленных правил.
• Manual: Вес и элементы, входящие в состав Сервиса, устанавливаются вручную с фиксированными значениями.
• Critical: Порог веса для установления, что сервис находится в критическом статусе. В режиме Smart это значение будет процентным.
• Предупреждение: Порог веса для установления, что сервис находится в статусе предупреждения. В режиме Smart это значение будет процентным.

Unknown elements as critical

Позволяет указать, что элементы в неизвестном состоянии вносят свой вес, как если бы они были элементом в критическом состоянии.

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), поскольку для элементов не определены веса, способ расчета их состояния следующий:

• Критические элементы вносят общую сумму своего процента в вес сервиса. Это означает, что если, например, у нас есть 4 элемента в Сервисе и только 1 из них является критическим, то этот элемент добавит 25% к весу Сервиса. Если бы вместо 4 элементов было 5, то критический элемент добавил бы 20% к весу Сервиса.
• Предупреждающие элементы вносят половину своего процента в вес Сервиса. Это означает, что если, например, у нас есть 4 элемента в Сервисе и только 1 из них предупреждающий, то этот элемент добавит 12,5% к весу Сервиса. Если бы вместо 4 элементов было 5, то предупреждающий элемент добавил бы 10% к весу Сервиса.

Режим 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

Правило для указания значения пользовательского поля, которое элемент должен иметь, чтобы быть частью сервиса. Указывается текст, который должен быть частью значения желаемого пользовательского поля.

Пример

Если вы решите отфильтровать Агентов группы Servers, чье имя Агента содержит Firewall и имя модуля содержит Network, вы можете получить следующий результат.

Пример

Если бы конфигурация динамического элемента была следующей.

Все модули, имя которых включает «Host Alive», которые находятся в агенте, имя которого включает «SW»,в группе «Servers», с пользовательским полем, имя которого включает «Department» и значение которого также включает «Systems», будут использоваться как элементы сервиса.

• SLA Value Service: Это процентное значение соответствия SLA ( async_data ).
• Service_SLA_Service: Показывает, выполняется SLA или нет ( async_proc ).
• Service_Service: Отображает сумму веса сервиса ( async_data ).

Это список операций, который показывает все созданные сервисы, и к которым пользователь имеет право доступа в Консоли Pandora FMS. Нажмите на Операция > Мониторинг и внутри него Сервисы.

Каждая строка представляет собой Сервис:

Group

Иконка группы, к которой принадлежит сервис и которую может видеть пользователь.

Critical

Пороговое значение сумм веса для присваивания сервису критического статуса.

Warning

Пороговое значение сумм веса для присваивания сервису предупреждающего статуса.

Value

Значение сумм веса элементов, которые содержат сервис.

Статус

Значок, отображающий статус сервиса. Существуют три возможных состояния, обычно представленные следующими цветами:

• Красный: Служба перешла в критическое состояние, так как сумма весов модулей превысила или равна критическому порогу.
• Желтый: Служба перешла в состояние предупреждения, так как сумма весов модулей превысила или равна порогу предупреждения.
• Зеленый: Сервис остается в нормальном или исправном состоянии, поскольку сумма весов модулей не достигла порога предупреждения.
• Gris: Служба находится в неизвестном состоянии, обычно это происходит, когда служба только что создана и в ней нет элементов, или когда сервер прогнозирования Pandora FMS не работает.

SLA

Значение SLA с одним из следующих возможных значений:

• OK: SLA выполняется в течение периода, определенного для SLA сервиса.
• ОШИБКА: SLA не выполняется в течение периода, определенного для SLA сервиса.
• N/A: SLA находится в неизвестном состоянии, поскольку либо еще не собрано достаточно данных для расчета, либо SLA отключен.

Таблица быстрого отображения всех видимых служб и их текущего состояния.

Этот вид доступен при нажатии на название сервиса в списке всех служб или через вкладку со значком лупы в заголовке названия сервиса.

Pandora FMS отобразит страницу, подобную той, что показана на следующем снимке экрана:

Список элементов, составляющих Сервис, расположен внизу:

Type

Значок, представляющий тип элемента: строительный блок для модулей, сложенные блоки для агента или значок сетевой диаграммы для служб.

Name

Текст, содержащий имя агента, или имя агента и модуля, или имя службы. Все они содержат ссылку на соответствующий вид операции.

Weight critical

Значение связанного веса, когда элемент находится в критическом состоянии. Следующие три столбца (Warning weight, Weight Unknown и Weight OK) соответствуют последовательно предупреждению, неизвестный и нормальный./p>

Data

Значение элемента, которое в зависимости от типа может быть:

• Модули: Значение модуля.
• Агенты: Текст, который сообщает о состоянии агента.
• Сервисы: Сумма весов de элементов сервиса, которая была выбрана в качестве элемента для родительской службы.

Статус

Значок, представляющий одним из кодированных цветов статус элемента.

Этот вид отображает сервис, позволяя быстро увидеть, как модули, агенты или подслужбы влияют на мониторинг сервиса. Даже в подслужбах можно увидеть влияние при расчете статуса по сумме весов.

Возможными узлами являются:

Узел Модуля

Изображается с помощью значка графика heartbeat. Этот узел всегда является конечным или листовым узлом, из которого не выходят другие узлы.

Узел Агента

Представлен значком коробки процессора. Это также конечный узел, из которого не будут выходить другие узлы.

Узел Сервиса

Представлен иконой скрещенных молотка и гаечного ключа. Поскольку это Сервис, он должен содержать элементы, представленные в виде выходящих из него ветвей.

Цвет Узлов и соединительных стрелок зависит от статуса узла в соответствии с кодировкой: зеленый ОК, красный критический, желтый предупреждающий или серый неизвестный статус.

Внутри узла вы будете иметь:

• Заголовок: Имя сервиса, агента или сопровождающего модуля агента.
• Список значений (за исключением Сервиса Корня дерева):
  • Критический: Вес, увеличивающийся при нахождении в критическом состоянии, который использует порог для входа в критическое состояние.
  • Предупреждение: Вес, увеличивающийся при нахождении в состоянии предупреждения, который использует порог для входа в это состояние.
  • Нормальный: Вес, увеличивающийся при нахождении в состоянии OK (в нормальном состоянии), который не появится в списке значений.
  • Неизвесный: Вес, увеличивающийся при нахождении в неизвестном состоянии, который не появится в списке значений.

Кроме того, на каждый элемент дерева можно нажать, а конечным пунктом является оперативный просмотр каждого из них.

В визуальной консоли вы можете добавить сервисы в качестве еще одного элемента для отображения на карте.

Создание элемента Сервиса на карте - это такой же процесс, как и для остальных элементов Визуальной карты, но палитра опций будет следующей:

Управление:

• Label: Название которое получит Сервис на визуальной карте.
• Service: Выпадающий список, показывающий Сервисы, к которым у вас есть доступ для добавления на карту.

Следует отметить, что элемент сервиса, в отличие от других элементов визуальной карты, не может быть связан с другими визуальными картами, и всегда ссылка визуальной консоли, на которую можно нажать, имеет в качестве целевого вида карту сервиса в древовидном режиме, описанный выше.

Этот вид позволяет визуализировать сервисы в форме дерева.

Каждый уровень показывает количество элементов, охваченных каждым сервисом или агентом.

• Сервисы: Сообщает общее количество сервисов, агентов и модулей, принадлежащих данной службе.
• Агентов: Сообщает о количестве модулей в критическом (красный), предупреждающем (желтый), неизвестном (серый), не запущенном (синий) и нормальном (зеленый) состоянии.

Сервисы, не относящиеся к другому уровню, всегда будут отображаться на первом уровне. В случае дочерней службы она будет отображаться вложенной в родительскую.

Плановые отключения пересчитывают значение отчетов 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]

Глядя на этот вывод, мы можем интерпретировать, что:

• Серверы Apache 3,4 и 10 находятся в критическом состоянии
• Базы данных MySQL_base 1 и 5 упали
• Балансировщик 192.168.10.139 не отвечает

Эта дополнительная информация позволяет уточнить причину состояния сервиса, сокращая расследование причин аварии.

Сервисы- это логические группы, которые являются частью бизнес-структуры организации. По этой причине группировка сервисов может иметь определенный смысл, поскольку во многих случаях между ними могут существовать зависимости, образуя, например, общий сервис (компания) и несколько более частных сервисов (корпоративный веб, коммуникации и т.д.). Чтобы сгруппировать службы, необходимо создать как общую или верхнюю службу, так и нижние службы, которые будут добавлены к ней, чтобы создать логическую древовидную структуру.

Эти группировки помогают нам, например, создавать визуальные карты, настраивать оповещения, применять политики мониторинга и т.д. Таким образом, мы можем создавать оповещения, которые предупреждают, когда компания находится в критическом состоянии, потому что сотрудники отдела продаж не могут выполнять свою работу, или когда один из сайтов не работает на полную мощность из-за технических проблем с его ERP-сервисом.

Для более четкого понимания что такое группировки сервисов ниже приведены два примера.

Вариант использования, в котором проводит мониторинг состояния Сервиса мониторинга Pandora FMS, состоящий из службы Apache, службы MySQL, сервера Pandora и Tentacle, с соответствующими весами важности.

Каждый из этих элементов, в свою очередь, представляет собой Сервис с различными компонентами, образуя, посредством группировки Сервисов, древовидную структуру.

В этом случае общая служба Pandora FMS достигнет статуса critical при достижении веса 2, и статуса warning при весе 1. Как видно, четыре компонента имеют разный вес в службе Pandora FMS:

• MySQL: Критический для службы Pandora FMS, индивидуальный вес 2, если MySQL не работает. Он приобретает вес 1, если находится в статусе warning, показывая предупреждение в службе Pandora FMS.
• Pandora Server: Критический для службы Pandora FMS, индивидуальный вес 2, если Pandora Server упал. Индивидуальный вес 1, если он находится в статусе warning, например, из-за чрезмерной загрузки процессора, продвигая предупреждение в общую службу Pandora FMS.
• Apache: Он предполагает ухудшение качества сервиса Pandora FMS, но не полное прерывание, поэтому он приобретает индивидуальный вес 1, если он не работает, показывая в статусе warning сервис Pandora FMS.
• Tentacle: Он предполагает снижение и наличие компонентов, которые могут выйти из строя, но он не предполагает полного прекращения работы Pandora FMS, поэтому его индивидуальный вес в случае отказа равен 1, показывая warning в общей службе.

Сервисы- это логические группы, которые являются частью бизнес-структуры организации. Поэтому может иметь смысл - и быть полезным - группировать сервисы вместе, так как иногда сервисы по отдельности не имеют полного смысла. Чтобы сгруппировать службы, просто добавьте их в качестве элемента к родительской службе, создав таким образом новую логическую группировку.

В следующем примере у нас есть кластер хранилища в HA. Для этого случая была выбрана система из двух параллельно работающих файловых серверов, каждый из которых контролирует процент и состояние ряда дисков, обслуживающих определенные отделы, создавая таким образом древовидную структуру сгруппированных сервисов.

Согласно этой структуре, порог критичности сервиса хранения данных компании будет достигнут только в случае отказа обоих файловых серверов, поскольку это полностью остановит сервис, в то время как отказ только одного из них приведет лишь к ухудшению работы сервиса.

На следующем изображении показана конфигурация весов, присвоенных двум основным элементам сервиса хранения:

На следующем изображении мы видим конфигурацию содержимого и веса сгруппированной службы FS01. Здесь элементы будут иметь определенный вес в соответствии с их критичностью, а именно:

• FS01 ALIVE: Критический для службы FS01, так как это виртуальный IP, назначенный первому кластеру дисков, индивидуальный вес 2, потому что если он выйдет из строя, остальные элементы службы будут неработоспособны. В этом случае не существует порога warning, ак как это данные Да/Нет, зависящие от состояния.
• DHCPserver ping: Критический для сервиса FS01, имеет индивидуальный вес 2. В этом случае также отсутствует порог warning .
• Диски: Им присваивается индивидуальный вес 1, если они достигают критического порога, и 0,5 для порога warning, так что это критически повлияет на службу FS01, только если по крайней мере два диска находятся в критическом состоянии или все четыре диска в состоянии warning.

Вернуться в оглавление Документации Pandora FMS