Découverte de l’outil de supervision Prometheus

46
31
jan.
2018
Supervision

Par le passé, j’ai été un grand utilisateur de Nagios et ses différents forks. J’avais pour habitude de le coupler avec un PNP4Nagios pour obtenir de jolies courbes sur les métriques remontées par mes greffons de surveillance. J’ai également commencé à utiliser l’outil Beats d’Elastic.

Prometheus

Pour diverses raisons, j’ai arrêté d’utiliser ces outils, pour passer sur une stack très différente basée sur Prometheus et Grafana.

Sommaire

Un peu de contexte

Pour diverses raisons, j’ai eu de nouveau à gérer la mise en place d’une surveillance pour des plates‐formes d’intégration ainsi que pour une plate‐forme servant principalement à faire du benchmark. Là encore, j’aurais pu ressortir mes scripts de suivi sous Nagios couplé à PNP4Nagios, me tourner vers un Cacti ou encore me mettre à Zabbix. Un autre candidat intéressant était la suite Beats d’Elastic.

Sauf que tous ces outils ne m’emballaient pas et avaient tous un défaut :

  • Nagios, PNP4Nagios et Cacti étaient clairement vieillots (avec ça, je vais me faire des amis) ;
  • je ne connaissais pas Zabbix mais je n’avais pas envie de m’y mettre (même si l’on m’en avait dit du bien) ;
  • Enfin, même si Beats d’Elastic est relativement intéressant, j’ai de plus en plus tendance à trouver Elasticsearch lourdaud et grand consommateur de ressource (grâce notamment à la légèreté de Java).

Bref, je trouvais que ces outils restaient en deçà de ce qu’on pourrait attendre d’une stack de supervision moderne. Autre point relativement contraignant : une intégration toujours complexe à réaliser alors que la tendance est plutôt vers des outils de moins en moins intrusifs (je suis un grand consommateur d’Ansible pour cette raison).

C’est donc dans cet état d’esprit que je m’apprêtais à mettre en place Beats d’Elasticsearch. Un peu par hasard, j’ai entendu parler de Prometheus et devant l’enthousiasme de la personne qui m’en parlait, j’ai décidé d’y jeter un coup d’œil.

Découverte de Prometheus : principe de fonctionnement

Avant de passer à la mise en place de Prometheus, attardons‐nous sur l’architecture de ce logiciel :
https://prometheus.io/assets/architecture.svg

Dans les éléments qui vont particulièrement nous intéresser, nous retiendrons les briques suivantes :

  • Prometheus server : c’est le moteur permettant de stocker les métriques collectées ;
  • Jobs exporters : il s’agit d’agents sur lesquels Prometheus viendra collecter les différentes métriques ;
  • Web UI : restitution des métriques à l’utilisateur ;
  • Alertmanager : gestionnaire d’envoi des alertes aux utilisateurs.

Principe de fonctionnement du stockage Prometheus

Prometheus utilise un stockage spécifique pour ses métriques. De ce stockage découlent les atouts et inconvénients de ce moteur. Avant la version 2, il existait trois formats v0, v1 et v2 (ce n’est plus le cas depuis la version 2). Dans la suite, nous reviendrons sur cette évolution et en quoi elle permet d’en retirer des avantages.

Au niveau de ce stockage, certains aspects ne seront pas abordés comme, par exemple, la structure des tampons utilisés ou l’écriture sur disque. Si vous voulez une description un peu plus poussée, vous pouvez vous tourner vers la présentation de Fabian Reinartz : Time Series in Prometheus (sur Slideshare.net).

Le format de cette base de données est spécifique (série temporelle ou time series dans la langue de Shakespeare) et diffère de celui qu’on pourrait retrouver dans une base de données classique (SQL ou NoSQL). En effet, les données collectées ont des caractéristiques connues :

  • collecte de métrique à intervalle connu (toutes les 60 secondes) ;
  • similarité des données d’une collecte sur l’autre (généralement, l’espace disque des partitions sur un serveur ne change pas).

Du fait de ces caractéristiques, Prometheus compresse les données en mémoire et sur disque. Il en résulte une bien meilleure utilisation des ressources mémoire, processeur et disque.

Présentation des données à stocker

Chaque collecte de métrique ramènera un groupe de métriques. Ces métriques seront toutes associées à une date stockée sous la forme d’un entier représentant le nombre de millisecondes écoulées depuis le 1er janvier 1970. Chaque métrique sera représentée sous la forme d’un chiffre à virgule flottante de type float64.

