Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Technologie

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

Se faire un réveil 4.0 avec un Raspberry Pi

Rédigé par dada / 15 janvier 2020 / 10 commentaires


Je me suis toujours méfié des objets connectés. Ce n'est un secret pour personne : une grande partie des babioles vendues sous la bannière IoT ou objet connecté sont des machins non sécurisés, non maintenus, non écologiques et d'un intérêt plus que discutable.


Ceci dit, avec l'aide de la WebThings Gateway de Mozilla, il est possible de commencer à jouer avec son matériel existant pour le rendre connecté. Ce truc permet de garder le contrôle des-dits machins connectés puisque le cerveau de ces choses sera dans votre salon et pas sur des serveurs obscurs à l'autre bout du monde.

Un exemple que je vous propose : mettre de côté votre ancien réveil, qui marche très bien, pour le remplacer par un Raspberry Pi.

Les ingrédients

Pour ce faire, il vous faudra :
  • un Raspberry Pi (du Zero au RP4)
  • des enceintes classiques
  • un câble jack
  • l'URL de streaming de FranceInfo

Le Raspberry Pi

Vous allez commencer par utiliser WebThings Gateway comme système d'exploitation de votre Raspberry Pi. C'est une Rasbpian, basée sur Debian donc, modifiée par Mozilla, rien de plus.
Je ne vais pas m'éterniser sur la procédure d'installation : c'est très simple.
Il suffit d'aller télécharger l'image disponible ici, de flasher la carte SD avec et de placer cette-dite carte dans l'ordinateur.

Une fois que la bête a démarré, un nouveau réseau Wifi va apparaître. Connectez vous y depuis votre PC et suivez la procédure de configuration :
  • connectez-la au réseau wifi de votre box
  • créez un compte utilisateur
  • choisissez l'URL qui va bien
L'attribution de l'URL peut prendre du temps, ne paniquez pas, ne touchez à rien : Mozilla vous enverra un lien par mail quand tout sera effectif.

Installer l'extension Radio

Par défaut, WTG ne fait pas grand chose. Tout comme pour Firefox, Mozilla s'appuie sur les gens pour fournir des extensions en pagaille. Et ça marche plutôt pas mal si j'en crois le dépôt officiel.

Je vous laisse cliquer dans les menus pour installer Radio : Settings > Add-ons > le + en bas à droite -> Internet radio. 

L'add-on vient avec quelques webradios inconnues au bataillon. Pas grave, on va installer celle qui nous intéresse : la radio d'État.


Pour récupérer l'adresse de streaming, je suis passé par ce lien qui m'a permis de trouver ça :
  • http://direct.franceinfo.fr/live/franceinfo-midfi.mp3
Il est possible que le flux change ou qu'il ne soit pas vraiment fonctionnel alors prenez le temps de le vérifier. L'autre jour, par exemple, j'avais bien un flux lu mais il ne contenait pas le moindre son : méfiez-vous.

Maintenant, vous devriez avoir WTG correctement configuré dans votre Raspberry Pi. Il ne reste plus qu'à créer la règle qui va permettre d'allumer tout ça aux heures voulues.

Mettre en place le réveil 4.0

WTG fonctionne, en gros, avec deux principes : les choses (things) et les règles (rules).

Les règles permettent de faire faire des choses à vos choses. Vous suivez ?


Dans le cadre du réveil, on va s'amuser à dire à WTG d'activer la chose radio, avec le volume qui va bien, à l'heure qui va bien. Le panneau de création d'une règle est coupé en deux :
  • À gauche, la ou les conditions d'entrée
  • À droite, la ou les conditions de sortie


On va remarquer la complexité relative de la règle puisqu'il faut :
- Deux choses Clock qui déclenchent deux événements à 7h du matin
- Une chose Radio qui allume la radio
- Une chose Radio qui fixe le volume

En une seule phrase, la logique ressemble à ça : À 7h du matin, tu allumes la radio et à 7h du matin, tu montes le volume à 75.
La partie volume de ma règle n'est pas obligatoire. Elle est présente dans mon exemple parce que le volume de base, 50, est trop faible à mon goût.

