Envoi d’alertes de cluster Redis à Slack avec Syslog

Envoi d’alertes de cluster Redis à Slack avec Syslog

Lors de l’exécution en production, un système enregistre de nombreux événements et alertes, aidant les administrateurs à surveiller ce qui se passe dans un système et à être avertis automatiquement lorsqu’ils doivent répondre à un problème. Par exemple:

  • Lorsqu’une nouvelle base de données est créée, un événement est consigné avec l’horodatage, l’utilisateur et le nom de la nouvelle base de données. Cela permet à l’administrateur de vérifier la configuration et de contacter l’utilisateur s’il a des questions.
  • Lorsqu’un seuil, tel qu’un pourcentage spécifique de consommation de mémoire, est atteint, une alerte est consignée, invitant l’administrateur à vérifier l’état du cluster Redis Enterprise.

Cet article expliquera comment Redis Enterprise utilise le service syslog pour consigner les événements et les alertes, et expliquera comment :

  • Configurer le journal système
  • Envoyer des événements de cluster à un serveur de journalisation centralisé
  • Envoyer des messages d’alerte de défaillance de nœud à Slack

Pour mettre cela en contexte, Redis Enterprise gère de nombreux journaux, conservés par défaut dans le /var/opt/redis/log répertoire, mais nous allons nous concentrer sur l’utilisation de syslog comme indiqué dans le Documentation Redis. J’espère qu’au moment où vous aurez fini de lire, vous saurez comment :

  • Configurez le système syslog pour enregistrer les événements et les alertes Redis dans un /var/log/redis.log dossier
  • Envoyez des événements et des alertes à un serveur distant syslog comme indiqué dans ce diagramme :
tug clusters blog image 2

Avant de commencer, vous devez disposer d’un Logiciel d’entreprise Redis cluster opérationnel ainsi qu’une instance Linux pour exécuter le serveur syslog. (Notez que pour ce post, j’ai utilisé un cluster à 3 nœuds de Redis Enterprise 5.4.14-28, fonctionnant sur CentOS 7.x., et une autre instance Linux pour exécuter le serveur syslog.)

Comprendre la configuration

Sur tous les nœuds, vous verrez un /var/opt/redis/log répertoire dans lequel Redis Enterprise écrit tous les journaux. Concentrons-nous sur le journal des événements. Ce fichier est géré par le service de gestionnaire d’alertes Redis Enterprise, qui génère des entrées en fonction de la configuration des alertes de cluster et de base de données, et consigne diverses actions administratives, telles que la création, la configuration et la suppression de la base de données.

Si vous ouvrez `/var/opt/redis/log/event_log.log` fichier, vous verrez des entrées qui ressemblent à ceci :

2020-04-06 15:30:46,425 INFO event_log EventLog: {"originator_username":"Administrator","object":"bdb:7","extra":{"bdb_uid":"7","bdb_name":"db-002"},"object_type":"bdb","originator_email":"admin@demo.com","originator_uid":1,"time":1586187046,"throttled_event_count":1,"obj_uid":"7","type":"creation_request"}
2020-04-06 15:30:47,896 INFO event_log EventLog: {"originator_username":"system","object":"cluster","extra":{"bdb_uid":"7","bdb_name":"db-002"},"object_type":"cluster","originator_uid":0,"time":1586187047,"throttled_event_count":1,"obj_uid":null,"type":"bdb_created"}

2020-04-06 15:32:20,073 CRITICAL event_log EventLog: {"originator_username":"system","object":"node:2","object_type":"node","state":true,"originator_uid":0,"time":1586187140,"throttled_event_count":1,"obj_uid":"2","type":"failed"}

Les entrées de journal ont la structure de base suivante :
horodatage gravité event_log EventLog :{}

  • Horodatage
  • Gravité de l’événement : INFO, AVERTISSEMENT, ERREUR, CRITIQUE
  • event_log Textes statiques bruts EventLog
  • {liste de paires clé-valeur dans n’importe quel ordre} une liste de paires clé-valeur décrivant l’événement spécifique. Les paires clé-valeur peuvent apparaître dans n’importe quel ordre. Certaines paires clé-valeur sont toujours affichées, et certaines apparaissent en fonction de l’événement spécifique. Vous pouvez trouver plus d’informations sur le contenu du message dans le Documentation Redis Entreprise.

Ces événements sont gérés au niveau du cluster, de sorte que seul le nœud maître du cluster écrit des événements dans le journal des événements fichier à un moment précis. Lançons le `rladmin` commande sur le cluster :

image1 8

Comme vous pouvez le voir, le nœud : 1 est le maître du cluster. Cela signifie que le journal des événements y seront peuplés. Si le maître se déplace vers un autre nœud, les événements seront enregistrés sur le nouveau maître.