Ci‐dessous un exemple de valeurs que nous allons stocker dans le moteur Prometheus :

  Métrique      Horodatage    Valeur
http_requests_total  1434317560938 1500
http_requests_total  1434317562939 1520
http_requests_total  1434317564939 1531
http_requests_total  1434317566945 1554

Stockage par double delta

Comme on peut le voir, les données ont comme caractéristiques d’être collectées à intervalles réguliers (ici, environ toutes les deux secondes) et d’avoir des valeurs proches d’une collecte à une autre. Afin de réduire la place prise par les données, il est possible de ne stocker que le delta de ces mesures.

Ainsi, une première façon de réduire la place prise par ces données est de les stocker sous la forme d'un delta :

Métrique   Delta horodatage   Valeur
http_requests_total       1434317560938     1500
http_requests_total     +2001     +20
http_requests_total     +2000     +22
http_requests_total     +2006     +20

Lors de la première mesure, l’horodatage consommera bien huit octets (un entier sur 64 bits). La donnée quant à elle consommera huit octets (Prometheus stocke toutes ses valeurs au format float64), soit 16 octets au total.

Dans le cas de l’horodatage, le delta pourra être stocké sous forme d’un entier de longueur variable fonction du delta avec la valeur précédente.

Pour le stockage de la métrique, le moteur fait appel à un ou exclusif (opération XOR) pour comparer l’ancienne et la nouvelle valeur. En fonction de ce résultat, le moteur stockera une représentation compressée de la différence constatée. Si ça n’est pas possible, le moteur utilisera une valeur sur huit octets.

Mais en réalité, Prometheus fait appel à un stockage par double delta. Le principe est simple : pour la première mesure, il utilise un stockage brut, pour la seconde mesure, il fait la différence par rapport à la première mesure et toutes les autres mesures sont stockées par rapport au delta du delta de la valeur précédente. Ci‐dessous le stockage que nous obtenons avec le jeu de données :

Métrique Delta delta horodatage     Valeur
http_requests_total     1434317560938     1500
http_requests_total     +2001     +20
http_requests_total     +-1     ++2
http_requests_total     ++6     +-2

Sur une grande quantité de données, cet algorithme permet de réduire l’espace consommé pour arriver à une moyenne de l’ordre de 1,37 octet par échantillon de métrique (au lieu des 16 octets initiaux).

Pour aller plus loin

Cette technique de stockage par mots de longueurs variables est similaire à celle décrite dans un papier sur l’outil Gorilla (produit interne de FaceBook). Ci‐après, le lien vers le PDF de l’article en question : http://www.vldb.org/pvldb/vol8/p1816-teller.pdf.

Prometheus server

Ce processus a en charge la collecte à intervalles réguliers de l’état des différents exporters. Il stocke les métriques collectées dans sa base de données et peut ensuite être interrogé au travers de son API (via HTTP).
Un autre rôle du serveur Prometheus est d’évaluer à intervalles réguliers les définitions d’alertes. Ces dernières s’appuient sur l’état des métriques internes collectées.

Installation du serveur Prometheus

Les inconditionnels de Docker pourront lancer l’installation à l’aide de la commande suivante :

docker run -p 9090:9090 prom/prometheus

Pour les personnes ayant toujours recours à des machines système classiques, vous devrez récupérer l’archive de Prometheus à depuis le site Web du projet. Vous aurez ensuite à :

  • décompresser l’archive avec la commande suivante :

    tar xfvz prometheus-2.0.0.linux-amd64.tar.gz

  • lancer Prometheus de la manière suivante :

    ./prometheus-2.0.0.linux-amd64/prometheus --config.file=prometheus-2.0.0.linux-amd64/prometheus.yml

La console Prometheus est maintenant joignable à l’URL suivante : http://localhost:9090.

Configuration du serveur Prometheus

Tel que vous l’avez lancé dans le précédent paragraphe, Prometheus sera configuré par défaut afin de scruter son propre état. Si vous souhaitez gérer sa configuration, vous aurez besoin d’alimenter un fichier au format YAML.

Si ce fichier est disponible à l’emplacement ~/prometheus.yml, vous devrez relancer votre conteneur Docker avec la commande suivante :
docker run -p 9090:9090 -v ~/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

Pour un lancement classique, la commande sera la suivante :
./prometheus-2.0.0.linux-amd64/prometheus --config.file=~/prometheus.yml

Jobs exporter

Autre élément important de l’architecture : les sources de données à collecter.

