Като част от своята система за наблюдение на предприятието, организациите разчитат на сигнали и известия като първа линия на защита за постигане на висока наличност и съответно намаляване на разходите за прекъсване.
Сигналите и известията понякога се използват взаимозаменяемо, например можем да кажем „Получих системен сигнал за високо натоварване“ и замяната на „предупреждение“ с „известие“ няма да промени значението на съобщението. Въпреки това, в света на системите за управление е важно да се отбележи разликата:сигналите са събития, генерирани в резултат на системен проблем, а известията се използват за предоставяне на информация за състоянието на системата, включително проблеми. Като пример блогът Severalnines Introducing the ClusterControl Alerting Integrations обсъжда една от функциите за интеграция на ClusterControl, системата за уведомяване, която е в състояние да доставя сигнали чрез имейл, чат услуги и системи за управление на инциденти. Вижте също PostgreSQL Wiki — Сигнали и известия за състоянието.
За да наблюдава точно дейността на базата данни на PostgreSQL, системата за управление разчита на показателите за дейността на базата данни, персонализирани функции или съветници за наблюдение и регистрационни файлове за наблюдение.
В тази статия преглеждам инструментите, изброени в PostgreSQL Wiki, секциите Мониторинг и PostgreSQL GUI, като пропускам тези, които не се поддържат активно или не предоставят сигнали и известия нито в рамките на продукта, нито с безплатен пробен акаунт. Въпреки че не е изчерпателен преглед, всеки инструмент беше инсталиран и конфигуриран до точката, в която можех да разбера неговите възможности за предупреждение и уведомяване.
Нагиос
Nagios е популярна локална система за наблюдение с общо предназначение, която предлага широка гама от плъгини. Докато Nagios Core е с отворен код, препоръчителното решение за наблюдение на PostgreSQL е Nagios XI.
Настройките за уведомяване са за всеки потребител и за да ги промени, администраторът трябва да „влезе като“ потребителя — Nagios използва термина masquerade as . Веднъж на страницата за настройка на акаунта, потребителят може да избере да активира или деактивира методите за уведомяване:
Предпочитания за известяване на Nagios XI За да конфигурирате типовете известия, отидете на страницата „Методи за уведомяване“:
Методи за уведомяване на Nagios XI Вижте ръководството за потребителя на Nagios XI за повече подробности.
За да конфигурирате сигнали, влезте като администратор и изберете съветника за конфигуриране на базата данни:
Съветник за конфигуриране на база данни Nagios XI Веднъж конфигурирани, сигналите могат да бъдат прегледани, като изберете някой от изгледите по подразбиране, таблата за управление или можем да конфигурираме персонализиран такъв. Извън кутията Nagios XI предоставя следните PostgreSQL монитори:
Nagios XI PostgreSQL монитори Обърнете внимание, че първоначално Nagios XI не предоставя никакви показатели, базирани на PostgreSQL Statistics Collector, вместо това всеки показател трябва да бъде дефиниран с помощта на съветника за конфигурация „Postgres Query“:
Nagios XI Postgres Query Datadog
Datadog е инструмент за мониторинг на SaaS с общо предназначение, включващ много голям набор от интеграции с различни услуги. За да започнете наблюдение, изберете интеграцията с PostgreSQL и след това изберете интеграцията на известия като имейл, чат (напр. Slack) или системи за реакция на инциденти, като PagerDuty:
Интеграции с Datadog За да получаваме известия чрез каналите за интеграция, конфигурирани по-рано, трябва да създадем поне един монитор на Datadog, в случай на наблюдение на PostgreSQL, тип „интеграционен“ монитор:
Интеграция с PostgreSQL Datadog Първата стъпка в конфигурирането на монитора е изборът на тип предупреждение:
Метод за откриване на Datadog След това конфигурирайте един или повече показатели:
Конфигуриране на показатели за Datador Конфигурирайте условията за задействане на сигнала:
Datadog Alert Trigger Известията могат да бъдат персонализирани с помощта на шаблонни променливи:
Интегриране на Datadog Postgres Накрая предоставете списък с получатели, които да получават известия:
Получатели на известия от Datadog Събитията, които Datadog може да наблюдава, са изброени в секцията „Показатели“ за интеграция на PostgreSQL и се базират на предварително дефинирани изгледи на PostgreSQL Statistics Collector:
Показатели за интеграция на Datadog Postgres За да наблюдава събития, които не са предоставени с интеграцията по подразбиране, Datadog предоставя на клиентите възможност за създаване на персонализирани показатели, ограничени до плана на Datadog.
Окметър
Okmeter също е част от семейството за наблюдение на SaaS с общо предназначение и точно както други SaaS инструменти, изисква агент на наблюдавания хост. След като агентът е инсталиран, се активира набор от тригери за събития по подразбиране, включително проверка на връзката с PostgreSQL:
Автоматични задействания на Okmeter Получаването на повече PostgreSQL показатели изисква добавяне на PostgreSQL „сървър“:
Okmeter - Добавяне на сървър За да наблюдаваме статистиката на PostgreSQL, подобно на Nagios и Datadog, трябва да конфигурираме персонализирани показатели, както е обяснено в Документацията на Okmeter — Изпращане на персонализирани метрики. Или редактирайте показателя „PostgreSQL сървър“ по-горе, за да включите за изгледи във функцията „okmeter.pg_stats“.
Страницата с документация за статистически данни за заявките на Okmeter обяснява как да активирате проследяване на статистически данни за изпълнение на SQL изразите. Имайте предвид, че има няколко ограничения при използването на изгледите „pg_stat_statements“, напр. максимален брой отделни изрази, които могат да бъдат записани от модул — вижте документацията на PostgreSQL на pg_stat_statements за подробности.
Страницата с контакти за уведомяване е мястото, където известията се конфигурират за всеки потребител:
Известие за контакт с Okmeter Съобщенията за уведомяване могат да бъдат допълнително персонализирани с помощта на шаблони:
Шаблон за съобщение за известие на Okmeter Цирконус
Circonus, друг продукт за общ мониторинг на SaaS, разполага с „проверка“ на PostgreSQL, която може да бъде активирана поотделно или добавена като част от инсталацията в една стъпка:
Настройка за проверка на Circonus Според документацията на Circonus PostgreSQL проверката се извършва от отдалечено място чрез директни SQL оператори. След конфигуриране на хоста на PostgreSQL да приема връзки от брокер на Circonus, съветникът ще представи списък с налични показатели:
Проверка на Circonus PostgreSQL За да конфигурирате сигнали, всеки показател е свързан с набор от правила и списък с контакти, които трябва да бъдат уведомени.
Подробности за метриката на Circonus Сигналите са категоризирани въз основа на нивата на сериозност:
Circonus правила задава нива на сериозност Каналите за уведомяване включват SMS, OpsGenie, Slack, VictorOps и PagerDuty (без имейл). Екранната снимка по-долу показва интеграция със Slack:
Групи за контакт на Circonus За да конфигурирате известия, на всеки показател в проверката трябва да бъдат присвоени правила и контакти. Имайте предвид, че контактите трябва да бъдат създадени преди да редактирате показателя:
Набори от правила на Circonus Нова реликва
New Relic е друга обща система за наблюдение на SaaS. Когато става въпрос за PostgreSQL, има (към това писане) три налични плъгина. Най-новият е плъгинът Blue Medora:
Нов плъгин Relic PostgreSQL от Blue Medora След като приставката работи, тя става видима на страницата с плъгини и сме готови да конфигурираме сигнали:
Настройка на нови сигнали за реликви New Relic използва концепцията за политики за предупреждение за групиране на сигнали в инциденти. Преди да конфигурираме политика, трябва да настроим каналите за известия. Извън кутията New Relic се интегрира с всички популярни системи за реакция при инциденти, както и с имейл:
Нови типове канали с реликви Имайте предвид, че интеграцията трябва първо да бъде активирана в приложението за уведомяване. Например избиране на Slack от списъка с типове канали:
Нова интеграция на Relic Slack След това създайте „политика за предупреждение“:
Нова политика за предупреждение за реликви Политиката за предупреждение изисква „условие за предупреждение“. Следващият набор от екранни снимки показва стъпките за постигане на точно това:
Нова реликтна категория на състоянието на PostgreSQL 
Нов обект на реликт за PostgreSQL условие 
Нов праг на състоянието на Relic PostgreSQL Накрая изберете раздела канали за уведомяване, за да промените по подразбиране:
Нови Relic PostgreSQL канали за известяване По желание добавете условието за предупреждение към New Relic Insights (изисква допълнителен абонамент):
Нова информация за реликви Postgres Enterprise Manager
PEM или Postgres Enterprise Manager е инструмент за управление, настройка и наблюдение на PostgreSQL.
Той идва с много богат набор от предварително дефинирани показатели:
Предварително дефинирани показатели за Postgres Enterprise Manager За да промените сигналите по подразбиране или да създадете персонализирани такива, използвайте шаблоните за сигнали:
Шаблон за персонализиран сигнал за Postgres Enterprise Manager PEM разчита на имейл и SNMP за известия, така че може лесно да се интегрира със системи за наблюдение като Nagios, но няма никакви интеграции с популярните системи за управление на инциденти (PagerDuty, VictorOps, OpsGenie) или услуги за чат (Slack), открити в другите продукти.
Алармиране по имейл и SNMP на Postgres Enterprise Manager pgwatch2
pgwatch2 е друг инструмент за наблюдение, ориентиран към PostgreSQL, самостоятелно хоствано решение.
За да дефинираме сигнали, първо трябва да създадем персонализирано табло за управление и да дефинираме показателя:
Показатели на таблото за управление на pgwatch2 След това конфигурирайте предупреждението:
pgwatch2 Конфигуриране на сигнали на таблото за управление След като бъдат конфигурирани, сигналите ще се покажат на страницата със списък със сигнали:
Списък на таблото за управление pgwatch2 pgwatch2 се интегрира с всички популярни системи за уведомяване. Ето пример за добавяне на Slack канал:
pgwatch2 Slack интеграция За да видите каналите за уведомяване, конфигурирани в системата, отворете страницата „Канали за уведомяване“:
pgwatch2 канали за уведомяване Допълнителни показатели могат да бъдат добавени, както е документирано в раздела Функции на pgwatch2.
ClusterControl
ClusterControl е локална система за управление, ориентирана към база данни с поддръжка за PostgreSQL, MySQL, MariaDB и MongoDB.
Първата стъпка е добавяне на интеграция с известия. Повече информация за наличните интеграции е налична в Представяне на ClusterControl Alerting Integrations:
Интеграции на ClusterControl За целите на тази демонстрация конфигурирах Slack:
ClusterControl Slack интеграция ClusterControl също така предлага опцията за уведомяване по имейл:
Уведомления за ClusterControl по имейл След като известията са на място, създайте персонализирани съветници, за да задействате сигнали въз основа на конкретни критерии:
Персонализирани съветници на ClusterControl Изтеглете Бялата книга днес PostgreSQL Management &Automation с ClusterControl, за да разберете какво ви трябва управлявайте и мащабирайте PostgreSQLD Изтеглете Бялата книга Заключение
Статията нямаше за цел да навлезе дълбоко във функционалността на всеки инструмент, по-скоро се опитах да очертая това, което смятам за важни функции, свързани с предупрежденията и известията за PostgreSQL, по-специално.
Един от научените уроци е, че процесът на подбор трябва да вземе предвид няколко фактора:
- на място или SaaS
- базирана на агент или отдалечена проверка
- интеграция със системи за управление на инциденти и услуги за чат
- наличност на наблюдавани показатели, готови и плъгини
- възможност за добавяне на персонализирани показатели
- функции за управление на сигнали (напр. групиране)
- Сложност срещу детайлност в потребителския интерфейс
- допълнителна функционалност (управление, настройка, API и т.н.)
Освен това, ако едно решение не отговаря на всички бизнес и/или технически изисквания, винаги е възможно да се използва комбинация от услуги.
