Таблица меню программирования пандора

Вернитесь к индексу документации В этом разделе объясняются некоторые принципы проектирования и особенности Pandora FMS.

1.1 Разработка базы данных Pandora FMS

Первые версии Pandora FMS, от версии 0.83 до версии 1.1, были основаны на очень простой идее: один фрагмент данных. Одна вставка в базу данных. Это позволяло программе выполнять простые операции поиска, вставки и другие операции.

Хотя его разработка имела некоторые преимущества, был большой недостаток: масштабируемость.

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

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

Текущая версия Pandora FMS реализует сжатие данных в режиме реального времени для каждой вставки. Он также позволяет сжимать данные на основе интерполяции. Задача обслуживания также позволяет автоматически удалять те данные, которые превышают определенный период времени.

Новая система обработки данных Pandora FMS хранит только «новые» данные. Если дублированное значение попадет в систему, оно не будет сохранено в базе данных.

Очень полезно свести базу данных к минимуму, и она работает для всех модулей Pandora FMS: числовых. Инкрементных,логических и строковых. В логическом типе данных индекс сжатия очень высок, так как это данные, которые редко меняются. Тем не менее, элементы «индекса» хранятся каждые 24 часа, поэтому существует минимум информации. Которая используется в качестве ссылки при сжатии информации.

Эта система частично решает проблему масштабируемости, сокращая использование базы данных на 40-70%. Но есть и другие способы повышения масштабируемости. Pandora FMS позволяет разбивать компоненты. Чтобы сбалансировать нагрузку на обработку файлов данных и выполнение сетевых модулей на разных серверах. Это позволяет иметь несколько серверов Pandora FMS (сетевые серверы, data или SNMP), веб-консоли Pandora FMS. А также базу данных или высокопроизводительный кластер (с MySQL5) на разных серверах.

Корректировки подразумевают большие изменения при чтении или интерпретации данных. В последних версиях Pandora FMS графический движок был переработан с нуля. Чтобы иметь возможность быстро представлять данные с помощью новой модели хранения данных. Процессы сжатия имеют определенные последствия при чтении и интерпретации данных графически. Представьте себе, что агент не может связаться с Pandora FMS. Поэтому сервер Pandora FMS не получает данных от этого агента. И существует период времени. В течение которого сервер не имеет никакой информации от модулей указанного агента. Если вы получите доступ к графическому изображению одного из этих модулей. Интервал без данных будет представлен как не претерпевающий никаких изменений. Как горизонтальная линия. Если Pandora FMS не получит новых значений, она будет считать, что никаких изменений не было, и все будет выглядеть так. Как было в последнем уведомлении.

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

Модульный граф full.jpg

Это будет эквивалентная графика для тех же данных, ожидаемых при сбое соединения, примерно с 05:55 до 15:29.

Модульный граф peak.jpg

В Pandora FMS 1.3 добавлена новая общая графика для агентов. Он показывает свою связность и скорость доступа от модуля к агенту. Этот график дополняет другие графики, которые отображаются, когда агент имеет активность и получает данные. Это пример агента который регулярно подключается к серверу:

График доступа full.jpg

Если у вас есть пики (низкие) на этом графике. То могут возникнуть некоторые проблемы или медленные соединения в соединении агента Pandora FMS с сервером Pandora FMS. А также проблемы с подключением с сетевого сервера.

Начиная с версии Pandora FMS 5 и далее была добавлена новая функция, позволяющая скрещивать данные событий типа

Grafica-dsconocido.jpg

1.1.1 Другие технические аспекты БД

В ходе обновления программного обеспечения были внесены небольшие улучшения в реляционную модель базы данных Pandora FMS. Одним из изменений является индексация по типам модулей. Таким образом, Pandora FMS может получить доступ к информации быстрее, поскольку она разбита на разные таблицы.

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

Кроме того, такие факторы, как числовое представление меток времени (в формате _timestamp_ UNIX). Ускоряют поиск диапазона дат. Их сравнение и т. д. Эта работа позволила значительно улучшить время поиска и вставки.

1.1.2 Основные таблицы базы данных

Info.png

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

 

Это диаграмма ER, а также подробное описание основных таблиц базы данных Pandora FMS.

