Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Monitoring

De l'alerting à base de logs

Rédigé par dada / 12 février 2020 / 2 commentaires


Cela fait un moment que je cherche un moyen de déclencher des alertes à partir d'erreurs spécifiques dans les logs. En fait, ça fait depuis la sortie de Loki que j'en rêve.



Pour rappel, le couple Loki/Promtail, permet de centraliser des logs dans Grafana pour les visualiser calmement plus tard. En gros, ça peut donner un truc comme ça, ou comme ça.
Après avoir mis tout ça en place, je trouvais dommage de ne pas pouvoir continuer l'intégration jusqu'au bout : repérer un message d'erreur dans des logs et transformer l'écran de monitoring en sapin de Noël.

En fait, c'était déjà possible, j'avais juste raté l'information !

Préambule

Ce dont je vais parler dans la suite du billet nécessite d'avoir déjà la stack Loki + Promtail + Grafana + Prometheus + Alert-manager. Ça demande un peu d'huile de coude et de temps mais ça s'installe très bien.

Les Pipelines

Promtail, comme tout exporter, expose des metrics de toute sorte. De base, il fait des choses simples, mais avec les Pipelines, on peut pousser le truc plus loin : ajouter le timestanp à une ligne de log, modifier des labels, ajouter clairement le numéro de ligne du log et, on y est, créer une metric custom !

Créer une metric custom

On va commencer par un exemple très simple :
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
Ceci est une partie de la configuration du Promtail en place sur mon serveur Mastodon. Ce n'est pas la plus propre du monde mais ça fera l'affaire.

Le job

On y voit la configuration qui permet de remonter les logs système de /var/log/*.log avec le label varlogs et un hostname forcé :
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr

Le pipeline

On enchaîne ensuite avec le fameux pipeline, que je vais présenter en deux parties : le selector et les metrics 

- La partie selector
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
Le selector permet de s'y retrouver. On va aller chercher à bidouiller les logs du job varlogs, pas ailleurs. Le stage permet de mettre en place une expression régulière en RE2, la version Google est regexp, pour filtrer l'information dont on a besoin.
Ici, je veux qu'une action soit déclenchée à chaque fois que error_message apparaît dans les logs. Celles et ceux qui ont une instance Mastodon savent de quoi je parle. Pour les autres, c'est quand un message ne peut pas atteindre son destinataire. C'est très courant.

- La partie metrics

Pour finir, la partie metrics est carrément celle qui nous intéresse le plus : elle va, comme son nom l'indique, créer une metric qui sera remontée à Prometheus.
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
On va lire la configuration lentement : La variable error_total sera de type Counter avec la description "total count of errors" et sera alimentée par error_message, défini dans la regexp précédente (entre les <>). De 0, la variable sera incrémentée de 1 à chaque match.

Prometheus

Vérifier la configuration

Vous voyez le truc ? On vient de mettre en place une metric custom qui sera remontée par Promtail vers Prometheus. À l'heure où j'écris ces lignes, cette metric ressemble à ça :
root@diaspodon ~ # curl -s http://localhost:9080/metrics   | grep custom
# HELP promtail_custom_error_total total count of errors
# TYPE promtail_custom_error_total counter
promtail_custom_error_total{filename="/var/log/daemon.log",hostname="diaspodon.fr",job="varlogs"} 92831
promtail_custom_error_total{filename="/var/log/syslog",hostname="diaspodon.fr",job="varlogs"} 50050
On retrouve bien la metric déclarée dans Promtail : error_total, avec son nom complet : promtail_custom_error_total.

Vous me direz que ce n'est pas très joli et vous aurez parfaitement raison. C'est un exemple, juste un exemple !

Mettre en place de l'alerting

Maintenant que vous avez des données dans Prometheus, rédiger une règle d'alerting est assez simple. On devrait s'en sortir avec ce type de chose :
  - alert: Error_total
    expr: promtail_custom_error_total > 1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} is invaded by custom errors!"
Simple, rapide, efficace. Si une erreur apparaît, elle sera repérée et une alerte sera déclenchée. Y'a plus qu'à faut qu'on vérifier que votre installation spamme correctement les développeurs pour les mettre sur le coup rapidement.

Pour aller plus loin

Je viens de rapidement parcourir le sujet pour vous donner envie d'y mettre le nez. En l'état, la configuration proposée a un gros problème : une fois qu'une erreur est détectée, le Counter sera incrémenté et rien ne lui permettre de revenir à 0. C'est assez chiant.

J'ai deux façons de contourner le problème : la première avec les développeurs, la deuxième avec ses seuls moyens.

Si les développeurs sont adorables, ils peuvent mettre en place un petit bout de code qui va écrire dans les logs que tout est revenu à la normale. En passant du Counter à une Gauge, on peut dire à Promtail d'incrémenter la metric quand un souci est détecté puis de la décrémenter quand tout redevient fonctionnel. Ça permet de jongler entre 0 et 1 et pas plus.

Par contre, si vous êtes tout seul, vous pouvez tricher en décidant de mettre en place une règle d'alerting qui fait un rate() sur 1h, ou la durée que vous voulez, pour avoir des passages à vide et des périodes de souci. Ça permet d'éviter de passer d'un Counter à une Gauge mais ça demande à mettre un délai de retour au calme long et d'être assidu sur les chan/salon/mail d'alerting.

Bref, c'est encore un point sur lequel je réfléchis. Si vous avez des idées, je prends.

Enfin voilà.

Des bisous

L'alerting avec Prometheus

Rédigé par dada / 02 août 2018 / 4 commentaires


Depuis le temps que je devais l'écrire, ce billet, le voici : comment mettre en place un système d'alerting avec Prometheus !

Pour celles et ceux qui ne sont pas familiers avec ce vocabulaire : l'alerting est une notion d'administrateur système qui consiste à prévenir les équipes en charge du bon fonctionnement d'un service qu'il est en train de se casser la figure. Ou qu'il s'est déjà vautré.

En avant-propos, je vous invite à aller faire un tour du côté de mes différents billets sur Prometheus.

L'alerting, c'est une brique en plus

Prometheus est une bête idiote, les exporters sont des bêtes idiotes, Grafana est une bête idiote, l'alerting est lui aussi une bête idiote. Pour le faire fonctionner, à la manière d'un exporter, il vous faut installer l'Alertmanager.

L'installation de l'Alertmanager est identique à celle des autres exporter : téléchargez le binaire ou le conteneur Docker, lancez tout ça en lui passant en paramètre son fichier de configuration.

Toujours comme un simple exporter, ou presque, faites comprendre à Prometheus qu'il est là en ajoutant ces quelques lignes dans prometheus.yml, en dessous de la configuration globale :
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - localhost:9093
    scheme: http
    timeout: 10s

N'oubliez pas de reload la configuration de Prometheus :

curl -X POST http://localhost:9090/-/reload

Configurer la détection des problèmes

Les alertes se présentent sous forme de fichiers que vous allez placer dans le répertoire rules/ de Prometheus :
root@server /etc/prometheus/rules # ls
memory  up
Il va ensuite falloir les déclarer dans Prometheus :
# Load and evaluate rules in this file every 'evaluation_interval' seconds.
rule_files:
  - '/etc/prometheus/rules/up'
  - '/etc/prometheus/rules/memory'
Pour faire simple et rapide, voici des exemples d'alertes qui pourraient vous servir :

- Service disponible
ALERT InstanceDown
  IF up == 0
  FOR 1m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{$labels.instance}} is down",
    description = "{{$labels.instance}} of job {{$labels.job}} has been down for more than 1 minutes"
  }
- L'utilisation de la RAM
ALERT MemoryUsage
  IF ((node_memory_MemTotal-node_memory_MemFree-node_memory_Cached)/(node_memory_MemTotal)*100) > 95
  FOR 10m
  LABELS { severity = "warning" }
  ANNOTATIONS {
    summary = "Instance {{$labels.instance}} is in danger",
    description = "RAM of {{$labels.instance}} has been too used for more than 10 minutes"
  }
Avant de vous lancez dans le copier/coller du code exposé ci-dessus, prenez le temps de lire les quelques lignes suivantes :

- ALERT : il s'agit d'un nom arbitraire que vous donnez à votre alerte
- IF : c'est la condition qu'il faut respecter pour déclencher l'alerte
- FOR : la durée pendant laquelle le IF doit être valide
- LABEL : ça permet de donner un poids à votre alerte (osef, warning, critical, etc)
- ANNOTATIONS : ce que vous voulez afficher quand l'alerte est déclenchée

Normalement, à ce niveau là, vous avez un Alertemanager capable de détecter si vous avez des soucis de RAM ou si vos serveurs/services sont fonctionnels ou HS. C'est bien beau, mais ça ne vous réveillera pas en cas de pépin.

Un rapide tour sur l'interface web de Prometheus devrait vous le confirmer. En exemple, voici la liste des alertes que j'utilise :

Configurer l'envoi d'emails d'alerte

Le fichier de configuration que vous passerez en paramètre au lancement de l'Alertmanager doit lui dire que faire quand une alerte est détectée. Il est possible de lui dire de vous envoyez un message sur Telegram, Mattermost, ou, simplement, de vous envoyer un mail. C'est la solution la plus simple, alors allons-y.

Les possibilités étant énormes, je ne vais vous proposer qu'un exemple de configuration simple :
global:
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@mon.email'

route:
  receiver: 'team-mails'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

receivers:
- name: 'team-mails'
  email_configs:
  - to: 'ladestination@email.mail'
Avec cette configuration, vous allez recevoir un mail en cas de souci. Sans intervention de votre part, le mail sera renvoyé au bout de 3h.

Cette conf est très simple. Je n'explique pas tout. Juste, elle marche. Si vous souhaitez en savoir plus, comme l'organisation de groupes qui recevront des alertes spécifiques ou la gestion des "warning" ou des "critical", je vous encourage à prendre un peu de temps pour lire l'exemple assez complet qu'on peut trouver par ici.

Et voilà ! Je suis loin d'avoir fait le tour des possibilités de Prometheus mais les différents billets que vous trouverez sur ce blog devraient vous permettre de mettre les doigts dedans et de vous en sortir.

Des bisous !

Un Exporter Prometheus pour Mastodon

Rédigé par dada / 27 juillet 2018 / Aucun commentaire


English ? Run to my Gitlab. Comments are in english.


Mon dernier billet ne laissait pas trop de doute sur mes activités du moment : du python, Prometheus et l'API de Mastodon sont bien les signes avant-coureurs de l'arrivée d'un Exporter ! Dans cette liste, j'ai pris le temps d'ajouter un peu de Grafana et du Docker, histoire de bien faire les choses, avant de vous ouvrir l'accès à mon dépôt Git.

Le poids des mots, le choc des photos

Pour reprendre le slogan de Paris-Match, voici une capture d'écran de la bête dans Grafana :

Ce que vous voyez ci-dessus est un exemple de dashboard Grafana. Un exemple. Vous pouvez faire bien mieux, j'en suis certain, et le partager.

Ce que l'Exporter permet de récupérer

  • Les comptes actifs
  • Le nombre d'instances connues
  • Le nombre total de comptes sur l'instance
  • Le nombre total de toots
  • Le nombre d'inscriptions pour la semaine courante
  • Le nombre de toots par semaine
Alors, oui, ce n'est pas grand chose, mais ça nous permet de récupérer des statistiques publiques et d'en faire des beaux graphiques avec la stack la plus chouette du moment ! J'ai enfin viré Munin :-)

Utilisation sans Docker

Clonez les sources où bon vous semble :
git clone http://git.dadall.info/prometheus/mastodon.git
Installez les dépendances :
pip3 install -r requirements.txt
Lancez la bête en ayant bien défini l'URL de votre instance dans les sources :
python3 instance_exporter.py

Utilisation avec Docker

Il va vous falloir créer l'image Docker :
docker build -t mastodon-exporter .
Et vous pourrez lancer un conteneur en ajoutant l'URL de votre instance en paramètre :
docker run -d -e MASTODON_HOST="https://instance.url/" -p 9410:9410 mastodon-exporter
Vous trouverez un exemple de dashbord pour Grafana, histoire de tout mettre en couleur, dans le dépôt.

Vous pouvez maintenant suivre l'activité de votre instance : foncez mettre ça en place avant le prochain afflux d'utilisateurs pour voir les courbes réagir : les données qui transitent sur Mastodon sont tellement nombreuses qu'il faut vraiment qu'il y ait une vague de nouveaux pour faire visiblement bouger les lignes !

Voilà

Si vous avez des retours, n'hésitez pas à passer par les commentaires ou Mastodon, à lâcher des pouces bleus et partager la vidéo.

Des bisous,

Comment prendre un peu de Python pour faire un Exporter Prometheus

Rédigé par dada / 20 juillet 2018 / 4 commentaires



Faire un Exporter Prometheus, c'était un défi qui traînait dans ma longue-liste-des-choses-à-faire depuis longtemps. J'ai enfin mis les mains dedans. C'est moins terrifiant qu'on le croit, à condition de vouloir faire des choses simples. Voici donc quelques lignes pour vous expliquer comment s'en sortir.

Du Python 3

Il est possible de faire des Exporters dans un nombre dingue de langages. Pour des questions de curiosité et d'envie, j'ai choisi de le faire en Python, version 3. En plus, Prometheus fournit une bibliothèque qui va bien.

Une API

Un Exporter est capable d'interroger, entre autre, des API. Pour l'exemple et parce ce que j'avais envie de mieux connaître mon instance Mastodon, c'est l'API de l'alternative à Twitter que vous allez croiser ci-dessous.

La logique globale

Un Exporter, pour faire très simple, c'est un bout de code coincé dans une boucle infinie.
Oui, très simple.
Il va récupérer de l'information et la transmettre à Prometheus, puis récupérer de l'information et la transmettre à Prometheus, puis récupérer de l'information...

Exemple

Ici, on va pondre un bout de code qui va aller récupérer le nombre de comptes que je follow sur Mastodon :
r = requests.get("https://diaspodon.fr/api/v1/accounts/1")
data = json.loads(r.content.decode())
metric = Metric('following_count', 'Number of following account', 'gauge')
metric.add_sample('following_count', value=data["following_count"], labels={})
yield metric
Ce qu'il faut comprendre :
- La variable r contient le retour de l'appel à l'API Mastodon.
- La variable data contient en utilisable le JSON contenu dans r.
- La variable metric contient les données exploitables par Prometheus.

C'est la ligne qui est vraiment cruciale :
metric.add_sample('following_count', value=data["following_count"], labels={})
Les choses importantes :

- following_count sera le nom que vous pourrez retrouver dans Prometheus pour afficher la donnée
- value sera la valeur retournée quand vous appelez following_count

Lancer la boucle infinie

On va coincer ce bout de code dans une boucle :
class JsonCollector(object):
    def __init__(self):
        pass

    def collect(self):

        url = mastodon_host + 'api/v1/accounts/1'
        r = requests.get(url)
        data = json.loads(r.content.decode())
        metric = Metric('following_count', 'Number of following account', 'gauge')
        metric.add_sample('following_count', value=data["following_count"], labels={})
        yield metric

if __name__ == "__main__":
    start_http_server(9400)
    REGISTRY.register(JsonCollector())
    while True: time.sleep(1)
Et c'est tout quant à la création d'un Exporter ! Retrouvez le lien vers le code complet en fin de ce billet. Ou . Pour plus de visibilité, j'ai volontairement caché les modules à inclure.

Comment valider que ça fonctionne ?

Un curl et tout va :
root@server ~ # curl localhost:9400
# HELP following_count Number of following account
# TYPE following_count gauge
following_count 552.0

Brancher l'exporter à Prometheus

Tout va se faire, comme d'habitude, dans le prometheus.yml.

  - job_name: 'mastodon'
    static_configs:
      - targets: ['localhost:9400']
On ajoute le job, la target avec son port et on reload la bête.

Notez que j'ai utilisé le port 9400 dans mon exemple. C'est un choix personnel : vous pouvez le changer s'il est déjà utilisé par un de vos services.

Enfin, si tout s'est bien passé, vous devriez pouvoir appeler la variable following_count dans Prometheus !


Vous trouverez un snippet avec l'intégralité du code par ici.

Je retourne à mon code. Vous vous doutez bien qu'avez tout ça, il y a moyen de faire un bel Exporter complet pour Mastodon !

Des bisous,

Des jolis graphes à Facette 0.4.0 et RRD

Rédigé par dada / 15 août 2017 / 9 commentaires


En 2015, j'étais tombé sur Facette, un outil plutôt bien foutu pour afficher l'état de mon serveur sans avoir à m'y connecter. En 2015, après quelques mésaventures, j'avais passé mon système de monitoring sous Monitorix. Eh bien, en 2017, avec la sortie de Facette 0.4rc1 (puis rc2 le temps de rédiger le billet), je retourne à mon premier amour !

Pourquoi ? Parce que cette version 0.4 est totalement retravaillée de l'intérieur, que ses jolis graphiques me manquent et que Monitorix, aussi simple soit-il, n'est pas vraiment une solution flexible. Je vous propose ici de quoi bien commencer, vu que la doc m'a filé mal au crâne.

Installer Facette

Pour les utilisateurs de Debian Jessie en amd64, voici le wget qui va bien. Pour les autres, faites un tour par ici.
wget https://github.com/facette/facette/releases/download/0.4.0rc2/facette_0.4.0rc2_jessie-amd64.deb
Pour installer le paquet :
dpkg -i facette_0.4.0rc2_jessie-amd64.deb 

Installer les dépendances RRD

Il est possible de remplir Facette avec Graphite, Influxdb, Kairosdb, ou encore Facette lui-même. J'ai choisi RDD, parce que.
apt-get install rrdtool rrdcached collectd 

Configurer Nginx

Facette a besoin d'un ReverseProxy pour fonctionner : en voici un exemple.

Configurer RRD

Installer les dépendances de RRD ne suffit pas, voici les quelques étapes supplémentaires pour faire fonctionner le bousin :

Créez les répertoires rrdcached :
mkdir /var/run/rrdcached/
On donne les bons droits à l'utilisateur facette :
chown facette: /var/run/rrdcached
Ajoutez ces lignes dans /etc/default/rrdcached :
OPTS="-s facette"
OPTS="$OPTS -l unix:/var/run/rrdcached/rrdcached.sock"
OPTS="$OPTS -j /var/lib/rrdcached/journal/ -F"
OPTS="$OPTS -w 1800 -z 1800 -f 3600 -t 4"
Cela permet, en gros, à Facette d'utiliser RRD.

Relancez RRDcached.
/etc/init.d/rrdcached restart 
Avec un ps, on vérifie que tout est comme on veut :
root@serveur:~# ps faux | grep rrd
root     14476  0.0  0.0  12736  2204 pts/0    S+   20:33   0:00                      \_ grep rrd
root     14465  0.0  0.0 138288  2632 ?        Ssl  20:33   0:00 /usr/bin/rrdcached -s facette -l unix:/var/run/rrdcached/rrdcached.sock -j /var/lib/rrdcached/journal/ -F -w 1800 -z 1800 -f 3600 -t 4 -p /var/run/rrdcached.pid

Configurer RRD comme fournisseur / provider

Allez dans le panneau d'administration de Facette et configurez RRD avec les informations que vous venez de mettre en place :

- Dossier de base
/var/lib/collectd/rrd

- Socket du démon rrdcached
/var/run/rrdcached/rrdcached.sock

- Motif de correspondance
(?P<source>[^/]+)/(?P<metric>.+).rrd

Voilà ! Vous devriez maintenant pouvoir commencer à faire vos propres graphiques :


Vous arriverez sans doutes à mettre en place vos graphiques comme des grands et à les afficher dans des collections, pas besoin d'expliquer comment faire.

Je reviens rapidement sur les fournisseurs de données. J'ai dit que Facette pouvait être de la partie, en plus de RRD et des autres. Cela veut dire que plusieurs instances bien configurées peuvent être agrégées sur un même serveur. C'était déjà une option bien chouette à l'époque, ça l'est toujours aujourd'hui : avoir une unique page pour, par exemple, surveiller tout le trafic réseau !