PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Les meilleurs outils d'alerte et de notification pour PostgreSQL

Dans le cadre de leur système de surveillance d'entreprise, les organisations s'appuient sur les alertes et les notifications comme première ligne de défense pour atteindre une haute disponibilité et, par conséquent, réduire les coûts d'interruption.

Les alertes et les notifications sont parfois utilisées de manière interchangeable, par exemple, nous pouvons dire "J'ai reçu une alerte système à charge élevée", et remplacer "alerte" par "notification" ne changera pas la signification du message. Cependant, dans le monde des systèmes de gestion, il est important de noter la différence :les alertes sont des événements générés à la suite d'un problème système et les notifications sont utilisées pour fournir des informations sur l'état du système, y compris les problèmes. À titre d'exemple, le blog de Manynines Introducing the ClusterControl Alerting Integrations traite de l'une des fonctionnalités d'intégration de ClusterControl, le système de notification qui est capable de fournir des alertes par e-mail, des services de chat et des systèmes de gestion des incidents. Voir également PostgreSQL Wiki — Alertes et notifications d'état.

Afin de surveiller avec précision l'activité de la base de données PostgreSQL, un système de gestion s'appuie sur les métriques d'activité de la base de données, les fonctionnalités personnalisées ou les conseillers de surveillance et les fichiers journaux de surveillance.

Dans cet article, je passe en revue les outils répertoriés dans le Wiki PostgreSQL, les sections Monitoring et GUI PostgreSQL, en sautant ceux qui ne sont pas activement maintenus ou qui ne fournissent pas d'alertes et de notifications dans le produit ou avec un compte d'essai gratuit. Bien qu'il ne s'agisse pas d'un examen exhaustif, chaque outil a été installé et configuré jusqu'au point où j'ai pu comprendre ses capacités d'alerte et de notification.

Nagios

Nagios est un système de surveillance à usage général sur site populaire qui offre une large gamme de plugins. Alors que Nagios Core est open source, la solution recommandée pour surveiller PostgreSQL est Nagios XI.

Les paramètres de notification sont par utilisateur, et pour les modifier, l'administrateur doit "se connecter en tant que" l'utilisateur — Nagios utilise le terme masquerade as . Une fois sur la page de configuration du compte, l'utilisateur peut choisir d'activer ou de désactiver les méthodes de notification :

Préférences de notification Nagios XI

Afin de configurer les types de notifications, rendez-vous sur la page "Méthodes de notification" :

Méthodes de notification Nagios XI

Voir le Guide de l'utilisateur de Nagios XI pour plus de détails.

Pour configurer les alertes, connectez-vous en tant qu'administrateur et sélectionnez l'assistant de configuration de la base de données :

Assistant de configuration de la base de données Nagios XI

Une fois configurées, les alertes peuvent être visualisées en sélectionnant l'une des vues par défaut, les tableaux de bord, ou nous pouvons en configurer un personnalisé. Prêt à l'emploi, Nagios XI fournit les moniteurs PostgreSQL suivants :

Moniteurs Nagios XI PostgreSQL

Notez que par défaut Nagios XI ne fournit aucune métrique basée sur le PostgreSQL Statistics Collector, à la place chaque métrique doit être définie à l'aide de l'assistant de configuration « Postgres Query » :

Requête Nagios XI Postgres

Datadog

Datadog est un outil de surveillance SaaS à usage général proposant un très grand nombre d'intégrations avec une variété de services. Pour démarrer la surveillance, sélectionnez l'intégration PostgreSQL, puis choisissez les intégrations de notifications telles que les e-mails, le chat (par exemple, Slack) ou les systèmes de réponse aux incidents tels que PagerDuty :

Intégrations Datadog

Afin de recevoir des notifications via les canaux d'intégration configurés précédemment, nous devons créer au moins un moniteur Datadog, dans le cas du monitoring PostgreSQL un moniteur de type « intégration » :

Intégration Datadog PostgreSQL

La première étape de la configuration du moniteur consiste à sélectionner un type d'alerte :

Méthode de détection Datadog

Ensuite, configurez une ou plusieurs métriques :

Configuration des métriques Datador

Configurez les conditions de déclenchement de l'alerte :

Déclencheur d'alerte Datadog