Aller un peu plus loin

Dans mon cas personnel, j'ai décidé d'ajouter une règle qui arrête la radio à 8h. Pourquoi ? Parce que je dois impérativement décoller à 8h sans quoi je rate mon train.


Si vous avez capté la logique, j'ai utilisé une chose Clock qui se déclenche à 8h et une chose Radio qui arrête la boucle d'informations du matin.

Et voilà !

Conclusion

Vous n'avez plus qu'à laisser votre imagination tourner. Avec WTG, vous pouvez avoir des objets connectés qui se contrôlent depuis un ordinateur dans votre salon que vous pouvez arrêter quand vous le voulez et qui est entièrement open-source.

C'est sans intérêt, donc indispensable ! Bonne année !

7 astuces pour économiser sa connexion 3G/4G et sa batterie

Rédigé par dada / 29 août 2019 / 7 commentaires


Android, pour ne parler que de lui, est devenu le Windows des systèmes d'exploitation mobiles. Voici quelques conseils pour le calmer et soulager votre téléphone.

1 - Utilisez Firefox comme navigateur par défaut

On vous dit qu'il est lent, qu'il est moins bien ? Laissez les gens parler. Utiliser ce navigateur par défaut en installant l'extension uBlock Origin permet de naviguer sur Internet sans charger les publicités et autres cochonneries. Sachant que les publicités peuvent représenter jusqu'à 25% du poids d'un site, ça fait 25% de data économisées ! Google Chrome a déclaré ne plus vouloir laisser les bloqueurs de pub travailler : laissez-le tomber.

2 - Installez Blokada

Blokada permet d'aller plus loin encore qu'avec Firefox en bloquant les échanges permanents de votre téléphone avec l'extérieur. Le coté smart de votre phone, ça se dit pour les choses qu'il balance à Internet, absolument pas pour sa capacité à utiliser des logiciels.
Avec Blokada, les applications que vous avez ne pourront plus aller pomper votre forfait 3G sans votre accord.

3 - Supprimez les applications inutiles

Vous lisez, disons, la presse en ligne ? Supprimez tout de suite leurs applications mobiles et optez pour les PWA. Késako ? Votre téléphone est parfaitement capable de créer une application à partir d'un site web. C'est ça, une Progressive Web App : c'est créer une application LeMonde sans installer l'application du même nom. Dans 99% des cas, les applications n'apportent rien et bouffent votre data pour envoyer des statistiques aux entreprises partenaires. En allant sur ces sites avec Firefox, une petite maison avec une croix à l'intérieur va apparaître : en cliquant dessus, vous installez votre application, économique celle-là. Trop facile.

4 - Supprimez les applications Google

Si vous découvrez maintenant que les applications de Google consomment de la data alors que vous ne vous en servez pas, il est temps de sortir de votre grotte ! Que ce soit Mail, Maps, Docs ou les autres, elles communiquent en permanence avec les serveurs d'Alphabet, consommant votre data, épuisant votre batterie alors que vous n'avez rien demandé.
Prenez un peu de temps pour nettoyer votre téléphone et vous sauvegarderez de la data et de la batterie ! Il existe un paquet d'applications effectuant les mêmes tâches, sans siphonner votre forfait 4G.

5 - Désactivez les services inutilisés

Vous avez sans doute pris l'habitude de laisser le Wifi, le Bluetooth ou encore le GPS activés ? Désactivez tout ça quand vous n'en avez pas besoin. Avec le Wifi actif loin de votre boxe, votre téléphone, perdu, essaiera de se connecter à tous les réseaux qu'il va croiser, en suçant votre batterie. Idem pour le Bluetooth. Pour le GPS, c'est encore pire : il vous géolocalisera tout le temps pour répondre à la curiosité des applications que vous traînez. Dégagez tout ça !

6 - Streaming, Réseaux sociaux