Pour cela, Prometheus offre des exporters prêts à l’emploi. Parmi ceux‐ci, le node exporter est particulièrement intéressant. Ce dernier se charge d’exporter énormément de métriques système, que ça soit pour des machines physiques ou virtuelles. On y retrouve indifféremment :

  • les informations sur l’activité processeur (au processeur près) ;
  • la consommation de la ressource mémoire ;
  • l’activité des disques (% d’attente, nombre d’entrées‐sorties par seconde, nombre de mégaoctets par seconde en lecture et écriture) ;
  • l’activité des interfaces réseau ;
  • enfin, sur les machines physiques, des indications comme par exemple la température des processeurs.

En réalité, il y a tellement de métriques à disposition (comme par exemple l’état de l’entropie du système) qu’il serait difficile de tout détailler.

À noter qu’il existe également des exporters pour certains produits connus du marché, comme par exemple HAProxy, Apache ou encore MySQL.

L’installation d’un node exporter se réalise en deux phases :

  • décompression des binaires sur la machine à superviser et lancement de l’agent ;
  • déclaration au niveau du serveur Prometheus de l’instance à scruter.

Installation d'un node exporter

Installation d’un node exporter

L’installation est assez classique. Il faut tout d’abord récupérer l’archive de l’exporter sur https://prometheus.io/download/ [lien direct].

Décompresser ensuite l’archive avec la commande suivante :
tar xfvz node_exporter-0.15.2.linux-amd64.tar.gz

Le node se lance ensuite de la manière suivante :
./node_exporter-0.15.2.linux-amd64/node_exporter

Configuration de Prometheus

Une fois que le node exporter est lancé, il est maintenant temps de l’indiquer à Prometheus. Afin que cet ajout soit le plus souple possible, ajouter la section suivante dans le fichier prometheus.yml (au niveau du champ scrape_configs) :

scrape_configs:
[...]
  - job_name: 'node'
    file_sd_configs:
        - files: [ "/etc/prometheus/nodes/*.yml" ]
[...]

Créez le répertoire jobs :
mkdir -p /etc/prometheus/nodes

Avec cette directive, Prometheus sera en mesure de scruter le contenu du répertoire /etc/prometheus/nodes et d'ajouter automatiquement à sa configuration tous les fichiers .yml qui y seront déposés. Dans le cas présent, ajoutez le fichier /etc/prometheus/nodes/localhost.yml avec le contenu suivant :

- targets: [ "localhost:9100" ]
  labels:
      # Vous pouvez ajouter ce que vous voulez pour taguer la machine
      host: "localhost"

Dès la création du fichier, Prometheus charge ce fichier et commence sa collecte.

Web UI : découverte de Grafana

Par défaut, Prometheus offre à l’utilisateur une interface de restitution. Mais cette dernière est assez rudimentaire (elle est surtout là pour de la mise au point). Les auteurs conseillent de s’appuyer sur l’interface Grafana qui est bien plus avancée de ce point de vue.

Installation de Grafana

Grafana est disponible au téléchargement à l’emplacement suivant : https://grafana.com/grafana/download.

Une fois Grafana téléchargé, l’installation se fait avec yum ou dpkg.

Ci‐dessous l’instruction pour Debian :

wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_4.6.3_amd64.deb 
sudo dpkg -i grafana_4.6.3_amd64.deb

Et la même chose pour Red Hat ou CentOS :

wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-4.6.3-1.x86_64.rpm 
sudo yum localinstall grafana-4.6.3-1.x86_64.rpm

Il est également possible de récupérer une archive TAR compressée avec GZIP seule. En effet, comme Prometheus, Grafana est écrit en Go et, par conséquence, n’a pas de dépendance au niveau système.

Une fois installé, il faut démarrer la console avec la commande suivante :
systemctl start grafana

L’utilisateur peut maintenant se connecter sur l’adresse URL de Grafana : http://localhost:3000

Si vous souhaitez activer Grafana au démarrage, lancez la commande suivante :
systemctl enable grafana

Interfaçage avec Prometheus

Une fois sur l’interface de Grafana, authentifiez‐vous en tant qu’administrateur (compte admin, mot de passe admin).

Seconde étape : la configuration d’une source de données. Au niveau des champs, vous pourrez rentrer les valeurs suivantes :

  • Name : nom de la connexion (ex : Prometheus) ;
  • Type : choisir Prometheus ;
  • URL : rentrer http://localhost:9090 ;
  • Access : laisser la valeur proxy.

Laissez les autres champs à la valeur par défaut et cliquez sur Add.

Ajout d’un dashboard

