====== Мониторинг сервисов ====== {{indexmenu_n>7}} [[:ru:documentation:start|Вернуться в оглавление Документации Pandora FMS]] ===== Мониторинг сервисов ===== {{:wiki:icono-modulo-enterprise.png |Версия Enterprise.}}Мониторинг сервисов является функцией только версии Enterprise Pandora FMS. ==== Введение ==== **Сервис** в Pandora FMS - это совокупность ресурсов информационных технологий (//Information Technology//, сокращенно **IT**) на основе их функциональных возможностей. Сервисом может быть, например, официальный сайт компании, //Customer Relationship Management// (CRM), приложение поддержки или даже все принтеры компании или в доме. Сервисы PFMS - это логические группы, включающие //хосты//, //маршрутизаторы//, //коммутаторы//, //брандмауэры//, веб-узлы и даже другие Сервисы. Pandora FMS представляет Сервисы как совокупность контролируемых элементов ([[:en:documentation:01_understanding:03_glossary#module|Модули]], [[:en:documentation:01_understanding:03_glossary#agent|Агенты]] или другие **Сервисы**) индивидуальное состояние которых определенным образом влияет на глобальную функциональность предоставляемого Сервиса. Более подробную информацию вы можете получить в обучающем видео «[[https://www.youtube.com/watch?v=9b7tbl7Sxcg|Мониторинг Сервисов в Pandora FMS]]». ==== Сервисы в Pandora FMS ==== [[:en:documentation:03_monitoring:01_intro_monitoring|Базовый мониторинг]] в Pandora FMS заключается в сборе метрик из различных источников, представляя их в виде систем контроля (называемых **Модулями**). Мониторинг на основе сервисов позволяет группировать предыдущие элементы таким образом, что, играя с определенными правилами, основанными на накоплении отказов, можно контролировать группы элементов различных типов и их взаимосвязь в более крупном и общем сервисе. Таким образом, мониторинг Сервисов позволяет проверить общее состояние всех служб. Вы можете узнать, предоставляется ли сервис нормально (зеленый цвет), ухудшается ли он (желтый цвет) или не предоставляется (красный цвет). Сервисы мониторинга представлены в рамках трех категорий: обычный режим, по //важности// и по цепочке каскадных событий. === Как работает простой режим === В этом режиме необходимо только указать, какие элементы являются критическими, а какие нет. {{ :wiki:new_service_simple_mode.png }} Только элементы, помеченные как критические, будут учитываться при расчетах, и только ''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''. ^Тип элемента ^Приписывание веса ^^^| | ::: ^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 | Сценарии сбоев: * Веб-сервер 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** оповестит соответствующую рабочую группу (операторов, техников и т.д.). Вы можете получить интересную информацию о Мониторинге Сервисов в [[https://pandorafms.com/blog/service-monitoring/|блоге Pandora FMS]] === Сервисы корень === {{:wiki:icono-modulo-enterprise.png |Версия Enterprise.}}Версия NG 726 или выше. Сервис Корень - это служба, которая не является частью другого Сервиса. Эта логическая концепция позволяет быстрее осуществлять мониторинг, сокращая очереди на выполнение работ. Аналогично, и основываясь на этой концепции, когда сервис, определенный в узле Pandora FMS, появляется как элемент сервиса Корень в [[:en:documentation:06_metaconsole:01_introduction#introduction|Метаконсоли]], именно сервер Метаконсоли будет оценивать его, обновляя значения, хранящиеся в узле. Это обеспечивает более эффективную распределенную логику и позволяет реализовать каскадную систему [[:ru:documentation:04_using:01_alerts|защиты на основе сервисов.]]. Сервисы в Metaconsole позволяют добавлять в качестве элементов сервиса как другие сервисы, так и модули и/или агенты, поскольку в предыдущих версиях разрешалось добавлять только узловые сервисы. ==== Создание нового Сервиса ==== === Pandora Server === Компонент **PredictionServer** должен быть включен, чтобы использовать Сервисы. Компонент [[:en:documentation:01_understanding:02_architecture#the_prediction_server|PredictionServer ]] должен быть запущен, и должна быть установлена версия Enterprise Pandora Server. === Введение === Сервисы могут представлять: * Модули. * Полные Агенты. * Другие Сервисы. Значения Сервиса рассчитываются с помощью Сервера прогнозирования. (//PredictionServer//). После того как все устройства находятся под наблюдением, добавьте в каждый Сервис все модули, агенты или подслужбы, необходимые для наблюдения за Сервисом. Например, для мониторинга сервиса //онлайн-Магазина// вам нужен модуль для его содержимого, Сервис, который будет проводить мониторинг состояния коммуникаций, и т.д. Чтобы создать новый сервис, перейдите в раздел **Topology Maps** > **Services**. {{ :wiki:menu_services.png?450 }} Появится вид дерева со всеми Сервисами. {{ :wiki:arbol_servicios.png?600 }} === Начальная конфигурация === Для создания нового сервиса нажмите на кнопку **Create Service** и заполните появившуюся форму: {{ :wiki:formulario_servicios.png?700 }} **Name** Это должно быть уникальное имя, позволяющее идентифицировать Службу. **Description** Обязательно. Это описание, вместо названия, появляется на карте Сервиса, при просмотре таблицы Сервиса и в //Widget// Сервисов. **Group** Группа, к которой принадлежит сервис, полезно в ограничениях [[:ru:documentation:04_using:11_managing_and_administration|ACL]]. **Agent to store data** Сервис хранит данные в специальных модулях данных (а именно в модулях прогнозирования). Необходимо ввести агента, который будет контейнером для этих модулей, и в то же время он будет содержать сигналы тревоги (см. следующие шаги). **Примечание**: Обратите внимание, что интервал, в котором будут выполняться все вычисления сервисных модулей, зависит от интервала агента, сконфигурированного как контейнер. {{ :wiki:formulario_servicios_detalle_1.png?600 |Режим для расчетов веса.}} **Mode** Метод расчета весов элементов. Он может иметь 2 значения: * **Smart**: Вес и элементы, входящие в состав Сервиса, рассчитываются автоматически на основании установленных правил. * **Manual**: Вес и элементы, входящие в состав Сервиса, устанавливаются вручную с фиксированными значениями. * **Critical**: Порог веса для установления, что сервис находится в критическом статусе. В режиме **Smart** это значение будет процентным. * **Предупреждение**: Порог веса для установления, что сервис находится в статусе предупреждения. В режиме **Smart** это значение будет процентным. **Unknown elements as critical** Позволяет указать, что элементы в неизвестном состоянии вносят свой вес, как если бы они были элементом в критическом состоянии. Режим //smart// доступен только начиная с версии //7.0 NG 748// Pandora FMS. Режимы //автоматический// и //простой// предыдущих версий станут //ручными// при применении //MR 40// в обновлении версии. **Favorite** Создайте прямую ссылку в боковом меню, и вы сможете фильтровать Сервисы при просмотре на основе этого критерия. {{ :wiki:servicios_favoritos.png?700 }} **Quiet** Активирует бесшумный режим работы Службы, чтобы она не генерировала предупреждения или события. **Cascade protection enabled** Активирует каскадную защиту на элементах Сервиса. Не должны генерироваться предупреждения или события, если они принадлежат Сервису (или //подслужбе//), который находится в критическом состоянии. **Calculate continuos SLA** Активирует создание модулей SLA и значений SLA для текущего Сервиса. Он используется в случаях, когда количество необходимых Сервисов настолько велико, что это может повлиять на производительность. Если вы отключите эту последнюю опцию, после создания Сервиса удалится история данных этих модулей, таким образом, вы потеряете информацию. **SLA interval** Период времени для расчета эффективного SLA сервиса. **SLA limit** Порог состояния OK сервиса, который будет считаться положительным SLA в течение периода времени, настроенного в предыдущем поле. **Alerts** В этом разделе вы должны выбрать шаблоны, которые Сервис будет иметь для запуска оповещения, когда служба переходит в состояние предупреждения, критическое, неизвестное или когда SLA службы не соблюдается. === Конфигурация элементов === После правильного заполнения формы регистрируется пустой Сервис, который необходимо заполнить своими элементами. В форме редактирования Сервиса выберите вкладку 'Конфигурация элементов'. {{ :wiki:elementos_servicios.png?600 }} Нажмите на кнопку **Add element**, и появится всплывающее окно с формой. //Форма будет немного отличаться, если сервис находится в режиме// **smart** //или в режиме//**manual**. {{ :wiki:formulario_elementos_servicios.png?550 }} **Description** Необязательный текст, который будет использоваться для представления элемента в карте сервиса. Если не указано, то используется имя модуля, агента или сервиса (в зависимости от добавленного элемента). **Type** Выберите Сервис, Модуль или Агент; если вы находитесь в режиме //Smart//, также появится тип **Dynamic** (динамический). **Agent** Система поиска агентов (видна, если элемент для создания или редактирования имеет тип Агент или Модуль). **Module** Выпадающий список с модулями Агента, ранее выбранными в поисковой системе (виден только при редактировании или создании элемента для модуля типа Сервис). **Сервис** Выпадающий список сервисов для создания элемента (виден только в том случае, если создаваемый или редактируемый элемент имеет тип Сервис). Вы всегда должны помнить, что сервисы, которые появляются в выпадающем списке, **не** являются родителями сервиса, это необходимо для отображения правильной древовидной структуры зависимости между сервисами. == Ручной режим == Следующие поля доступны только для сервисов в ручном режиме: * ''critical''> Вес, который элемент добавит к сервису, находясь в критическом состоянии. * ''warning''> Вес, который элемент добавит к сервису, находясь в состоянии предупреждения. * ''unknown''> Вес, который элемент добавит к сервису, находясь в неизвестном состоянии. * ''normal''> Вес, который элемент добавит к сервису, находясь в нормальном состоянии. Для расчета статуса сервиса вес каждого из его элементов суммируется на основе его статуса, и если он превышает пороговые значения, установленные в сервисе для предупреждения или критического состояния, статус сервиса изменяется на предупредительный или критический в зависимости от ситуации. == Режим Smart == В сервисах в интеллектуальном режиме (Smart), поскольку для элементов не определены веса, способ расчета их состояния следующий: * Критические элементы вносят **общую сумму** своего процента в вес сервиса. Это означает, что если, например, у нас есть 4 элемента в Сервисе и только 1 из них является критическим, то этот элемент добавит 25% к весу Сервиса. Если бы вместо 4 элементов было 5, то критический элемент добавил бы 20% к весу Сервиса. * Предупреждающие элементы вносят **половину** своего процента в вес Сервиса. Это означает, что если, например, у нас есть 4 элемента в Сервисе и только 1 из них предупреждающий, то этот элемент добавит 12,5% к весу Сервиса. Если бы вместо 4 элементов было 5, то предупреждающий элемент добавил бы 10% к весу Сервиса. **Режим Dynamic** {{ :wiki:topology_maps-services-edit_service_elements-add_element-01.png }} Следующие поля доступны только для элементов типа **Dynamic** (сервисы в режиме **Smart**): **Matching object types** Выпадающий список для выбора того, будут ли элементы, для которых будут оцениваться динамические правила и которые будут частью сервиса, агентами или модулями. **Filter by group** Правило для указания группы, к которой должен принадлежать элемент, чтобы быть частью сервиса. **Having agent name** Правило для указания имени Агента, которым должен обладать элемент, чтобы быть частью Сервиса. Указывается текст, который является частью имени желаемого Агента. **Having module name** Правило для указания имени модуля, который должен иметь элемент, чтобы быть частью Сервиса. Указывается текст, который является частью названия нужного модуля. {{ :wiki:topology_maps-services-edit_service_elements-add_element-02.png }} **Use regular expresions selector** Если вы включите эту опцию, будет использоваться механизм поиска через [[https://ru.wikipedia.org/wiki/Регулярные_выражения|Регулярные Выражения]] (**regex** или **regexp**) но в соответствии с тем, как [[https://dev.mysql.com/doc/refman/8.0/en/regexp.html|MySQL обрабатывает регулярные выражения]]. **Having custom field name** Правило для указания //имени// пользовательского поля, которое элемент должен иметь, чтобы быть частью сервиса. Указывается текст, который является частью названия желаемого пользовательского поля. **Having custom field value** Правило для указания //значения// пользовательского поля, которое элемент должен иметь, чтобы быть частью сервиса. Указывается текст, который должен быть частью значения желаемого пользовательского поля. {{ :wiki:topology_maps-services-edit_service_elements-add_element-03.png }} Вы должны поместить текст в оба поля, чтобы он учитывался при поиске в пользовательских полях. {{ :wiki:topology_maps-services-edit_service_elements-add_element-04.png }} Начиная с версии NG 752 можно добавлять поиск в дополнительных пользовательских полях, которые будут выбраны, если они соответствуют любой из заданных пар ключевых слов. {{ :wiki:topology_maps-services-edit_service_elements-add_element-07.png }} **Пример ** Если вы решите отфильтровать Агентов группы **Servers**, чье имя Агента //содержит// ''Firewall'' и имя модуля //содержит// ''Network'', вы можете получить следующий результат. {{ :wiki:topology_maps-services-edit_service_elements-add_element-06.png }} **Пример ** Если бы конфигурация динамического элемента была следующей. {{ :wiki:topology_maps-services-edit_service_elements-add_element-05.png }} Все модули, имя которых включает "Host Alive", которые находятся в агенте, имя которого включает "SW",в группе "Servers", с пользовательским полем, имя которого включает "Department" и значение которого также включает "Systems", будут использоваться как элементы сервиса. Динамические элементы не подвержены каскадной защите Сервисов. === Модули, которые создаются при конфигурировании сервиса: === * **SLA Value Service**: Это процентное значение соответствия SLA ( ''async_data'' ). * **Service_SLA_Service**: Показывает, выполняется SLA или нет ( ''async_proc'' ). * **Service_Service**: Отображает сумму веса сервиса ( ''async_data'' ). ==== Визуализация Сервисов ==== === Простой список всех сервисов === Это список операций, который показывает все созданные сервисы, и к которым пользователь имеет право доступа в Консоли Pandora FMS. Нажмите на **Операция** > **Мониторинг** и внутри него **Сервисы**. {{ :wiki:services_list_services_admin_v5.png?800 }} Каждая строка представляет собой Сервис: **Group** Иконка группы, к которой принадлежит сервис и которую может видеть пользователь. **Critical** Пороговое значение сумм веса для присваивания сервису критического статуса. **Warning** Пороговое значение сумм веса для присваивания сервису предупреждающего статуса. **Value** Значение сумм веса элементов, которые содержат сервис. **Статус** Значок, отображающий статус сервиса. Существуют три возможных состояния, обычно представленные следующими цветами: * **Красный**: Служба перешла в критическое состояние, так как сумма весов модулей превысила или равна критическому порогу. * **Желтый**: Служба перешла в состояние предупреждения, так как сумма весов модулей превысила или равна порогу предупреждения. * **Зеленый**: Сервис остается в нормальном или исправном состоянии, поскольку сумма весов модулей не достигла порога предупреждения. * **Gris**: Служба находится в неизвестном состоянии, обычно это происходит, когда служба только что создана и в ней нет элементов, или когда сервер прогнозирования Pandora FMS не работает. **SLA** Значение SLA с одним из следующих возможных значений: * **OK**: SLA выполняется в течение периода, определенного для SLA сервиса. * **ОШИБКА**: SLA не выполняется в течение периода, определенного для SLA сервиса. * **N/A**: SLA находится в неизвестном состоянии, поскольку либо еще не собрано достаточно данных для расчета, либо SLA отключен. == Таблица всех служб == Таблица быстрого отображения всех видимых служб и их текущего состояния. {{ :wiki:services_table_view.png }} == Простой список сервиса и всех содержащихся в ней элементов == Этот вид доступен при нажатии на название сервиса в списке всех служб или через вкладку со значком лупы в заголовке названия сервиса. Pandora FMS отобразит страницу, подобную той, что показана на следующем снимке экрана: {{ :wiki:services_list_elements_operation_v5.png?800 }} Список элементов, составляющих Сервис, расположен внизу: **Type** Значок, представляющий тип элемента: строительный блок для модулей, сложенные блоки для агента или значок сетевой диаграммы для служб. **Name** Текст, содержащий имя агента, или имя агента и модуля, или имя службы. Все они содержат ссылку на соответствующий вид операции. **Weight critical** Значение связанного веса, когда элемент находится в критическом состоянии. Следующие три столбца (**Warning weight**, **Weight Unknown** и **Weight OK**) соответствуют последовательно //предупреждению//, //неизвестный// и //нормальный//./p> **Data** Значение элемента, которое в зависимости от типа может быть: * **Модули**: Значение модуля. * **Агенты**: Текст, который сообщает о состоянии агента. * **Сервисы**: Сумма весов de элементов сервиса, которая была выбрана в качестве элемента для родительской службы. **Статус** Значок, представляющий одним из кодированных цветов статус элемента. Обратите внимание, что расчет сервисов производится сервером PredictionServer, поэтому данные рассчитываются за периоды времени. Поэтому может случиться так, что при добавлении элементов они обновляются только тогда, когда сервис пересчитывается сервером. == Вид карты сервиса == Этот вид отображает сервис, позволяя быстро увидеть, как модули, агенты или подслужбы влияют на мониторинг сервиса. Даже в подслужбах можно увидеть влияние при расчете статуса по сумме весов. {{ :wiki:services_servicemap_v5.png?800 }} Возможными узлами являются: **Узел Модуля** Изображается с помощью значка графика heartbeat. Этот узел всегда является конечным или листовым узлом, из которого не выходят другие узлы. **Узел Агента** Представлен значком коробки процессора. Это также конечный узел, из которого не будут выходить другие узлы. **Узел Сервиса** Представлен иконой скрещенных молотка и гаечного ключа. Поскольку это Сервис, он должен содержать элементы, представленные в виде выходящих из него ветвей. Цвет Узлов и соединительных стрелок зависит от статуса узла в соответствии с кодировкой: зеленый ОК, красный критический, желтый предупреждающий или серый неизвестный статус. Внутри узла вы будете иметь: * **Заголовок**: Имя сервиса, агента или сопровождающего модуля агента. * **Список значений** (за исключением Сервиса Корня дерева): * **Критический**: Вес, увеличивающийся при нахождении в критическом состоянии, который использует порог для входа в критическое состояние. * **Предупреждение**: Вес, увеличивающийся при нахождении в состоянии предупреждения, который использует порог для входа в это состояние. * **Нормальный**: Вес, увеличивающийся при нахождении в состоянии OK (в нормальном состоянии), который не появится в списке значений. * **Неизвесный**: Вес, увеличивающийся при нахождении в неизвестном состоянии, который не появится в списке значений. Кроме того, на каждый элемент дерева можно нажать, а конечным пунктом является оперативный просмотр каждого из них. Когда служба находится в режиме //simple//, рядом с каждым критическим элементом появится красный восклицательный знак. == Сервисы в визуальной консоли == В визуальной консоли вы можете добавить сервисы в качестве еще одного элемента для отображения на карте. {{ :wiki:servicios1.jpg?800 |Нажмите для увеличения}} Создание элемента Сервиса на карте - это такой же процесс, как и для остальных элементов Визуальной карты, но палитра опций будет следующей: {{ :wiki:servicios2.jpg?800 |Haga clic para ampliar}} Управление: * **Label**: Название которое получит Сервис на визуальной карте. * **Service**: Выпадающий список, показывающий Сервисы, к которым у вас есть доступ для добавления на карту. Следует отметить, что элемент сервиса, в отличие от других элементов визуальной карты, не может быть связан с другими визуальными картами, и всегда ссылка визуальной консоли, на которую можно нажать, имеет в качестве целевого вида карту сервиса в древовидном режиме, описанный выше. === Древовидный вид сервиса === Этот вид позволяет визуализировать сервисы в форме дерева. Каждый уровень показывает количество элементов, охваченных каждым сервисом или агентом. * Сервисы: Сообщает общее количество сервисов, агентов и модулей, принадлежащих данной службе. * Агентов: Сообщает о количестве модулей в критическом (красный), предупреждающем (желтый), неизвестном (серый), не запущенном (синий) и нормальном (зеленый) состоянии. Сервисы, не относящиеся к другому уровню, всегда будут отображаться на первом уровне. В случае дочерней службы она будет отображаться вложенной в родительскую. {{ :wiki:services_treeview.png?600 }} Ограничение разрешений 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 это день, неделя или месяц), тем менее резкой будет эскалация. ==== Каскадная защита сервисов ==== {{:wiki:icono-modulo-enterprise.png |Версия Enterprise.}}Версия NG 725 или выше. Можно динамически отключать эти элементы Сервиса. Это позволяет избежать лавины предупреждений для каждого элемента, принадлежащего сервису или подслужбе. Когда функция 'каскадная защита сервиса' активирована, выполняется действие, связанное с шаблоном, который был настроен для корневого сервиса, таким образом информируя об элементах, которые имеют неправильный статус в рамках сервиса. Важно отметить, что эта система позволяет использовать оповещения для элементов, которые становятся критическими в рамках сервиса, даже если общее состояние сервиса является правильным. Каскадная защита сервиса точно предупреждает о выходе из строя корневых элементов независимо от глубины определенного сервиса. {{ :wiki:service2test.png?800 }} В приведенном примере мы видим, что один из элементов сервиса находится в критическом состоянии. Даже если основной сервис остается в правильном состоянии, он предупредит нас о состоянии неправильных элементов, запустив оповещение, связанное с элементом, находящимся в кризисе. ==== Анализ корневых причин ==== В рамках одного сервиса мы можем иметь неограниченное количество подслужб (путей). В версиях, предшествующих 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 === Вариант использования, в котором проводит мониторинг состояния Сервиса мониторинга Pandora FMS, состоящий из службы Apache, службы MySQL, сервера Pandora и Tentacle, с соответствующими весами важности. {{ :wiki:pesos.jpg?800 |Haga clic para ampliar}} Каждый из этих элементов, в свою очередь, представляет собой Сервис с различными компонентами, образуя, посредством группировки Сервисов, древовидную структуру. {{ :wiki:arbol.jpg?800 |Haga clic para ampliar}} В этом случае общая служба 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'' в общей службе. === Сервис кластерного хранения, объединение сервисов === Сервисы- это логические группы, которые являются частью бизнес-структуры организации. Поэтому может иметь смысл - и быть полезным - группировать сервисы вместе, так как иногда сервисы по отдельности не имеют полного смысла. Чтобы сгруппировать службы, просто добавьте их в качестве элемента к родительской службе, создав таким образом новую логическую группировку. В следующем примере у нас есть //кластер// хранилища в [[:en:documentation:05_big_environments:06_ha|HA]]. Для этого случая была выбрана система из двух параллельно работающих файловых серверов, каждый из которых контролирует процент и состояние ряда дисков, обслуживающих определенные отделы, создавая таким образом древовидную структуру сгруппированных сервисов. {{ :wiki:cluster.jpg?800 |Haga clic para ampliar}} Согласно этой структуре, порог критичности сервиса хранения данных компании будет достигнут только в случае отказа обоих файловых серверов, поскольку это полностью остановит сервис, в то время как отказ только одного из них приведет лишь к ухудшению работы сервиса. На следующем изображении показана конфигурация весов, присвоенных двум основным элементам сервиса хранения: {{ :wiki:pesoscluster.jpg?800 |Haga clic para ampliar}} На следующем изображении мы видим конфигурацию содержимого и веса сгруппированной службы FS01. Здесь элементы будут иметь определенный вес в соответствии с их критичностью, а именно: * **FS01 ALIVE:** Критический для службы FS01, так как это виртуальный IP, назначенный первому //кластеру// дисков, индивидуальный вес 2, потому что если он выйдет из строя, остальные элементы службы будут неработоспособны. В этом случае не существует порога ''warning'', ак как это данные Да/Нет, зависящие от состояния. * **DHCPserver ping:** Критический для сервиса FS01, имеет индивидуальный вес 2. В этом случае также отсутствует порог ''warning'' . * **Диски**: Им присваивается индивидуальный вес 1, если они достигают критического порога, и 0,5 для порога ''warning'', так что это критически повлияет на службу FS01, только если по крайней мере два диска находятся в критическом состоянии или все четыре диска в состоянии warning. {{ :wiki:pesosfs01.jpg?800 |Haga clic para ampliar}} [[:ru:documentation:start|Вернуться в оглавление Документации Pandora FMS]]