Les notifications peuvent être personnalisées à l'aide de variables de modèle :

Intégration Datadog Postgres

Enfin fournissez une liste de destinataires pour recevoir les notifications :

Destinataires des notifications Datadog

Les événements que Datadog peut surveiller sont répertoriés dans la section "Métriques" de l'intégration PostgreSQL et sont basés sur les vues prédéfinies de PostgreSQL Statistics Collector :

Métriques d'intégration Datadog Postgres

Afin de surveiller les événements non fournis avec l'intégration par défaut, Datadog offre aux clients la possibilité de créer des métriques personnalisées limitées au plan Datadog.

Okmètre

Okmeter fait également partie de la famille de surveillance à usage général SaaS et, tout comme les autres outils SaaS, nécessite un agent sur l'hôte surveillé. Une fois l'agent installé, un ensemble de déclencheurs d'événements par défaut sont activés, y compris une vérification de connexion PostgreSQL :

Déclencheurs automatiques d'Okmeter

Pour obtenir plus de métriques PostgreSQL, il faut ajouter un "serveur" PostgreSQL :

Okmeter - Ajout d'un serveur

Afin de surveiller les statistiques PostgreSQL, de la même manière que Nagios et Datadog, nous devons configurer des métriques personnalisées comme expliqué dans la documentation Okmeter - Envoi de métriques personnalisées. Ou modifiez la métrique "Serveur PostgreSQL" ci-dessus pour l'inclure pour les vues dans la fonction "okmeter.pg_stats".

La page de documentation des statistiques de requête Okmeter explique comment activer le suivi des statistiques d'exécution pour les instructions SQL. Notez qu'il existe quelques limitations dans l'utilisation des vues "pg_stat_statements", par ex. nombre maximal d'instructions distinctes pouvant être enregistrées par un module — consultez la documentation PostgreSQL sur pg_stat_statements pour plus de détails.

La page des contacts de notification est l'endroit où les notifications sont configurées pour chaque utilisateur :

Notification de contact Okmeter

Les messages de notification peuvent être personnalisés davantage à l'aide de modèles :

Modèle de message de notification d'Okmeter

Circonus

Circonus, un autre produit de surveillance générale SaaS, propose une "vérification" PostgreSQL qui peut être activée individuellement ou ajoutée dans le cadre de l'installation en une étape :

Configuration de Circonus Check

Selon la documentation Circonus PostgreSQL, la vérification est effectuée à distance via des instructions SQL directes. Après avoir configuré l'hôte PostgreSQL pour accepter les connexions d'un courtier Circonus, l'assistant présentera une liste des métriques disponibles :

Vérification Circonus PostgreSQL

Afin de paramétrer les alertes, chaque métrique est associée à un ensemble de règles et une liste de contacts à notifier.

Détails de la métrique Circonus

Les alertes sont classées en fonction des niveaux de gravité :

Niveaux de gravité des ensembles de règles Circonus

