Objectifs du chapitre et prérequis

1. Contexte et prérequis

La collecte des métriques, des logs et des traces repose sur des outils spécialisés. Ce livre illustre ces concepts avec Prometheus pour les métriques, Loki pour les journaux et Tempo pour les traces. Ces outils fonctionnent très bien. En revanche, chacun utilise des mécanismes de collecte différents : la collecte active pour les métriques, un agent dédié pour les logs avec Loki, et une collecte passive pour les traces distribuées.

Le projet OpenTelemetry a pour ambition d’unifier ces mécanismes en proposant un agent générique : le collecteur OpenTelemetry. Ce dernier permet de recevoir, transformer et acheminer n’importe quel vecteur de données d’observabilité vers le moteur de stockage ad hoc. Il existe en deux variantes : la version standard ainsi que la version contrib. Cette dernière est plus complète et intègre de nombreux connecteurs supplémentaires. Malgré cela, les connecteurs disponibles restent limités pour des cas d’usage avancés (en particulier autour de Loki) et nécessitent beaucoup d’adaptation.

Le projet OpenTelemetry est encore jeune et en rapide évolution. Les limitations évoquées ici pourraient évoluer entre le moment de la rédaction...

Mise en place de l’agent Grafana Alloy

1. Présentation de l’agent

Les métriques permettent de surveiller l’état global du système, les logs apportent un historique textuel des événements applicatifs et systèmes tandis que les traces fournissent une vue détaillée du cheminement d’une requête.

Cependant, jusqu’à maintenant, ces trois formes de données sont collectées de manière isolée et dépendent des outils utilisés. Cette démarche a plusieurs inconvénients :

L’indisponibilité des outils de collecte entraîne l’arrêt de l’alimentation des autres briques : certaines métriques dérivées des traces ne sont plus disponibles si Tempo est indisponible.
Le travail d’alimentation des métriques (dérivées des traces ou des journaux de Systemd) est fait par Tempo ou Loki directement : l’ingestion d’une grande quantité d’événements peut induire une charge importante sur ces briques.
Enfin, l’acquisition des données reste hétérogène.

Ainsi, pour chaque cas, il faut gérer une configuration spécifique avec potentiellement des identifiants à propager ainsi que des adresses de destination, sans oublier les flux réseau correspondants.

L’intérêt de cet agent est de prendre en charge l’ensemble de cette collecte et d’uniformiser l’acquisition de la donnée brute. Pour mémoire, Alloy signifie « alliage » en français.

Ce qui suit est une introduction au fonctionnement de l’agent de collecte Grafana Alloy avec des exemples de configuration pour chaque vecteur de données.

2. Un mot sur l’origine du projet OpenTelemetry

Le projet OpenTelemetry est géré au sein de la CNCF (Cloud Native Computing Foundation). Il vise à standardiser la collecte, le format et l’export des signaux de supervision à l’aide d’un ensemble cohérent d’outils.

Ces outils comprennent le collecteur mais surtout les librairies permettant d’uniformiser le dialogue entre les différents langages.

En revanche, aucun mécanisme de stockage n’est privilégié :...

Collecte des traces à l’aide de Grafana Alloy

1. Contexte

L’agent Grafana Alloy fait maintenant l’acquisition des données en provenance du journal de SystemD et peut ainsi remplacer l’agent Promtail. Toutefois, il ne s’agit que d’une capacité parmi d’autres.

En effet, ce collecteur supporte l’acquisition, la transformation et l’acheminement de n’importe quel pilier de la norme OpenTelemetry : métriques, logs ou traces.

Il peut ainsi remplacer l’acquisition faite par Prometheus ou Tempo tout en prenant en charge la génération des métriques consommable par Prometheus.

2. Configuration de Tempo

Précédemment, Tempo a été configuré afin d’écouter sur les ports 4317 (protocole otlp/grpc) et 4318 (protocole otlp/http).

Afin de faire cohabiter les deux outils sur une même machine, Tempo utilisera le port 4317 tandis qu’Alloy utilisera le port 4318.

