[ElasticStack / MetricBeat] Projet d'Inventaire, Monitoring et scheduler

Bonjour,

(désolé pour ce long post!)
J'ai déjà ouvert un post sur developpez.net pour un projet qui consiste la mise en place d'un Agent qui doit faire l'inventaire, le monitoring et servir de tasks scheduler sur chaque machine (en stockant les donnés).

Un de vos collaborateurs m'a conseillé Elastic, en cherchant j'ai trouvé ElasticStack (anciennement Elk ?) qui me semble intéressant mais ne réponds pas totalement à nos besoins : ce "package" ne se charge que notre aspect Monitoring, donc nous devrons tout de même développer un agent pour l'inventaire et la plannification des tâches.

J'ai tou de même regarder (pas testé en pratique) quelques produits :
Kibana : Nous avons déjà une interface web sur laquelle nous souhaitons intégré notre nouveau système pour garder centralisé ce qui concerne notre support

MetricBeat : j'ai regardé avec la démo Kibana. Cette partie monitoring me semble complet, mais nous souhaitons que notre agent (qui sera développé en nodeJS) garde la main, j'ai donc quelques questions :

  1. Comment notre Agent pourra pourra-t-il utiliser les données que MetricBeat collecte ? Pourra-t-il "l'écouter" ? Ou devra-t-il les récupérer à un endroit ou MetricBeat les aura stocké au préalable ?
  2. Notre agent pourra-t-il avoir la main sur le paramétrage de MetricBeat ? (par exemple changer son intervalle de "scan" ?)
  3. sur la démo dans DashBoard -> [Metricbeat System] Overview ECS, je ne vois pas d'info sur les volumes, juste sur le total de disque. Est-ce possible d'avoir l'espace restant pour chaque volume ?
  4. Notre agent sera un setup d'installation (.exe, [...] cross-platform), est-ce que l'installation de MetricBeat sur chaque machine devra se faire en plus de notre agent ? Ou puis-je espérer pouvoir "intégrer" son installation ?

ElasticSearch : j'ai regardé la doc notamment la modélisation des données (sans tester en pratique pour l'instant). Nos données seront toutes liées (elle se rapporte toutes à une et même machine) donc je penses que Nested Object est la meilleure solution, en revanche nous souhaitons pouvoir récupérer seulement une partie du document ce qui n'est pas possible avec Nested Object

Niveau DB nous souhaitons :

  • pouvoir historiser toutes les valeurs entrantes (chaque tâche pouvant en amener)
  • en optimisant l'espace qu'occupera la base
  • en ayant des réponses rapide aux requêtes
  • avec une structure "changeante" : chaque tâche doit pouvoir enregistrer ses propres données, que je ne peux pas réellement connaitre à l'avance
  • pouvant supporter un potentiel gros trafic : chaque tâche de chaque machine (peut-être lancée toutes les 15 minutes) est potentiellement un INSERT ou UPDATE sans ralentir les autres machines

ElasticSearch vous semble-t-il pouvoir correspondre à mes besoins ? Ou devrai-je plutôt regarder du côté MongoDB/NoSQL/PostGré ?

Je vais essayer de mettre en place unedémo locale pour essayer tout ça, je suppose que :

  • je dois installer et configurer ElasticSearch (dans un container sur une machine?)
  • je dois installer et configurer Kibana (dans un autre container sur la même machine qu'ElasticSearch ?)
  • je peux installer et configurer MetricBeat sur un autre poste ?

Merci d'avance à tous ceux qui ont lu ! :slight_smile:

Bonjour,

J'ai parcourus la discussion sur developpez.net, Je pense que le plus simple c'est effectivement d’après les besoins listés, Metricbeat est ce qu'il faut. Pour l'inventaire et le monitoring, par contre pour le tasks scheduler, faudra développer quelque chose.

Je ne comprends pas trop le choix:

mais nous souhaitons que notre agent (qui sera développé en nodeJS) garde la main

ça me semble plus un choix politique qui risque de compliquer les choses sur le long terme, sachant que l’équipe d'elastic pond une version presque tous les mois avec beaucoup de nouveautés et d’améliorations et vous serez suffisamment occupées à améliorer votre système plutôt que de maintenir un agent qui duplique des choses existantes.
Quand je dis "améliorer votre système ", je veux dire vous concentrer sur les problèmes réseaux et non pas maintenir un nouvel outils pour monitorer.
[Fin de l'avis perso]

Pour les questions sur metricbeats je pense qu'il vaux mieux essayer et voir les limites et comme j'ai dit plus haut les équipes de développeur sont très réactives et vos besoins pourront peut être aider à améliorer le produit ou faire votre propre fork.

Les contraintes listées dans

sont toutes couvertes et même plus.

Le plus simple pour tester c'est de suivre ce tuto:
https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-docker.html

En relisant mon post j'ai l'impression d’être un elastic fan boy.... :sweat_smile: désolé pour le parti pris, mais lire ces blogs peut aussi aider à devenir fan boy voir d'autres cas d'utilisation, plus similaire au votre.
https://www.elastic.co/blog/category/user-stories

En espérant avoir apportés quelque chose au débat.

1 Like