Нажмите на изображение, чтобы увеличить его
  • taddress: Он содержит дополнительные адреса агентов.
  • taddress_agent: Адреса, связанные с агентом(rel. taddress/tagent).
  • tagente: Он содержит информацию об агентах Pandora FMS.
    • id_agent: уникальный идентификатор агента.
    • имя: Имя агента (с учетом регистра).
    • адрес: Адрес агента. Можно назначить дополнительные адреса через taddress.
    • comentarios: Свободный текст.
    • id_group: Идентификатор группы, к которой принадлежит агент (ref. tgrupo).
    • last_contact: Дата последнего контакта агента, либо через программный агент, либо через удаленный модуль.

    • режим: Режим работающего агента, 0 нормальных, 1 тренировка.
    • интервал: Интервал выполнения агента. В зависимости от этого интервала агент будет показан как выходящий за пределы.
    • id_os: Идентификатор агента SO (ref. tconfig_os).
    • os_version: версия SO (свободный текст).
    • agent_version: Версия агента (свободный текст). Обновляется программными агентами.
    • last_remote_contact: Последний агент-дата получения контакта. В случае программных агентов, в отличие от last_contact, дата отправляется самим агентом.
    • отключено: Состояние агента, включено (0) или отключено (1).
    • id_parent: Идентификатор родительского агента (ref. tagent).

    • custom_id: пользовательский идентификатор агента. Полезно взаимодействовать с другими инструментами.
    • server_name: Имя сервера, которому назначен агент.
    • cascade_protection: Каскадная защита. Отключено на 0. При значении 1 он предотвращает срабатывание связанных с агентом предупреждений. Если было вызвано критическое родительское предупреждение агента. Для получения дополнительной информации ознакомьтесь с разделом об оповещениях.
  • tagent_data: Данные, полученные от каждого модуля. Если для того же модуля последние полученные данные совпадают с предыдущими. То они не будут добавлены (но tagent_status будет обновлен).

    Инкрементные и строковые данные сохраняются в разных таблицах.

  • tagent_data_inc: Инкрементный тип данных.
  • tagent_data_string: Строковый тип данных.
  • tagent_status: Информация о текущем состоянии каждого модуля.
    • id_agent_status: Идентификатор.
    • id_agent_module: Идентификатор модуля(ref. tagent_module).
    • данные: Значение последних полученных данных.
    • временная метка: Данные последних полученных данных (они могут исходить от агента).
    • статус: Статус модуля: 0 НОРМАЛЬНЫЙ, 1 КРИТИЧЕСКИЙ, 2 ПРЕДУПРЕЖДАЮЩИХ, 3 НЕИЗВЕСТНЫХ.

    • id_agent: Идентификатор агента, связанный с модулем (ref. tagent).
    • last_try: Дата последнего успешного выполнения модуля.
    • utimestamp: Дата последнего выполнения модуля в формате UNIX.
    • current_interval: Интервал выполнения модуля в секундах.
    • running_by: Имя сервера, выполнившего модуль.
    • last_execution_try: Дата последней попытки выполнения модуля. Казнь могла провалиться.
    • status_changes: Количество изменений состояния. Он используется для того, чтобы избежать непрерывных изменений состояния. Для получения дополнительной информации ознакомьтесь с разделом

      Операции.

    • last_status: Предыдущий статус модуля.
  • tagent_module: Конфигурация модуля.
    • id_agent_module: Уникальный идентификатор модуля.
    • id_agente: Идентификатор агента, связанный с модулем (ref. tagent).
    • id_tipe_module: Тип модуля (ref. ttipo_modulo).
    • описание: Свободный текст.
    • имя: Имя модуля.
    • макс.: максимальное значение модуля. Данные выше этого значения недопустимы.
    • min: Минимальное значение модуля. Данные ниже этого значения недопустимы.
    • module_interval: Интервал выполнения модуля в секундах.
    • tcp_port: Порт назначения TCP в сетевых модулях и плагинах. Имя столбца для чтения в модулях WMI.

    • tcp_send: Данные для отправки в сетевых модулях. Пространство имен в модулях WMI.
    • tcp_rcv: Ожидаемый ответ в сетевых модулях.
    • snmp_community: SNMP-сообщество в сетевых модулях. Фильтр в модулях WMI.
    • snmp_oid: OID в сетевых модулях. WQL-запрос в модулях WMI.
    • ip_target: Адрес назначения в сетевых модулях, плагине и WMI.
    • id_module_group: Идентификатор группы, к которой принадлежит модуль (ref. tmodule_group).
    • флаг: Флаг принудительного исполнения. Если значение равно 1, то модуль будет выполнен, хотя и не имеет права на интервал.
    • id_modulo: Идентификатор модулей, которые не могут быть распознаны по его id_module_type.

      6 для модулей WMI, 7 для ВЕБ-модулей.

    • отключено: Состояние модуля, 0 включено, 1 отключено.
    • id_export: Идентификатор сервера экспорта, связанного с модулем (ref. tserver).
    • plugin_user: Имя пользователя в модулях plugin и WMI, user-agent в веб-модулях.
    • plugin_pass: Пароль в модулях плагинов и WMI, количество повторных попыток в веб-модулях.
    • plugin_parameter: Дополнительные параметры в модулях плагинов, настройка задачи Goliat в веб-модулях.
    • id_plugin: Идентификатор плагина, связанного с модулем в plugin modules (ref. tplugin).

    • post_process: Значение, на которое данные модуля будут умножены перед сохранением.
    • prediction_module: 1, если это модуль прогнозирования, 2, если это сервисный модуль, 3, если он синтетический. И 0 в любом другом случае.
    • max_timeout: Время ожидания модулей плагина в секундах.
    • custom_id: индивидуальный идентификатор модуля. Полезно взаимодействовать с другими инструментами.
    • history_data: Если он установлен на 0, то данные модуля не будут сохранены в tagent_data*, а будут обновлены только tagent_status.
    • min_warning: Минимальное значение, активирующее состояние ПРЕДУПРЕЖДЕНИЯ.

    • max_warning: Максимальное значение, активирующее состояние ПРЕДУПРЕЖДЕНИЯ.
    • min_critical: Минимальное значение. Которое активирует КРИТИЧЕСКОЕ состояние.
    • max_critical: Максимальное значение. Которое активирует КРИТИЧЕСКОЕ состояние.
    • min_ff_event: Количество раз, когда должен быть выполнен термин изменения состояния, прежде чем это изменение произойдет. Это связано с tagent_status.status_changes.
    • delete_pending: Если он установлен на 1, то он будет удален сценарием обслуживания pandora_db.pl база данных.
    • custom_integer_1: Когда prediction_module равен 1, это поле является идентификатором модуля, из которого получаются данные для прогнозов. Когда prediction_module равен 2, это поле является идентификатором службы, назначенным модулю.
    • custom_integer_2:
    • custom_string_1:
    • custom_string_2:
    • custom_string_3:
  • tagent_access: Новая запись будет добавляться каждый раз при получении данных от агента на любой сервер, но не более одной минуты. Чтобы избежать перегрузки базы данных. Его можно отключить, установив значение agentaccess равным 0 в конфигурационном файле pandora_server.conf.
  • talert_snmp: Конфигурация оповещения SNMP.
  • talert_commands: Команды, которые могут быть выполнены из действий, связанных с предупреждением (например, отправка почты).

  • talert_actions: Экземпляр команды, связанный с любым предупреждением (например, отправить почту администратору).
  • talert_templates: Шаблоны предупреждений.

    • id: уникальный идентификатор шаблона.
    • имя: Имя шаблона.
    • описание: Описание.
    • id_alert_action: Идентификатор действия по умолчанию, связанного с шаблоном.
    • field1: Настраиваемое поле 1(свободный текст).
    • field2: Настраиваемое поле 2(свободный текст).
    • field3: Настраиваемое поле 3 (свободный текст).
    • тип: Тип оповещения в соответствии с инициирующим термином (‘regex’, ‘max_min’, ‘max’, ‘min’, ‘equal’, ‘not_equal’, ‘warning’. ‘critical’).

    • значение: Значение для предупреждений типа regex (свободный текст).
    • matches_value: Когда установлено значение 1, оно инвертирует логику триггерного термина.
    • max_value: Максимальное значение для оповещений max_min и max.
    • min_value: Минимальное значение для оповещений max_min и min.
    • time_threshold: Интервал оповещения.
    • max_alerts: Максимальное количество срабатываний оповещения в течение интервала.
    • min_alerts: Минимальное количество раз, которое должно быть выполнено в течение интервала срабатывания предупреждения.

    • time_from: Время, с которого предупреждение будет активным.
    • time_to: Время, до которого тревога будет активна.
    • понедельник: Если установлено значение 1, оповещение активно по понедельникам.
    • вторник: Если установлено значение 1, оповещение будет активно по вторникам.
    • среда: Если установлено значение 1, оповещение будет активно по средам.
    • четверг: Если установлено значение 1, оповещение будет активно по четвергам.
    • пятница: Если установлено значение 1, оповещение будет активно по пятницам.
    • суббота: Если установлено значение 1, оповещение будет активно по субботам.

    • воскресенье: Если установлено значение 1, оповещение будет активно по воскресеньям.
    • recovery_notify: При установке значения 1 он включает восстановление предупреждений.
    • field2_recovery: Пользовательское поле 2 для восстановления предупреждений (свободный текст).
    • field3_recovery: Пользовательское поле 3 для восстановления предупреждений (свободный текст).
    • приоритет: Приоритет оповещения: 0 Техническое обслуживание, 1 Информационное, 2 Нормальное, 3 Предупреждение, 4 Критическое.
    • id_group: Идентификатор группы, к которой принадлежит шаблон (ref. tgrupo).
  • talert_template_modules: Экземпляр шаблона оповещения, связанного с модулем.

    • id: Уникальный идентификатор оповещения.
    • id_agent_module: Идентификатор модуля, связанного с предупреждением (ref. tagente_modulo).
    • id_alert_template: Идентификатор шаблона, связанного с предупреждением (ref. talert_templates).
    • internal_counter: Количество раз, когда был выполнен срок срабатывания предупреждения.
    • last_fired: Последний раз, когда срабатывало предупреждение (Unix time)
    • last_reference: Начало текущего интервала (Unix time).
    • times_fired: Количество срабатываний оповещения (оно может отличаться от internal_counter)

    • отключено: При установке значения 1 оповещение отключается.
    • приоритет: Приоритет оповещения : 0 Техническое обслуживание, 1 Информационное, 2 Нормальное, 3 Предупреждение, 4 Критическое.
    • force_execution: При установке значения 1 действие предупреждения будет выполнено, даже если оно не было вызвано. Он используется для ручного выполнения предупреждений.
  • talert_template_module_actions: Экземпляр действия, связанного с предупреждением (ref. talert_template_modules).
  • talert_compound: Составные оповещения, столбцы аналогичны столбцам talert_templates.
  • talert_compound_elements: Простые предупреждения, связанные с составным предупреждением. Каждое из которых имеет соответствующую логическую операцию (ref. talert_template_modules).
  • talert_compound_actions: Действия, связанные с составным предупреждением (ref. talert_compound).
  • таттачмент: Привязанности, связанные с заболеванием.
  • tconfig: Конфигурация консоли.
  • tconfig_os: Допустимые операционные системы в Pandora FMS.
  • tevento: Записи событий. Значения приоритета такие же, как и у оповещений.
  • tgrupo: Определенные группы в Pandora FMS.
  • tincidencia: Записи о заболеваемости.
  • tlanguage: Доступные языки в Pandora FMS.
  • tlink: Ссылки отображаются в нижней части консольного меню.
  • tnetwork_component: Сетевые компоненты. Это модули, связанные с сетевым профилем, используемым сервером Recon. После этого они приводят к записи в tagent_module, так что столбцы обеих таблиц похожи.
  • tnetwork_component_group: Группы для классификации сетевых компонентов.
  • tnetwork_profile: Сетевой профиль. Группа сетевых компонентов, которая будет назначена задачам распознавания Сервера Recon. Сетевые компоненты, связанные с профилем, приведут к появлению модулей в созданных агентах.
  • tnetwork_profile_component: Сетевые компоненты, связанные с сетевым профилем (rel. tnetwork_component/tnetwork_profile).
  • tnota: Примечания, связанные с заболеваемостью.
  • ториген: Возможный источник заболеваемости.
  • tperfil: Профили пользователей, определенные в консоли.
  • trecon_task: Задачи разведки, выполняемые Сервером Разведки.
  • tserver: Зарегистрированные серверы.
  • tsesion: Информация о действиях, выполненных во время сеанса пользователя для администрирования и статистических журналов.
  • ttype_module: Типы модулей в зависимости от их источника и типа данных.
  • ttrap: SNMP-ловушки, полученные консолью SNMP.
  • tuser: Консоль-зарегистрированные пользователи.
  • tuser_profile: Связанные с пользователем профили (rel. tuser/tprofile).
  • tnews: Новости показывали на консоли.
  • tgraph: Пользовательские графики, созданные в консоли.
  • tgraph_source: Модули, связанные с графом (rel. tgraph/tagente_modulo).
  • treport: Пользовательские отчеты, созданные в консоли.
  • treport_content: Элементы, связанные с определенным отчетом.
  • treport_content_sla_combined: Компоненты элемента SLA, связанного с определенным отчетом.
  • tlayout: Пользовательские карты, созданные в консоли.
  • tlayout_data: Элементы, связанные с картой.
  • tplugin: Определения плагинов для Сервера плагинов.
  • tmodule: Типы модулей (Network, Plugin, WMI…).
  • tserver_export_data: Данные для экспорта, связанные с пунктом назначения.
  • tplanned_downtime: Плановые простои.
  • tplanned_downtime_agents: Агенты, связанные с запланированным временем простоя (rel. tplanned_downtime/tagent).