La source de données est maintenant configurée. En revanche, il n’y a aucun tableau de bord. La bonne nouvelle est que vous en avez de nombreux disponibles prêts à l’emploi à l’adresse suivante : https://grafana.com/dashboards.

Parmi ces tableaux de bords, Node Exporter Full permet de récupérer toutes les métriques remontées par les nodes exporter de Prometheus. Il est consultable à l’adresse suivante : https://grafana.com/dashboards/1860.

L’installation est réalisée par l’écran d’importation de Grafana en saisissant l’identifiant du dashboard (ici 1860). En cas de problème d’ouverture de flux (avec un serveur mandataire), il est possible de télécharger le dashboard au format JSON, pour ensuite le téléverser sur via interface de Grafana.

Une fois le dashboard créé, vous devriez obtenir les graphiques suivants :
Capture d’écran du dashboard

Définition d’alertes

Tout est en place pour la collecte et la restitution des données. Il faut maintenant définir des alertes afin de les remonter auprès des différents opérateurs. Première chose, il faut modifier la configuration de Prometheus afin de lui faire charger des règles permettant de générer des alertes. Ci‐dessous la déclaration à rattacher au niveau du champ global :

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
    - /etc/prometheus/rules/node.rules.yml

Créez également le fichier /etc/prometheus/rules/node.rules.yml en y mettant les éléments suivants :

  • une variable groups avec une liste de règles ;
  • pour chaque règle les champs name et rules ;
  • pour chaque enregistrement de rules, la définition d’une alerte.

Une alerte pourra faire appel à différents champs. Parmi ces derniers, vous pouvez retenir ceux‐ci :

  • le champ alert, avec le nom de cette dernière ;
  • le champ expr, avec une requête permettant de déclencher l’alerte ;
  • le champ for, pour indiquer au bout de combien de temps vous considérez que l’alerte est caractérisée ;
  • enfin, les champs labels et annotations peuvent apporter des informations supplémentaires sur l’alerte (nom du système de fichiers, nom du serveur, petite phrase pour donner une procédure permettant de rétablir le service, etc.).

Ci‐dessous quelques exemples d’alertes pour une surveillance des machines :

groups:
- name: Alerts nodes
  rules:
  - alert: DiskWillFillIn4Hours
    expr: predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600) < 0
    for: 5m
    labels:
      severity: critical
    annotations:
      title: '{{ $labels.mountpoint }} is almost full on {{ $labels.instance }}: {{ $value | humanize }}%'
  - alert: NoDiskSpace
    expr: node_filesystem_avail{fstype=~"(ext.|xfs)",job="node"} / node_filesystem_size{fstype=~"(ext.|xfs)",job="node"} * 100 <= 1
    for: 15m
    labels:
      severity: critical
    annotations:
      description: There's only 1% disk space left on host {{ $labels.instance }}
      title: 'No disk space left on {{ $labels.mountpoint }} on {{ $labels.instance }}: {{ $value | humanize }}%'
  - alert: HighInodeUsage
    expr: node_filesystem_files_free{fstype=~"(ext.|xfs)",job="node"} / node_filesystem_files{fstype=~"(ext.|xfs)",job="node"} * 100 <= 20
    for: 15m
    labels:
      severity: critical
    annotations:
      description: '{{ $labels.mountpoint }} inodes are running low. Please consider removing file.'
      title: 'Free inodes on $labels.instance }} on mountpoint {{ $labels.mountpoint }} is at {{ $value | printf "%.2f" }}%'
  - alert: ExtremelyHighCPU
    expr: instance:node_cpu_in_use:ratio > 0.95
    for: 2h
    labels:
      severity: critical
    annotations:
      description: 'CPU use percent is extremely high on {{ $labels.instance }} for the past 2 hours.'
      title: 'CPU use percent is extremely high on {{ $labels.instance }} for the past 2 hours.'
  - alert: HighCPU
    expr: instance:node_cpu_in_use:ratio > 0.8
    for: 2h
    labels:
      severity: critical
    annotations:
      description: 'CPU use percent is extremely high on {{ $labels.instance }} for the past 2 hours.'
      title: 'CPU use percent is high on {{ $labels.instance }} for the past 2 hours.'

En se rendant dans la console de Prometheus sur le lien Alerts, vous obtiendrez toutes les alertes définies et la liste des exporters en erreur.
Exemple d’alerte dans la console Prometheus

Alertmanager

Ce processus aura en charge de restituer auprès des équipes en charge des serveurs l’arrivée de nouveaux événements.

Installation