Ces journaux sont gérés par l’infrastructure de journalisation du cluster Redis. Cependant, Redis Enterprise utilise également syslog. Vous trouverez les mêmes entrées de journal dans le /var/log/messages dossier:

Apr 8 05:32:20 ip-100-00-00-000 event_log[2015]: {"originator_username":"system","object":"node:2","object_type":"node","state":true,"originator_uid":0,"time":1586187140,"throttled_event_count":1,"obj_uid":"2","type":"failed"}

Notez que la même entrée est présente avec le nom de l’hôte et du processus en préfixe :

(ip-100-00-00-000 event_log[2015])

Comprendre la configuration de Redis Enterprise et de rsyslog

Regardons maintenant la configuration de Redis Enterprise pour voir comment et pourquoi les logs sont utilisés par rsyslog. La journalisation Redis Enterprise est configurée dans le /opt/redis/config/logging.conf dossier:

{
    "version": 1,
    "disable_existing_loggers": false,
    "formatters": {
        "standard": {
            "format": "%(asctime)s %(levelname)s %(name)s %(threadName)s: %(message)s"
        },
        "syslog": {
            "format": "%(name)s[%(process)d]: %(message)s"
        }
    },

    "handlers": {
        "console": {
            "class": "logging.StreamHandler",
            "formatter": "standard",
            "stream": "ext://sys.stdout"
        },
        "syslog": {
            "class": "logging.handlers.SysLogHandler",
            "formatter": "syslog",
            "facility": "daemon",
            "address": "/dev/log"
        }
    },

    "loggers": {
        "": {
            "level": "INFO"
        },
        "event_log": {
            "level": "INFO",
            "handlers": ["syslog"],
            "propagate": false
        }
    }
}

Ce fichier contient deux sections intéressantes pour ce post :

loggers.event_log définit quel(s) gestionnaire(s) sont utilisés pour consigner les événements

gestionnaires.syslog définit le gestionnaire. La configuration par défaut utilise le “démon” “installation”.

Gardez à l’esprit que si vous modifiez le /opt/redis/config/logging.conf il sera remplacé lors de la mise à jour de Redis Enterprise. Dans les sections suivantes, j’expliquerai comment contrôler la journalisation à l’aide de syslog sans toucher aux configurations Redis Enterprise. Si vous modifiez la configuration de la journalisation, vous devez exécuter la commande suivante pour l’activer :

$ supervisorctl restart alert_mgr

Qu’est-ce qu’une installation syslog ?

La fonction Syslog est une entrée de configuration située dans /etc/rsyslog.conf qui définit où un message syslog sera écrit, en fonction de l’origine du message. Vous pouvez trouver plus d’informations sur les installations dans le Page Wikipédia de Syslogy compris la liste des installations disponibles.

Comme indiqué ci-dessus, par défaut, Redis Enterprise utilise le démon installation utilisée pour enregistrer les démons système. Syslog définit également les facilités local0 à local7 pour permettre aux administrateurs de configurer une stratégie de journalisation personnalisée.

Configuration de Syslog

Nous sommes maintenant prêts à configurer syslog. Commençons par créer un nouveau fichier de configuration contenant toutes les informations spécifiques à la journalisation des événements Redis.

Créez le fichier comme indiqué ici :

/etc/rsyslog.d/redis.conf

Et ajoutez la configuration suivante :

template(name="RedisEventTemplate" type="string" string="%syslogseverity-text%:%pri-text%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf% -- %syslogtag%  -- %programname% \n")

if $programname startswith 'event_log' then {
  action(type="omfile" file="/var/log/redis.log" template="RedisEventTemplate" )
}

Avec cette configuration, le service syslog va :

  • Charger un nouveau modèle nommé RedisEventTemplateRedisEventTemplate qui enregistre le message avec la priorité (syslogseverity-text) ce sera Info, critique, Attention
  • Utilisez ce modèle pour écrire dans le fichier /var/log/redis.log lorsque le programme est ‘journal des événements’(le gestionnaire de journaux Redis Enterprise)

Vous pouvez en savoir plus sur la syntaxe du modèle dans le documentation syslog.

Enfin, redémarrez syslog :

systemctl restart rsyslog

Test de la nouvelle configuration

Accédez à la console Web Redis Enterprise et créez une nouvelle base de données (ou modifiez une base de données existante). Vous devriez voir un nouveau /var/log/redis.log fichier et l’événement que vous avez généré. Voici un exemple de ce à quoi pourrait ressembler une entrée de journal :

info:local5.info 17:48:47:ip-00-00-00-00:event_log[14176] ::{"originator_username":"Administrator","object":"bdb:18","extra":{"old_val":"dd2","new_val":"db01","attr":"name"},"object_type":"bdb","originator_email":"admin@demo.com","originator_uid":1,"time":1586281727,"throttled_event_count":1,"obj_uid":"18","type":"updated"}

