Monitoring des VM hébergeant les services

Lors de cette TX, nous voulions avoir une remontée d’information centralisée de l’état de nos machines afin de nous rendre compte de la charge ou non de celle-ci. Comme le temps nous a manqué, la solution retenue a été la mise en place d’une solution metricbeat, couplée à un moteur de recherche elasticsearch et au client kibana pour visualiser les données. En l’état actuel, cela fonctionne et il est possible d’avoir des informations sur l’état des machines via l’URL suivante.
Cette solution nécessiterait que l’on se penche dessus afin de sécuriser l’accès au Kibana par exemple. Une solution de véritable monitoring est aussi à envisager avec le déploiement d’une solution comme checkmk par exemple.

Afin de remonter les information, nous utilisons donc la solution MetricBeat. C’est un produit open source développé par la société Elastic et qui permet de remonter des informations sur l’état des machines (nombre de processus, mémoire utilisée, système de fichier …). En sortie, ce MetricBeat est configuré pour envoyer ses données vers le moteur de recherche Elasticsearch. Il stocke et indexe les données chaque jour et permet de requêter ces données via une API REST ou via l’interface web Kibana.

Le fichier de configuration se trouve dans /etc/metricbeat/metricbeat.yml

root@hostname:~# cat /etc/metricbeat/metricbeat.yml  | grep -v '#' | grep -v '^$'
metricbeat.modules:
- module: system
  metricsets:
    - cpu
    - load
    - diskio
    - filesystem
    - fsstat
    - memory
    - network
    - process
  enabled: true
  period: 10s
  processes: ['.*']
name: hostname
output.elasticsearch:
  hosts: ["localhost:9200"]

Comme on peut le voir ci-dessus, on remonte toutes les métriques et on les envoie en output vers un elasticsearch sur le port 9200. En effet, afin de sécuriser l’Elasticsearch et d’empêcher des écritures depuis n’importe où, nous avons effectué une redirection SSH depuis le serveur de monitoring vers les machines hébergeant les services.
Un utilisateur ssher à été instancié sur la machine de monitoring. Les clés de pica01 et pica02 ont été ajoutées à cet utilisateur ce qui permet de se connecter sans mot de passe. Ensuite, on lance la commande suivante.

ssh -nNT -f -L9200:127.0.0.1:9200 ssher@monitoring.picasoft.net

Cette commande ouvre une session distante sur le serveur de monitoring avec le user ssher et redirige le port 9200 de la machine de monitoring vers le port 9200 de la machine locale.

Pour s’assurer que cette connexion reste ouverte en permanence, nous avons installé autossh. Cela permet de rouvrir le pont ssh si jamais la connexion a été coupée. On le lance avec la commande:

autossh -M 0 -N -f -L9200:127.0.0.1:9200 ssher@monitoring.picasoft.net

Il ne faut pas oublier de l’ajouter dans le /etc/rc.local pour le lancer au démarrage du serveur.

Les données sont donc stockées dans le moteur de recherche Elasticsearch. Comme sur toute la plateforme, celui-ci est lancé dans un conteneur Docker. Au contraire de pica01/02, la machine de monitoring n’utilise pas swarm pour faire tourner ces conteneurs. Comme pour pica01/02, la configuration docker se trouve dans le /DATA.
Du fait que l’on utilise pas swarm, on peut utiliser docker-compose pour orchestrer et lancer nos conteneurs:

version: '2'

services:
  elasticsearch:
    image: elasticsearch
    ports:
      - "127.0.0.1:9200:9200"
      - "127.0.0.1:9300:9300"
    environment:
      ES_JAVA_OPTS: "-Xms4g -Xmx4g"
    volumes:
      - /DATA/elasticsearch/data:/DATA/elasticsearch/data
      - /DATA/elasticsearch/config/elasticsearch.yml:/DATA/elasticsearch/config/elasticsearch.yml
    networks:
      - docker_elk
  kibana:
    image: kibana
    volumes:
      - /DATA/kibana/config/kibana.yml:/etc/kibana/kibana.yml
    networks:
      - docker_elk
    depends_on:
      - elasticsearch
      - traefik
    ports:
      - 5601:5601
networks:
  docker_elk:
    driver: bridge

Le service Elasticsearch est bien exposé sur le 127.0.0.1:9200/9300 pour éviter que celui-ci ne soit accessible depuis l’extérieur via l’IP publique. On ne peut donc attaquer l’Elasticsearch que depuis la machine locale ou depuis des redirections SSH.
Pour faire du nettoyage dans les données qui sont stockées au sein de l’Elasticsearch, nous utilisons l’outil curator lui aussi développé par Elastic. Il permet de lister et de faire des actions sur des index. Ce qui nous intéresse ici, c’est de supprimer les données plus vieilles de 3 jours afin de ne pas saturer l’espace de stockage sur la machine de monitoring. Pour cela, on créé une cron qui lance la commande suivante:

root@monitoring:/DATA/elasticsearch# cat /etc/cron.daily/remove-elasticsearch-index
#!/bin/bash

/usr/bin/curator_cli --host localhost --port 9200 delete_indices --filter_list '[{"filtertype":"age","source":"name","direction":"older","unit":"days","timestring": "%Y.%m.%d","unit_count":3},{"filtertype":"pattern","kind":"prefix","value":"metricbeat"}]'

Cette commande permet donc à curator de lister les index plus vieux de 3 jours en se basant sur le nom de l’index et de les supprimer.

Ce système fonctionne bien et il a l’avantage de se mettre en place très rapidement. En revanche, il n’est pas en mesure de lever des alertes en cas de problèmes. Une solution de monitoring complète permettrait d’avoir plus d’informations sur les machines et de notifier les administrateurs en cas d’anomalies.
— Antoine Picasoft 2016/12/21 12:11