Tout comme pour la partie serveur de Prometheus, vous pouvez démarrer le gestionnaire d’alertes avec la commande :
docker run -p 9093:9093 prom/alertmanager

Pour les autres, vous allez devoir :

  • récupérer l’archive d’alertmanager (actuellement en version 0.13.0) :

    wget https://github.com/prometheus/alertmanager/releases/download/v0.13.0/alertmanager-0.13.0.linux-amd64.tar.gz

  • décompressez‐la avec la commande suivante :

    tar xfvz alertmanager-0.13.0.linux-amd64.tar.gz

  • enfin, le lancement du gestionnaire d'alerte se fait avec les commandes suivantes :

    cd ./alertmanager-0.13.0.linux-amd64 ./alertmanager --config.file=simple.yml

Le fichier simple.yml est un exemple de configuration.

Configuration du gestionnaire d’alertes

Le gestionnaire d’alertes est très ouvert au niveau de ses capacités de communication. Vous pouvez envoyer des courriels ou des messages vers Slack pour notifier l’arrivée de nouvelles alertes.

Ci‐dessous un exemple de configuration mettant en place l’envoi des notifications vers Slack :

[...]
# The root route on which each incoming alert enters.
route:
  # On envoie tout vers slack par défaut
  receiver: slack
[...]
receivers:
- name: 'slack'
  slack_configs:
  - api_url: "https://hooks.slack.com/services/xxx/xxx/xxxxxx"
    channel: '#prometheus'
[...]

Dès que Prometheus envoie une alerte, cette dernière est poussée vers Slack sur le canal #prometheus afin d’être prise en compte par les différentes équipes.

Branchement sur Prometheus

Dernier point : brancher le serveur Prometheus sur le gestionnaire d’alertes avec la configuration suivante à ajouter dans le fichier prometheus.yml :

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # À adapter en fonction du serveur gestionnaire d’alertes
      - localhost:9093

Un redémarrage du serveur sera nécessaire pour la prise en compte. Ceci fait, les alertes devraient commencer à arriver sur le canal de communication.

Pour conclure

Le tour du propriétaire est maintenant terminé. À vous de jouer !