Est-ce que vous vous êtes déjà demandé combien vous coûtent les applications de streaming musical ? Perso, au rythme de 4 ou 5 albums que j'ajoute à ma collection par an, j'ai de quoi écouter de la musique d’excellente qualité pour 70€ l'année. Le truc magique ? Prenez 5min pour copier/coller votre collection dans la carte SD de votre téléphone.
Les réseaux sociaux ? Vraiment ? On en parle ? L'application Facebook pompe jusqu'à 20% de votre batterie. Twitter ? Vous utilisez encore ce truc à la con ? Viendez sur Mastodon, plutôt.

7 - Installez une ROM alternative

Les constructeurs et vendeurs bourrent votre téléphone d'applications lamentables : des applications qui fonctionnent sans rien vous demander tout en massacrant votre 4G et votre batterie.
Pour vous débarrasser de façon radicale de toutes ces cochonneries, pensez à aller voir du côté de /e/OS : si votre téléphone est compatible, tentez votre chance et essayez-le ! Vous pourrez toujours installer des applications du Playstore, mais uniquement celles que vous voulez, ce coup-ci !

Enfin voilà. Prenez le temps de faire du ménage, de reprendre le contrôle du machin que vous laissez dans la poche et vous serez plus heureux.

Ajuster le Nextcloud de son Turris Mox

Rédigé par dada / 12 août 2019 / 3 commentaires



Un Turris Mox ?

Pour celles et ceux qui ne sauraient pas ce que c'est, je vous redirige par ici. Je vous balance directement le lien vers la description de sa version cloud parce que c'est celle que j'ai prise. L'objectif ? Arrêter d'héberger mes données sur des serveurs tiers et revenir à un vrai auto-hébergement pour toute ma partie données perso. Ce blog et les autres outils resterons dans les nuages.

Nextcloud

L'intégration de Nextcloud dans le TurrisOS, la variante d'OpenWRT présente dans le Mox, ne vient pas avec toutes les petites configurations qui vont bien. Voici une rapide liste des choses à modifier ou corriger pour que tout se passe au mieux.

Remarque

Notez que le Mox est un petit appareil aux performances modestes. Il comblera sans trop de problème mes besoins perso, en tant qu'utilisateur unique de mon instance, mais n'espérez réussir à gérer convenablement plusieurs utilisateurs actifs en même temps.

Les modifications

  • Variables d'environnement
vim /etc/php7-fpm.d/www.conf 
Vous y trouverez ces variables commentées, enlevez le point-virgule qui traîne devant :
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
  • PHP Memory limit
La configuration de PHP-FPM vient avec un memory_limit de 384M quand Nextcloud en réclame 512 pour bien fonctionner. Pour corriger le tire, allez modifier la valeur dans /etc/php.ini pour remplacer 384 par 512 :
memory_limit = 512M
Et redémarrer le PHP-FPM :
/etc/init.d/php7-fpm restart
  • Opcache
Ajoutez la conf Opcache qui va bien dans /etc/php.ini :
opcache.enable=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
  • Lighttpd
Le serveur web choisi par TurrisOS est Lighttpd. Sachez qu'il est possible d'installer Nginx pour le remplacer mais comme c'est la configuration par défaut, j'ai décidé de le laisser là.

Pour corriger les erreurs de well-known, ajouter les lignes qui manquent dans /etc/lighttpd/conf.d/nextcloud.conf :
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )

$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
     url.access-deny = ("")
}

# Redirect Cal/CardDAV requests to Nextcloud endpoint:
url.redirect = (
    "^/.well-known/caldav"  => "/nextcloud/remote.php/dav",
    "^/.well-known/carddav" => "/nextcloud/remote.php/dav",
"^/.well-known/webfinger" => "/nextcloud/public.php?service=webfinger"

)
Et redémarrez le service :
/etc/init.d/lighttpd restart
  • Memcache
Pour le moment, je n'ai pas trouvé comment faire pour mettre en place un système de cache honorable pour améliorer les performances générales de Nextcloud. Il n'y a pas, dans les dépôts officiels de TurrisOS, de paquet php-redis ou encore php-memcached. Du coup, pas de cache.


Loki : jouer avec ses logs dans Grafana

Rédigé par dada / 18 juin 2019 / 5 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 !