Dans cet exemple, la première partie de l’entrée de journal (info) est la gravité, que vous pouvez utiliser ultérieurement pour capturer des événements spécifiques.

Configuration du cluster complet

Comme mentionné précédemment, vous configurez Redis Enterprise et syslog sur un seul nœud (le nœud maître), vous devez donc répéter ces étapes sur chaque nœud du cluster.

Le cluster Redis Enterprise est désormais configuré pour utiliser une configuration syslog personnalisée pour capturer les événements et les alertes ; il est maintenant possible d’utiliser les capacités de syslog.

Envoi de tous les nœuds d’un cluster vers un emplacement unique

Un cas d’utilisation courant de Syslog consiste à regrouper tous vos journaux dans un emplacement unique pour le traitement. Syslog fournit une capacité de serveur pour ce faire, il vous suffit d’ajouter une nouvelle action dans la configuration de syslog pour envoyer les messages sur le réseau.

Pour envoyer tous les messages à un serveur de journalisation centralisé, ajoutons une nouvelle action dans le /etc/rsyslog.d/redis.conf dossier:

template(name="RedisEventTemplate" type="string" string="%syslogseverity-text%:%pri-text%:%programname%:%timegenerated%:%HOSTNAME%:%syslogtag%:%msg:::drop-last-lf% \n")

if $programname startswith 'event_log' then {
  action(type="omfile" file="/var/log/redis.log" template="RedisEventTemplate" )
  action(type="omfwd" protocol="tcp" target="10.0.0.12" port="514" template="RedisEventTemplate" )
}

Redémarrez le service syslog :

$ systemctl restart rsyslog

Si vous générez un événement à partir de Redis Enterprise, par exemple en modifiant une base de données, vous devriez voir un nouvel événement dans le /var/log/messages fichier dans le serveur syslog vers lequel vous pointez.

Envoi d’alertes de défaillance de nœud à Slack

Tous les événements du cluster Redis sont envoyés à un serveur syslog centralisé, écrivant ces événements dans le /var/log/messages dossier.

Vous pouvez maintenant utiliser ce serveur pour analyser et intégrer ces messages avec tout autre outil tel que Splunk, Syslog Watcher ou Datadog. Par exemple, un flux agréable et facile serait d’analyser les messages du fichier journal et d’envoyer un message à Slack lorsqu’un modèle spécifique est rencontré. Voici comment procéder :

Créer des webhooks Slack entrants

  1. Aller à https://apps.slack.com
  2. Créer ou activer un compte développeur
  3. Rechercher “webhooks entrants”
  4. Créer un nouveau crochet

Le webhook entrant Slack est un simple point de terminaison REST que vous pouvez utiliser pour publier des messages sur Slack.

Écrire l’analyseur de messages Python

Maintenant que le webhook Slack est en place, utilisons un simple script Python pour suivre ce fichier et vérifions si la nouvelle ligne provient de Redis journal des événements et contient la chaîne manqué. Lorsque c’est le cas, le script envoie le message à Slack à l’aide d’un simple webhook.

La redis-alert.py scénario ressemble à ça:

import time
import json
import requests
import re
import sys

# Read log
def tail(f):
    f.seek(0, 2)
    while True:
        line = f.readline()
        if not line:
            time.sleep(0.1)
            continue
        yield line

# Parse line and send message if match
def analyze_message(line, text):
    if re.search(r"\bevent_log\b", line) and  re.search(r"\b"+ text + r"\b", line):
        webhook_url="https://hooks.slack.com/services/YOUR_HOOK/URL/SLACK"
        slack_data = {'text': '"' + line + '"'}
        response = requests.post(
            webhook_url, data=json.dumps(slack_data),
            headers={'Content-Type': 'application/json'})

# Run the application
while True:
    print(sys.argv[1])
    auditlog = tail( open (sys.argv[1]) )
    for line in auditlog:
        analyze_message(line, sys.argv[2])

Voici le script sur le serveur syslog qui agrège tous les événements Redis :

$ python redis-alert.py /var/log/messages failed

Pour voir comment cela fonctionne, générez une panne de nœud, par exemple en forçant le redémarrage d’un des nœuds. Vous devriez voir une notification dans votre chaîne Slack :

image3 4

Ce script Python est très simple, il envoie le message exactement tel qu’il est reçu.

Syslog est un outil puissant pour capturer, organiser, filtrer et déplacer les entrées de journal à divers endroits. Dans cet article, nous avons configuré Redis Enterprise et syslog pour capturer les événements et les alertes du cluster dans un format personnalisé et avons envoyé ces entrées à un serveur syslog central. Si vous voulez en savoir plus sur l’utilisation de syslog, rendez-vous sur le site officiel Documentation RSylog.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *