Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

prometheus

Loki : jouer avec ses logs dans Grafana

Rédigé par dada / 18 juin 2019 / 3 commentaires



Le 3 juin dernier est sortie la première version beta de Loki : la v0.1.0. J'attendais cette première version depuis un bon moment ! Depuis le FOSDEM, pour être précis. Grand fan de la stack Prometheus / Grafana, je bavais d'impatience de pouvoir mettre les mains dans un système d'agrégation de logs directement dans Grafana. On y est alors regardons comment ça se passe !

Loki

Loki se comporte comme Prometheus : c'est un logiciel que vous allez installer sur votre machine qui sert pour le monitoring de votre infrastructure et le laisser vivre sa vie. Comme son mentor, ou presque, il va falloir lui associer des exporters pour le gaver de données : Promtail.

Installation

Pour le moment, je me sers de Loki dans un conteneur docker, parce que c'est marrant et parce que voilà. Pour le faire tourner comme j'en ai envie, j'ai besoin de deux fichiers :

- le Dockerfile
FROM grafana/loki

COPY local-config.yaml /etc/loki/local-config.yaml

CMD ["/bin/loki", "-config.file=/etc/loki/local-config.yaml"]
- Les conf dans local-config.yaml :
auth_enabled: false

server:
  http_listen_port: 3100

ingester:
  lifecycler:
    address: 127.0.0.1
    ring:
      kvstore:
        store: inmemory
      replication_factor: 1
  chunk_idle_period: 15m

schema_config:
  configs:
  - from: 2018-04-15
    store: boltdb
    object_store: filesystem
    schema: v9
    index:
      prefix: index_
      period: 168h

storage_config:
  boltdb:
    directory: /tmp/loki/index

  filesystem:
    directory: /tmp/loki/chunks

limits_config:
  enforce_metric_name: false
  reject_old_samples: true
  reject_old_samples_max_age: 168h

chunk_store_config:
  max_look_back_period: 0

table_manager:
  chunk_tables_provisioning:
    inactive_read_throughput: 0
    inactive_write_throughput: 0
    provisioned_read_throughput: 0
    provisioned_write_throughput: 0
  index_tables_provisioning:
    inactive_read_throughput: 0
    inactive_write_throughput: 0
    provisioned_read_throughput: 0
    provisioned_write_throughput: 0
  retention_deletes_enabled: false
  retention_period: 0

Il n'y a pas grand-chose à raconter sur ces deux fichiers. J'ai volontairement réduit le Dockerfile au strict minimum puisque je ne m'en sers que pour copier la configuration de Loki directement dans le conteneur, histoire de réduire la liste des paramètres à son lancement.

Exécution

Pour lancer Loki, on va taper ça dans son terminal :
docker run -d -p 3100:3100 loki
Si tout s'est bien passé, vous devriez avoir un conteneur qui vous répond des politesses :
root@monito:~# curl 127.0.0.1:3100
404 page not found
C'est normal. Par contre, si vous avez autre chose, c'est pas normal.

Maintenant que Loki tourne comme un grand, il faut bien comprendre qu'il ne sert à rien sans son comparse Promtail.

Promtail

Installation

Pour installer Promtail, on va faire exactement comme avec Loki : un conteneur simple avec un peu plus de paramètres au lancement.

- Le Dockerfile :
FROM grafana/promtail

COPY docker-config.yaml /etc/promtail/docker-config.yaml

ENTRYPOINT ["/usr/bin/promtail", "-config.file=/etc/promtail/docker-config.yaml"]
- La conf dans docker-config.yaml :
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://IP_SRV_LOKI:3100/api/prom/push

scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
Si vous avez le coup d’œil, vous devriez avoir remarqué que cette configuration ressemble furieusement à celle de Prometheus : surtout la partie scrape_configs. On y retrouve la conf des jobs, les targets, labels, etc.
Remarquez qu'ici, vous devez remplacer IP_SRV_LOKI par l'IP du serveur sur lequel vous avez effectivement lancé Loki.
Ici, Promtail va aller gratter tous les fichiers locaux se terminant par log dans le répertoire /var/log/ le tout en les classant dans le job system avec le label varlogs.
Locaux, vous dites ? Mais nous sommes dans un conteneur : par quelle magie est-ce possible ? En jonglant avec les volumes !