1.1.3 Сжатие данных в реальном времени

Чтобы избежать перегрузки базы данных, сервер выполняет простое сжатие в момент вставки. Один фрагмент данных не будет храниться в базе данных. Если только он не будет отличаться от предыдущего или между ними не будет разницы во времени в 24 часа.

Например, для интервала около 1 часа последовательность 0,1,0,0,0,0,0,0,0,1,1,0,0 сохраняется в базе данных как 0,1,0,1,0. Последовательный 0 не будет сохранен, если не пройдет 24 часа.

График, показанный здесь, был составлен на основе данных предыдущего примера. В базу данных были вставлены только данные, выделенные красным цветом.

Сжатие данных 01.png

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

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

  • Поиск предыдущих данных, вне заданного интервала и даты. Если он существует, поместите его в начало диапазона. Если его нет, то нет и данных.
  • Ищите следующие данные вне диапазона и данные, заданные до максимума, равного интервалу модуля. Если он существует, то поставьте его в конце интервала. Если нет, продлите последнее доступное значение до конца интервала.
  • Все данные должны быть проверены, учитывая, что часть данных действительна до тех пор. Пока вы не получите другую часть данных.

1.1.4 Сжатие данных

Pandora FMS теперь включает в себя систему Эта система ориентирована на малые / средние развертывания (250-500 агентов,

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

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

В больших базах данных это может быть Вместо этого можно использовать модель базы данных истории.

1.1.5 База данных истории

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

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

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

Перейдите в меню НастройкаНастройкаИсторическая база данных и настройте там параметры для доступа к базе данных истории.

Bbddhist.png

Вот некоторые интересные настройки объяснены:

Дни
Максимальное количество дней, в течение которых информация хранится в основной базе данных. После этой даты данные будут перемещены в базу данных истории. 30 дней — это хороший вариант.
Оценить
Это работает как буфер. Скрипт обслуживания базы данных возьмет X регистров из базы данных. Добавит их в базу данных истории и удалит из основной базы данных. Это отнимает много времени, а размер зависит от настройки вашей консоли. 1000-хорошее значение по умолчанию.
Задержка
После блока из серии модулей скрипт будет ждать количество времени, указанное в delay(секундах). Это полезно, если производительность вашей базы данных низкая, чтобы избежать перегрузок. Используйте значения между 1-5.

1.1.5.1 Расширенная настройка

Конфигурация Pandora FMS по умолчанию не передает строковые данные в историческую базу данных. Однако. Если эта конфигурация была изменена и историческая база данных получает этот тип информации, необходимо настроить ее очистку, так как в противном случае это займет слишком много времени. Вызовет большие проблемы. А также негативно скажется на производительности.

Чтобы настроить этот параметр, необходимо выполнить запрос непосредственно в базе данных, чтобы установить дни. По истечении которых эта информация будет удалена. Ключевая таблица здесь естьtconfig, а поле есть string_purge. Если вы хотите установить 30 дней для очистки этого типа информации, этот запрос должен быть запущен непосредственно в исторической базе данных:

UPDATE tconfig SET value = 30 WHERE token = 

База данных поддерживается сценарием с именемpandora_db.pl:

Pandora FMS Enterprise 751 - параметры пути pandora db -.png

Хороший способ проверить, правильно ли выполняется обслуживание базы данных, — запустить сценарий вручную:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server.conf 

Он не должен сообщать об ошибке. Если другой экземпляр использует базу данных, вы можете использовать -f опцию. Которая вызывает выполнение; с -p параметром вы не сжимаете данные. Это особенно полезно в средах высокой доступности с историческими базами данных, так как сценарий гарантирует. Что необходимые шаги для этих компонентов выполняются в правильном порядке и режиме.

1.2 Статус модуля Pandora FMS

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

1.2.1 Когда устанавливается каждый статус?

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

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

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

1.2.2 Распространение и приоритет

В рамках организации Pandora FMS некоторые элементы зависят от других, как, например, модули агентов или модули групп. Это в равной степени относится и к корпоративным политикам Pandora FMS, с которыми связаны определенные агенты и модули. Которые считаются связанными с каждым агентом.

Эта структура особенно полезна для оценки состояния модуля с первого взгляда. Это достигается путем распространения статуса вверх по схеме организации, предоставляя этот статус агентам. Группам и политикам.

1.2.2.1 Какой статус имеет агент?

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

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

1.2.2.2 Что должно быть приоритетом статуса?

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

  1. Срабатывающие оповещения
  2. Критический статус
  3. Состояние предупреждения
  4. Неизвестный статус
  5. Нормальное состояние

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

С другой стороны, для того, чтобы одна группа была в нормальном состоянии. Все ее агенты должны иметь этот статус; это означает. Что все модули группы будут в нормальном состоянии.

1.2.3 Цветовой код

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

1.3 Графики Pandora FMS

Графики являются одной из самых сложных реализаций Pandora FMS. Поскольку они собирают информацию в режиме реального времени из БД. И никакая внешняя система не используется (rrdtool или аналогичная).

Существует несколько графических характеристик в зависимости от типа исходных данных:

  • Асинхронные модули. Предполагается, что нет никакого уплотнения данных. Данные, хранящиеся в БД, представляют собой все реальные образцы данных (следовательно, никакого уплотнения). Он создает более
  • Модули текстовых строк. Они показывают скорость собранных данных.
  • Числовые модули. Большинство модулей сообщают такие данные.
  • Булевы модули. Это числовые данные по модулям *PROC: например, проверка ping, состояние интерфейса и т. Д. 0 означает

1.3.1 Сжатие

Сжатие влияет на представление графики. Когда получены два фрагмента данных с одинаковым значением, Pandora FMS не сохраняет последний включенным. Если при представлении графика нет опорного значения, Pandora FMS будет искать до 48 часов назад во времени. Чтобы найти последнее известное значение. Которое можно взять в качестве опорного. Если он ничего не найдет, то начнет с 0.

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

1.3.2 Интерполяция

При построении графика Pandora FMS берет 50xN выборок (N-коэффициент разрешения графика. Который можно настроить в настройках. По умолчанию это 3). Например, монитор, возвращающий данные каждые 300 секунд (5 минут). Будет генерировать 12 выборок в час и 288 выборок (12*24) в день. Таким образом, дневной график не будет представлять 288 значений, а скорее будет

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

Graph-explain.png

В нормальных графикахинтерполяция реализуется простым способом: если в интервале есть две выборки (например. Интервал B примера). То среднее значение будет вычислено и представлено.

В булевых графах, если в выборке есть несколько данных (в данном случае только 1 или 0). Будет показано 0. Это помогает визуализировать сбои в пределах интервала. Давая ему приоритет над обычным состоянием.

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

1.3.3 Среднее значение/Макс./Мин

Grafica avg max min.png

Графики показывают среднее, максимальное и минимальное значения по умолчанию. Поскольку образец может содержать несколько данных, появятся средние, максимальные или минимальные значения данных. Чем больше требуется интерполяция (чем длиннее период отображения и чем больше данных у вас есть). Тем выше будет уровень интерполяции и. Следовательно. Разница между максимальным и минимальным значениями будет выше. Если диапазон графика невелик (час или около того), то интерполяции не будет или она будет минимальной. Поэтому вы увидите данные с их реальным разрешением. И три ряда будут идентичны.

Вернитесь к индексу документации