Aller plus loin

  • # nethdata

    Posté par . Évalué à 10. Dernière modification le 31/01/18 à 11:12.

    Je me suis intéressé au couple prometheus/grafana mais sans pour l'instant avoir le temps de le mettre en place (le fait qu'on ait déjà une solution d'un autre millénaire, mais corporate et qui fonctionne n'aide pas).

    Au hasard de la lecture du fedora magazine j'ai aussi récemment découvert netdata qui fait un peu le même job mais au niveau local, en live et de façon absolument géniale et sexy. Là où c'est intéressant c'est que netdata fourni une api REST qui peut être interrogée par prometheus et peut donc dans ce cas de node exporter. Ici la partie de la conf à faire dans prometheus :

          - job_name: 'netdata-scrape'
    
        metrics_path: '/api/v1/allmetrics'
        params:
          # format: prometheus | prometheus_all_hosts
          format: [prometheus]
          #
          # sources: as-collected | raw | average | sum | volume
          # default is: average
          #source: [as-collected]
          #
          # server name for this prometheus - the default is the client IP
          # for netdata to uniquely identify it
          #server: ['prometheus1']
        honor_labels: true
    
        static_configs:
          - targets: ['{your.netdata.ip}:19999']
    

    Du coup ben netdata est très bien pour interroger les machines en live (une sorte de top/glances du sous stéroïdes) et la partie prometheus + grafana permet de gérer l'historique.

    • [^] # Re: nethdata

      Posté par . Évalué à 1.

      Je ne connaissais pas netdata, merci ! Une très belle découverte.

      • [^] # Re: nethdata

        Posté par (page perso) . Évalué à 2.

        il y a aussi pcp qui vient avec les distrib qui est tres sympa aussi.

        • [^] # Re: netdata

          Posté par . Évalué à 1.

          pcp ?

          • [^] # Re: netdata

            Posté par (page perso) . Évalué à 4.

            oui pardon pour ne pas avoir donne le lien, mais comme c'etait accessible via les yum search et autre apt search … :)

            et pour visualiser il y a un graphite, et un grafana intégré, on peu pousser la config pour exporter vers un autre serveur pcp ou tout ce qu on veut.

            et pour les sondes temps réelles, il suffit de regarder avec vector, avec Brenda Greg comme dev entre autre, il s y connait en métrologie et perf :)

            lien de redhat ici et

  • # influxdb vs prometheus

    Posté par . Évalué à 7.

    N'hésite pas a nous faire part de tes commentaires après utilisation sur le moyen terme: Performances, maintenance …

    As-tu regardé Influxdb qui propose une full stack de monitoring (Telegraf, Chronograf, InfluxDB et Kapacitor ?

    J'aimerai beaucoup avoir des retours Influxdb vs Prometheus.

    • [^] # Re: influxdb vs prometheus

      Posté par (page perso) . Évalué à 3.

      Sur la partie performance, je peux déjà te faire un retour comme quoi c'est vraiment très performant. En tout cas bien moins consommateur en IO et CPU qu'une solution basée sur beats et Elasticsearch dans des conditions équivalentes. L'exploitation est également plus simple puisque pas besoin de purger, Prometheus se débrouille tout seul.

      Pour la suite, nous avons prévu d'étendre la couverture de l'outils ainsi qu'en augmentant la durée de rétention des données. Quand ça sera en place, j'essaierai de faire un petit retour sur ce que ça donne.

      Merci pour les informations autour de la stack InfluxDB. Je vais jeter un coup d'oeil pour voir ce que ça donne.

      Pour info, il existe des drivers permettant de stocker à l'extérieur de Prometheus les données collectées. Parmi les solutions, tu retrouves Influxdb. Une liste des solutions est disponible à l'adresse suivante : https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage

    • [^] # Re: influxdb vs prometheus

      Posté par (page perso) . Évalué à 2. Dernière modification le 31/01/18 à 20:47.

      J'ai mis en place Telegraf / InfluxDb / Grafana pour monitorer une dizaine de machines, il y a 3 semaines. C'est très facile à faire et pour l'instant ça marche très bien (utilisation sur un moniteur, alerting et en consultation ponctuelle par 4 personnes).

      En terme de perf, la VM (2 vcore / 8 Gb de Ram / ssd) est sous utilisées : le load (rapporté au nombre vcore dépasse très rarement 0.1). Je pense downgrader à une 1 vcore / 4 Gb ram / ssd.

    • [^] # Re: influxdb vs prometheus

      Posté par . Évalué à 1.

      dans le genre timeseries, le plus performant de ceux que j'ai testé c'est dalmatinerDB qui prend des millions des clés/valeurs par seconde sans broncher. Après prometheus et influxdb sont vraiment très bon et surtout quel que soit le choix, ils sont tous plus ou moins compatibles entre eux dans le sens où si un service à choisi prometheus et un autre service une autre solution, ce n'est pas très grave (par exemple dalmatiner supporte les formats Graphite, InfluxDB (http), Prometheus (including scraping), Metrics2.0, OpenTSDB) et sinon un grafana saura servir de frontend à ces bases "timeseries".

    • [^] # Re: influxdb vs prometheus

      Posté par . Évalué à 3.

      En ce qui me concerne j'ai rencontré une limitation avec InfluxDB sur la cardinalité des séries. En gros Influx stocke en mémoire des informations sur chaque série, ce qui pose problème (Out of Memory) avec un grand nombre de séries. Ils bossent dessus mais c'est pas encore mûre.

      Du coup je voulais savoir si des gens avait fait un switch Influx -> Prometheus (ou l'inverse) et ce qu'ils en pensaient.

      • [^] # Re: influxdb vs prometheus

        Posté par (page perso) . Évalué à 3.

        Pour ma part, je trouves la séparation collecteur / stockage de influx plus facile a appréhender que l'aspect bundle de prometheus.

        Influxdb pour le stockage avec une répartition des bases sur plusieurs serveurs. Netdata, jmxtrans, telegraf, collectd, whatelse pour la collecte. Grafana pour l'affichage, Kapacitor pour les alertes, c'est juste kiss.

        Le point surtout, c'est que c'est facile à faire vivre pas comme les trucs clic clic à l'API improbable lorsqu'elle existe…

        • [^] # Re: influxdb vs prometheus

          Posté par (page perso) . Évalué à 4.

          Influxdb pour le stockage

          Pourquoi Influxdb par rapport à Graphite ?

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: influxdb vs prometheus

      Posté par . Évalué à 3.

      Un des défauts de prometheus par rapport à influxdb c'est je crois qu'il ne supporte actuellement pas des rétentions longues des données. C'est dans la roadmap mais à priori pour l'instant t'aurais juste 1 mois de rétention, ce qui est rédhibitoire si tu veux faire du capacity planning à partir de l'outil.

  • # Article : problèmes de balisage

    Posté par . Évalué à 2.

    Requête pour les modérateurs. Il y a quelques soucis dans le Markdown de l'article. Les sections "Jobs Exporter" et "Web UI : découverte de Grafana" ne s'affichent pas très bien.

  • # Complémentaire à Nagios

    Posté par (page perso) . Évalué à 4.

    Je n'ai pas encore essayé. Pour moi ça semble plutôt complémentaire à Nagios dans le sens où c'est très orienté données numériques et qu'elles sont envoyées directement des machines supervisées.
    Nagios est au départ orienté test simple (les perfdata sont arrivées après) et plutôt par requête depuis l'extérieur de la machine supervisée.
    Vérifier que le serveur HTTP fonctionne bien est plus fiable en faisant une requête depuis l'extérieur qu'en lui demandant si il vas bien ;)
    Et superviser un matériel propriétaire tout intégré ne permettant pas d'installer de module supplémentaire dessus (exemple : un matériel réseau routeur, switch) ne semble pas super adapté pour Prometheus (ni nethdata, ni telegraph); il faut une machine de "polling"
    Mais à l'inverse devoir mettre du snmp pour superviser l'utilisation CPU/RAM, etc. c'est lourd (oui on peut faire autrement aussi heureusement)

    Une refonte de l'interface Nagios (Il faut vraiment que je teste sérieusement certains forks comme shinken) avec intégration des principes de ces outils avec agent et graphiques serait l'idéal.

    • [^] # Re: Complémentaire à Nagios

      Posté par (page perso) . Évalué à 3.

      De mon point de vue, Prometheus remplace complétement Nagios. La différence se trouve surtout dans son fonctionnement.

      Avec Nagios, la surveillance se fait au moment du lancement de la sonde. Les états SOFT/HARD permettront ensuite de savoir si - en cas d'erreur - le problème est transitoire ou s'il s'agit d'un vrai problème pour lequel on enverra un mail/notification SMS.

      Avec Prometheus, la notion d'alerte s'appuie sur les données collectées. En gros, le travail qui était auparavant réalisé par des sondes sur le serveur à surveiller se trouve au niveau du serveur de monitoring. Mais on peut ainsi très facilement écrire des choses s'appuyant sur des intervalles de temps (si l'erreur est là depuis 30 minutes par exemple). Avec Nagios, il faudrait attendre d'avoir eu 6 erreurs dans le cas d'une collecte toutes les 5 minutes. A noter que si jamais l'agent ne répond pas, une métrique sera alimentée indiquant que ce dernier est "down".

      Pour les équipements ne proposant que du SNMP, il est possible de passer par un exporter (tout comme il fallait passer par un plugin avec Nagios) Un article explique la mise en place d'une telle solution : https://www.robustperception.io/snmp-monitoring-with-prometheus/. A noter que cet exporter peut-être mutualisé pour la surveillance de plusieurs noeuds. Au niveau comportement, on est assez proche d'un cacti où on va venir collecter un sous-ensemble de l'arbre SNMP. Le bonus de Prometheus vient de sa capacité de pouvoir analyser après coup ces métriques et d'en faire des alertes sans avoir à les définir une à une dans Nagios. En bonus, on a de belles courbes qu'on peut récupérer dans Grafana et tout ça avec un seul outils.

  • # Forks de Nagios

    Posté par . Évalué à 6.

    Nagios et ses différents forks […] Nagios, PNP4Nagios et Cacti étaient clairement vieillots (avec ça, je vais me faire des amis) ;

    Par curiosité, quel(s) fork(s) utilisais-tu ? Centreon Engine est activement développé. Il me semble qu’Icinga et Shinken le sont aussi…

    Quel est l’intérêt de choisir Nagios, qui n’est pas libre, par rapport à l’un des moteurs de supervision compatible Nagios, libre ?

    J’ai un peu l’impression que quand les gens disent : « J’utilise Nagios », dans 99% du temps c’est l’un de ses forks. Le terme « Nagios » se retrouvant à désigner les conventions établi, le protocole en quelque sorte : signification des codes de retour, façon d’indiquer les intervalles, concept de SOFT/HARD, etc… plus que le logiciel en lui-même.

    Je me fais des idées fausses d’après-vous ? Nagios, le logiciel portant ce nom, a-t-il un nombre d’utilisateurs important ?

    • [^] # Re: Forks de Nagios

      Posté par (page perso) . Évalué à 5.

      La remarque est totalement valable je trouve, car en effet c'est plus un terme générique que de celui de son implémentation "historique".

      Après chacune a ses différences, mais si on mets de côté la partie configuration (qui se différencie de plus en plus avec le temps entre les outils), les utilisateurs finaux ne font plus la différence une fois devant leur interface.

      Surtout que la plupart des interfaces ne montrent que le sommet de l'iceberg, (juste host+service avec status et output, et c'est tout) sans trop chercher à faire comprendre les autres notions (rien que HARD/SOFT c'est important, et pourtant pas bien mis en valeur pour que tout le monde comprenne sans avoir lu une doc de 500 pages )

      Reste que ceux qui doivent administrer la plateforme de supervision eux font la différence, mais bon ils sont dans la mine, alors c'est pas visible, même si ça fait toute la différence sur le projet au final ^

  • # Choix des outils

    Posté par . Évalué à 6.

    Enfin, même si Beats d’Elastic est relativement intéressant, j’ai de plus en plus tendance à trouver Elasticsearch lourdaud et grand consommateur de ressource (grâce notamment à la légèreté de Java).

    Alors oui si ton besoin c'est de stocker des valeurs scalaires, c'est pas fait pour toi. Le principe d'elasticsearch c'est de faire des indexation fulltext très évolués pas des timeseries. L'objectif est de requêter des log. Le fait qu'il soit possible de stocker des données scalaires et un plus, mais pas l'objet du logiciel. Il faut comparer ELK à splunk ou greylog pas à nagios et ses confrères.

    Le format de cette base de données est spécifique (série temporelle ou time series dans la langue de Shakespeare) et diffère de celui qu’on pourrait retrouver dans une base de données classique (SQL ou NoSQL). En effet, les données collectées ont des caractéristiques connues :

    • collecte de métrique à intervalle connu (toutes les 60 secondes) ;
    • similarité des données d’une collecte sur l’autre (généralement, l’espace disque des partitions sur un serveur ne change pas).

    Du fait de ces caractéristiques, Prometheus compresse les données en mémoire et sur disque. Il en résulte une bien meilleure utilisation des ressources mémoire, processeur et disque.

    On trouve ça dans les bases NoSQL, c'est l'objectif des bases de données orienté colonne (et ce que tu présente ensuite est une base de données orienté colonne). Le principe étant de stocker par colonne et non par ligne pour permettre des optimisations importantes (celle que tu présente ou d'autres).

    • [^] # Re: Choix des outils

      Posté par (page perso) . Évalué à 2.

      Je suis d'accord avec toi, ELK est là pour faire de l'analyse de log. C'est plus beats d'ELK qui était visé par mon commentaire puisque je trouve que la mise en place de cet outils a un coût non négligeable. L'idée est de remonter que c'est une fausse bonne idée d'utiliser ELK pour faire de la collecte de métrique.

      Et merci pour ta remarque sur la notion de base de données orienté colonne.

  • # Gnocchi

    Posté par (page perso) . Évalué à 6.

    Prometheus fournit une stack complète, mais malheuresement elle ne propose aucune solution pour la haute disponibilité et le passage à l'échelle horizontal (scale out).

    Pour ceux qui s'intèressent à ce genre de problème et veulent stocker des métriques à grande échelle, je vous propose de jetter un œil à Gnocchi. J'ai par ailleurs écrit un petit article sur la différence des deux logiciels qui met en avant ce pour quoi ils peuvent être intéressant.

    À noter que la prochaine version de Gnocchi (4.2) offrira une couche de compatibilité Prometheus qui permettra de recevoir (mais pas de lire) des métriques au format Prometheus (émulation de l'API write de Prometheus).

  • # Quel taille de parc supervisé ?

    Posté par . Évalué à 2.

    Bonjour,

    je suis curieux de connaitre la taille des parcs que vous supervisez avec de tels solutions ?
    En terme de nombre d'équipements, diversité et nombres de services.

    A ceux qui utilisent ce type de solutions pourriez vous partager ces infos ? et surtout la facilité de maintenance de la solution, ajout de services personnalisé (genre surveiller une donnée non prévu par les développeurs) etc ..

    Merci

    • [^] # Re: Quel taille de parc supervisé ?

      Posté par (page perso) . Évalué à 2. Dernière modification le 12/03/18 à 23:05.

      Dans mon cadre pro nous avons 1 influxdb sur une machine t2.small (1 CPU 2Go de mémoire) qui absorbe les métriques provenant de 200 serveurs par datacenter. Chaque serveur fournit en moyenne 5000 métriques toutes les 10 minutes

      CNRS & UNIX-Experience

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.