Exécution

On build le conteneur :
docker build -t promtail .
Dans ce cas simple, on peut lancer Promtail comme ceci :
docker run -d -p 9095:9095  -v /var/log:/var/log promtail
Voyez qu'on monte les logs locaux de la machine dans le conteneur, les rendant accessibles à Promtail. N'hésitez pas à jouer de exec -it pour vérifier qu'ils sont bien là.

On se retrouve avec un Loki capable d'être gavé et d'un Promtail qui, pour le coup, gave Loki. Chouette.

Grafana

Maintenant que les bases sont en place, allons dire à Grafana de nous afficher tout ça. Si, comme moi, Grafana tourne sur la même machine que Loki, ça va être facile. Il faut ajouter un nouveau Data Source local : http://localhost:3100.

Une fois que c'est fait, foncez jouer dans la rubrique Explore et faites votre sélection ! Bon, pour le moment, vous n'avez que les logs system d'une seule machine, mais c'est déjà ça. Si je vous montre le graphique des logs Nginx de ma machine principale, vous avez ce genre de chose :


Si vous affichez cette capture d'écran en grand, vous devriez bien remarquer le manque de sérieux dans quelques-unes de mes configurations (rien de grave, rassurez-vous). On y voit du gris, du vert et du rouge.

Non, vous n'aurez pas les logs à proprement parler mais faites moi confiance, ils s'entassent en dessous.

L'affichage des logs est manipulable avec le Log Stream Selector. Ce machin permet de filtrer l'affichage simplement. Dans mon exemple, remarquez que je sélectionne le job nginxlogs et le hostname de ma machine.
Vous pouvez aussi filtrer le contenu même des logs, le texte en gros, mais je vais vous laisser chercher par vous-même.

Si vous avez vraiment le coup d’œil, dans la configuration de Promtail que je vous propose juste au dessus, il n'y a pas de hostname, ni de log Nginx d'ailleurs.