Les canaux de notification incluent SMS, OpsGenie, Slack, VictorOps et PagerDuty (pas d'e-mail). La capture d'écran ci-dessous montre une intégration Slack :

Groupes de contact Circonus

Afin de configurer les notifications, chaque métrique de la vérification doit se voir attribuer des règles et des contacts. Notez que les contacts doivent être créés avant de modifier la métrique :

Ensembles de règles Circonus

Nouvelle relique

New Relic est un autre système de surveillance général SaaS. En ce qui concerne PostgreSQL, il existe (au moment de la rédaction de cet article) trois plugins disponibles. Le plus récent est le plugin Blue Medora :

Nouveau plugin Relic PostgreSQL de Blue Medora

Une fois que le plugin fonctionne, il devient visible sur la page des plugins et nous sommes prêts à configurer les alertes :

Configuration des alertes de nouvelle relique

New Relic utilise le concept de politiques d'alerte pour regrouper les alertes en incidents. Avant de configurer une politique, nous devons configurer les canaux de notification. Prêt à l'emploi, New Relic s'intègre à tous les systèmes de réponse aux incidents courants, ainsi qu'aux e-mails :

Nouveaux types de canal Relic

Notez que l'intégration doit d'abord être activée dans l'application de notification. Par exemple, en sélectionnant Slack dans la liste des types de chaînes :

Intégration de New Relic Slack

Créez ensuite une "politique d'alerte" :

Politique d'alerte de nouvelle relique

Une politique d'alerte nécessite une « condition d'alerte ». La prochaine série de captures d'écran montre les étapes pour y parvenir :

Nouvelle catégorie de condition Relic PostgreSQL Nouvelle entité de condition Relic PostgreSQL Nouveau seuil de condition Relic PostgreSQL

Sélectionnez enfin l'onglet canaux de notification afin de modifier la valeur par défaut :

Nouveaux canaux de notification Relic PostgreSQL

Ajoutez éventuellement la condition d'alerte à New Relic Insights (nécessite un abonnement supplémentaire) :

Nouvelles perspectives sur les reliques

Gestionnaire d'entreprise Postgres

PEM ou Postgres Enterprise Manager est un outil de gestion, de réglage et de surveillance de PostgreSQL.

Il est livré avec un ensemble très riche de métriques prédéfinies :

Metriques prédéfinies Postgres Enterprise Manager

Pour modifier les alertes par défaut ou en créer des personnalisées, utilisez les modèles d'alerte :

Modèle d'alerte personnalisé Postgres Enterprise Manager

PEM s'appuie sur le courrier électronique et SNMP pour les notifications, il peut donc facilement s'intégrer aux systèmes de surveillance tels que Nagios, mais il n'y a pas d'intégration avec les systèmes de gestion des incidents populaires (PagerDuty, VictorOps, OpsGenie) ou les services de chat (Slack) trouvés dans les autres produits.

Postgres Enterprise Manager Alerte par e-mail et SNMP

pgwatch2

pgwatch2 est un autre outil de surveillance centré sur PostgreSQL, une solution auto-hébergée.

Afin de définir des alertes, nous devons d'abord créer un tableau de bord personnalisé et définir la métrique :

pgwatch2 Métriques du tableau de bord

Configurez ensuite l'alerte :

Configuration des alertes du tableau de bord pgwatch2

Une fois configurées, les alertes s'afficheront sur la page Liste des alertes :

pgwatch2 Liste d'alertes du tableau de bord

pgwatch2 s'intègre à tous les systèmes de notification populaires. Voici un exemple d'ajout d'un canal Slack :

pgwatch2 Intégration Slack

Pour afficher les canaux de notification configurés dans le système, ouvrez la page "Canaux de notification" :

pgwatch2 Canaux de notification

Des métriques supplémentaires peuvent être ajoutées comme documenté dans la section Fonctionnalités de pgwatch2.

ClusterControl

ClusterControl est un système de gestion de base de données sur site prenant en charge PostgreSQL, MySQL, MariaDB et MongoDB.

La première étape consiste à ajouter une intégration de notification. Plus d'informations sur les intégrations disponibles sont disponibles sur Présentation des intégrations d'alerte ClusterControl :

Intégrations ClusterControl

Pour les besoins de cette démo, j'ai configuré Slack :

Intégration de ClusterControl Slack

ClusterControl offre également la possibilité de notifier par e-mail :

Notifications de contrôle de cluster par e-mail

Une fois les notifications en place, créez des conseillers personnalisés afin de déclencher des alertes en fonction de critères précis :

ClusterControl Custom AdvisorsTélécharger le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

Conclusion

L'article n'était pas destiné à approfondir les fonctionnalités de chaque outil, j'ai plutôt tenté de décrire ce que je considérais comme les fonctionnalités importantes liées aux alertes et aux notifications pour PostgreSQL, en particulier.

L'une des leçons apprises est que le processus de sélection doit tenir compte de plusieurs facteurs :

  • sur site ou SaaS
  • vérification basée sur un agent ou à distance
  • intégration avec les systèmes de gestion des incidents et les services de chat
  • disponibilité des métriques surveillées, prêtes à l'emploi et des plug-ins
  • possibilité d'ajouter des statistiques personnalisées
  • fonctionnalités de gestion des alertes (par exemple, regroupement)
  • complexité vs granularité dans l'interface utilisateur
  • fonctionnalités supplémentaires (gestion, réglage, API, etc.)

De plus, si une solution ne répond pas à toutes les exigences commerciales et/ou techniques, il est toujours possible d'utiliser une combinaison de services.