Dans le cas de l’utilisation de deux machines séparées, cette adaptation n’est pas nécessaire.

Ci-dessous la section à modifier dans le fichier /etc/tempo/config.yml :

 
# ...  
distributor:  
 receivers:  
   otlp:  
     protocols:  
       grpc:  
         endpoint: "0.0.0.0:4317"  
       #HTTPReceiversisnow managed by the OpenTelemetrycollector 
       http:  
         endpoint: "" #...

Procédez à l’arrêt/relance du service de Tempo :

$ sudo systemctl restart tempo

3. Gestion des traces à l’aide de l’agent Grafana Alloy

a. Collecte des traces

Première étape : indiquer à Grafana Alloy où envoyer les traces qu’il va recevoir.

Cette définition se fait à l’aide d’une section otelcol.exporter.otlp.

Attention à bien distinguer la notion d’exporteur du monde d’OpenTelemetry de celui de Prometheus. Dans un cas, il s’agit d’un point de collecte, dans l’autre d’un point où envoyer de l’information.

Cette section réclame...

Collecte de métriques à l’aide de l’agent Grafana Alloy

1. Rappel du traitement d’analyse de l’agent Promtail

Lors de la conversion du fichier de l’agent Promtail, le binaire alloy a perdu la phase d’analyse des traces dans le Journal de SystemD. Pour mémoire, l’extrait de la configuration correspondant de l’agent Promtail :

pipeline_stages:  
  - match:  
      selector: '{job="systemd-journal"}'  
      stages:  
        - metrics:  
            log_count_total:  
              type: Counter  
              description: "Total number of log lines"  
              prefix: systemd_journal_  
              config:  
                match_all: true  
                action: inc

Ce code définit un pipeline...

Injection dans Prometheus des métriques de l’agent Grafana Alloy

L’agent génère des métriques. En revanche, aucun mécanisme n’est en place afin de les collecter. Grafana Alloy est tout à fait en mesure de faire ce travail de collecte.

L’activation de cette collecte réclame deux définitions :

Un référencement du collecteur en lui-même à l’aide d’une section prometheus.exporter.self.
La définition d’une collecte de métrique à l’aide d’un bloc prometheus.scape contenant une référence targets vers le collecteur défini précédemment (accessible sous la référence prometheus.exporter.self.<NAME>.targets) ainsi qu’une référence vers le moteur Prometheus défini précédemment (champ forward_to).

Ci-dessous les deux blocs à ajouter reprenant ces indications afin d’activer cette collecte :

prometheus.exporter.self "alloy" {}   
  
prometheus.scrape "alloy" {   
  targets    = prometheus.exporter.self.alloy.targets   
  forward_to = [prometheus.remote_write.default.receiver]   
}

Sauvegardez la modification dans le fichier /etc/alloy/config.alloy puis rechargez la configuration de l’agent afin...

Collecte des métriques systèmes

1. Exporteurs disponibles dans Grafana Alloy

En plus de son propre point de surveillance compatible OpenMetrics, l’agent Alloy met à disposition une collection d’exporteurs standards.

On retrouve pêle-mêle les capacités suivantes :

surveillance du système Linux ou Windows ;
surveillance de type blackbox ou SNMP ;
surveillance des bases de données MySQL/MariaDB/PostgreSQL/Oracle ;
mécanisme de découverte automatique.

Le principe est simple : Grafana Alloy embarque directement le code des exporteurs supportés (dont une grande partie des exporteurs abordés jusqu’à maintenant).

Ce mécanisme est particulièrement intéressant puisqu’il permet de disposer de nombreux exporteurs sans avoir à gérer leurs installations. L’autre avantage étant que les points de collecte ne sont plus disponibles depuis l’extérieur empêchant le détournement éventuel d’informations disponibles dans la liste des métriques.

La liste complète est disponible à l’adresse suivante : https://grafana.com/docs/alloy/latest/reference/components/prometheus/

2. Désactivation de la surveillance système dans Prometheus

Avant d’activer la surveillance système, supprimez la surveillance correspondante du composant...

Unification de la collecte à l'aide de Grafana Alloy