Pour que ça marche chez vous, vous devez déjà monter le répertoire de log de Nginx dans le conteneur et utiliser cette configuration :
- job_name: nginx
  static_configs:
  - targets:
      - localhost
    labels:
      job: nginxlogs
      __path__: /var/log/nginx/*log
      hostname: b2d
Vous pouvez l'ajouter à la suite de ce que je propose déjà, ça vous fera déjà plus de logs à parcourir !

Bref. Afficher des logs dans Grafana, c'est chouette, mais Loki ne permet heureusement pas que ça sinon il n'y aurait aucun intérêt à parler d'un truc pas encore terminé.

Loki et Prometheus

Avoir un Loki en parallèle d'un Prometheus, ça permet de coupler la puissance des exporters Prometheus avec les logs pompés par Loki. Et ça, c'est beau ! Comment ? En cliquant sur "split" pour partager l'écran de Grafana en choisissant Loki d'un côté et Prometheus de l'autre.

En image ça donne quelque chose comme ça :


Ce qu'on y voit ? La corrélation entre les logs Nginx et le load de la machine. Bon, certes, ce n'est pas foufou mais je n'avais pas d'exemple super pertinent à vous montrer. Quoi qu'il en soit, cette combinaison Loki/Prometheus vous permet de mettre en image ce que vous voulez et ainsi réagir comme il faut, le tout avec un peu de PromQL et des filtres.

Deux yeux, un affichage unifié, c'est franchement cool. Et je ne vous parle pas encore de l'extase si vous avez bien fait l'effort de faire correspondre les labels entre les deux outils...!

Perso, je trouve ça absolument génial et j'ai hâte de continuer à approfondir ma maîtrise de ces beautés !

De retour du FOSDEM 2019

Rédigé par dada / 07 février 2019 / Aucun commentaire


Qu'on aime ou pas cet événement, la Réunion Européenne des Développeurs de Logiciels Libres et Open Source est devenue mon week-end préféré de l'année. Ou presque.
C'est toujours avec un plaisir fou que je me retrouve entouré des gens avec qui je ne peux discuter qu'à travers un écran le reste de l'année : du suisse, de l'allemand, du français, du finlandais et, nouveauté 2019, un américain ! Bref, des copains, trop d'anglais, des bières belges et des discussions jusqu'à pas d'heure.

Cette année et contrairement aux autres fois, j'ai réussi à assister à des conférences et à boire de la bière avec modération ! Je vous assure que ce n'est pas une mince affaire quand on connaît le talent de nos amis belges en matière de brasserie. Le vin est à la France ce que la bière est à la Belgique !

Voici un aperçu de ce que j'ai vu. Tout est en anglais et je ne crois pas qu'il existe un moyen de mettre des sous-titres. Si la langue d'Ed Sheeran n'est pas votre fort, passez votre chemin.

Ceph storage with Rook : Running Ceph on Kubernetes


Je connaissais déjà la bête et vous êtes en plein dedans si vous lisez cet article. Je pensais pouvoir découvrir deux ou trois trucs mais la démonstration qui devait être faite à la fin de la présentation n'a pas pu se faire : souci d'écran.

Loki - Prometheus for logs


Sur celle-là, j'ai carrément jubilé ! Ce truc a l'air vraiment super sympa. J'ai déjà essayé de le faire tourner dans mon cluster mais ce n'est pas vraiment stable. En plus clair, ça fait tomber les nodes un par un à cause d'une consommation de mémoire vive ahurissante.

ActivityPub Panel

 

Assez inévitable quand on est à fond dans le Fédiverse : la table ronde autour d'AP. C’était intéressant et je vous encourage à la regarder même si Chris Webber et son accent américain fatiguent rapidement les oreilles.

Matrix in the French State

 

Assister à une conférence qui parle à la fois de Matrix et de l'État Français, je ne pouvais pas rater ça ! C'était fichtrement intéressant, même si le bonhomme s'est amusé à comparer l'ANSSI à la NSA...

The Cloud Is Just Another Sun

 

Je ne savais pas trop à quoi m'attendre en allant voir cette conférence. Faut dire que j'avais pas totalement lu le descriptif. On y apprend qu'il faut se méfier du Cloud. Je vous invite vivement à la regarder, le mec est clair, et à vous forger une opinion sur le sujet.

Pour le lolz

On est allé, avec les gars de Feneas, voir la conférence autour du réseau social basé sur la blockchain : Hey. Pas grand chose à en dire. C'était technique et très concentré autour de la chaîne de blocs. Je n'ai pas compris grand chose.

Bref

Des litres de bières, des rencontres, des sujets qui font du bien au cerveau et surtout, mais surtout, des gens avec qui on n'arrive jamais à capter : c'est ça le FOSDEM, mon FOSDEM, que j'aime tant !

Merci aux organisateurs et à l'année prochaine !

Prometheus et Graphana pour voir dans son cluster Kubernetes

Rédigé par dada / 23 novembre 2018 / 2 commentaires


Mes aventures avec Kubernetes ne se sont pas arrêtées, loin de là. J'ai actuellement 54 pods répartis sur 3 nodes et 1 master et 2 VM MariaDB en master/slave, le tout reparti sur mon laptop, mon PC fixe et un vieux PC portable datant de ma vie étudiante. Je pourrais aussi vous parler de mon Pi-Hole sur ma Raspberry qui voit passer toutes les requêtes. Bref.
Aujourd'hui, alors que je peste contre ProxySQL sur Mastodon, j'ai décidé de regarder du côté du monitoring de l'orchestrateur, histoire de prendre l'air. Si vous êtes un malheureux lecteur régulier, vous devriez savoir que j'adore Prometheus et que Grafana fait, à mes yeux, des dessins bien plus impressionnants que Klimt.

Note : ça n'a pas calmé ma frustration : c'est très rapide et simple à mettre en place.

Installer Prometheus

Avec pour base mes billets précédents, nous allons installer Prometheus, Grafana et l'AlertManager avec Helm.

Ajouter le dépôt dans helm

Là, à la manière d'APT, nous allons ajouter une source à Helm pour lui permettre d'installer ce qu'on lui demande.

helm repo add coreos https://s3-eu-west-1.amazonaws.com/coreos-charts/stable/

Installer l'operator

On enchaîne sur l'installation de l'operator, le grand patron qui va s'occuper pour nous de Prometheus dans k8s.

helm install coreos/prometheus-operator --name prometheus-operator --namespace monitoring
Une fois exécutée, vous devriez voir ça :
dada@master:~/prometheus$ kubectl get pods -n monitoring -o wide
NAME                                                   READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE
alertmanager-kube-prometheus-0                         2/2     Running   0          37m   10.244.3.140   node3    <none>
kube-prometheus-exporter-kube-state-65b6dbf6b4-b52jl   2/2     Running   0          33m   10.244.3.141   node3    <none>
kube-prometheus-exporter-node-5tnsl                    1/1     Running   0          37m   192.168.0.76   node1    <none>
kube-prometheus-exporter-node-fd7pt                    1/1     Running   0          37m   192.168.0.49   node3    <none>
kube-prometheus-exporter-node-mfdj2                    1/1     Running   0          37m   192.168.0.22   node2    <none>
kube-prometheus-exporter-node-rg5q6                    1/1     Running   0          37m   192.168.0.23   master   <none>
kube-prometheus-grafana-6f6c894c5b-2d6h4               2/2     Running   0          37m   10.244.2.165   node2    <none>
prometheus-kube-prometheus-0                           3/3     Running   1          37m   10.244.1.187   node1    <none>
prometheus-operator-87779759-wkpfz                     1/1     Running   0          49m   10.244.1.185   node1    <none>

Notez que si vous êtes, comme moi, sur une connexion ADSL classique, vous aller avoir le temps d'aller faire couler un grand café et d'aller le boire une clope au bec et au soleil. Votre cluster va télécharger beaucoup de pods et sur chaque nœud.

En y regardant bien, on retrouve :

  • L'AlertManager permettant de nous spammer en cas de souci,
  • Les exporter nodes placés logiquement sur chaque node et sur notre master,
  • Grafana, le copain de Prometheus qui vous fait des beaux dessins,
  • Le kube et l'operator.

Accéder à tout ça

L'installation est vraiment triviale. Le petit bonus de ce billet sera de vous passer une liste de commandes pour admirer le tout dans votre navigateur préféré : Firefox.

Pour accéder à l'interface de Prometheus

Commencez par ouvrir un tunnel SSH sur le port 9090 vers votre master :

ssh -L 9090:127.0.0.1:9090 dada@IPDuMaster

Puis lancez le port-foward :

kubectl port-forward -n monitoring prometheus-prometheus-operator-prometheus-0 9090

Pour accéder à l'interface de Grafana

Encore un tunnel SSH, sur le 3000 ce coup-ci :

ssh -L 3000:127.0.0.1:3000 dada@IPDuMaster

Et encore un port-forward :

kubectl port-forward $(kubectl get  pods --selector=app=grafana -n  monitoring --output=jsonpath="{.items..metadata.name}") -n monitoring  3000

Vous êtes bons ! Les dashboards sont maintenant accessibles en tapant http://localhost:PORT dans Firefox.

En image, ça devrait donner ça pour Grafana :

Et ça pour les alertes Prometheus :

Alors, oui. Vous avez aussi remarqué que des alertes étaient déjà levées ? Ce sont des outils/configurations que Prometheus attend de rencontrer dans votre cluster. Le mien n'a pas encore ces histoires de scheduler ou de controller manager. Ça va faire partie des découvertes à suivre dans les futurs billets.

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,