Reprise du message précédent :

 
quelques exemples ?

Yes, un exemple. Je suis incapable de monitorier les boitiers "SDWAN" du client     Pas de SNMP, juste une API

D'équipements? Y'a plusieurs MP SCOM qui s'appuient sur les API REST des produits, par exemple pour les F5 BigIP ou pour Vmware. Ou évidemment pour le MP Azure qui supervise tout type de resources déployées à partir du moment où elle expose ses métriques via l'API Azure Monitor.  
 
J'en ai moi-même développé quelques-uns mais pour des logiciels plus que des équipements à proprement parler (SMA Opcon, RabbitMQ...)

Pour expliquer rapidement, ce qui se passe "sous le capot" dans SCOM quand tu crées une règle de supervision, c'est la création d'un workflow de supervision.
En gros, tu vas avoir source de données > filtrage > action (stockage de la métrique pour faire des graphiques, génération d'une alerte...)
Et en fait n'importe quoi peut être une "source de données" : il y a des modules natifs (journal d'évènement, log texte, compteur de perf dans perfmon, requête wmi...) mais tu peux aussi très bien exécuter n'importe quel binaire ou un script powershell de 12 000 lignes si ca te chante, ou même une dll custom à partir du moment où les données sont sorties dans le format "SCOM" (du XML avec une syntaxe propre).

Donc je fais un script powershell qui va requêter l'API et recracher toutes les données qui m'intéressent, et ensuite je crée les règles de supervision dont j'ai besoin et qui vont s'appuyer dessus

Qui peut le plus peut le moins : tu peux utiliser du snmp aussi, et créer tes plug-ins depuis ton noeud central pour faire du pull snmp (ou autre, je fais des tests de latence de services par exemple).

Après le gros intérêt c'est pas netdata tout seul mais c'est Prometheus et Grafana ensemble. Ça veut dire des métriques applicatives directement dans ton prometheus et Grafana pour exploiter (un seul dashboard pour tout).

Aussi notre Grafana sert à nos métriques business, même UI mais pour un backend ElasticSearch. Donc théoriquement, même de l'analyse de log via Logstash puis ES et exploitation Grafana. Tout en ayant Netdata pour les métriques OS.

Bref, ce sont de bonnes briques compatibles je trouve

 
et y en a pas qui "s'amusent" a rendre les MP payant dans le tas ?

Si, y'a des éditeurs qui les vendent, c'est le cas de Veeam pour le MP VMware ou de HYCU pour le MP F5 BigIp.
Vu leurs niveaux de complexité c'est pas volé, il y'a probablement quelques centaines de jours/homme de boulot notamment sur celui de Veeam. Y'a aussi un MP Vmware développé par la communauté mais c'est pas du tout le même niveau de détail!

On est cons aussi à vouloir payer la DIME pour un logiciel qui fait tout le boulot au lieu d'en associer 5

 
Si c'était Ikea like/trop compliqué/à la OpenStack j'en parlerai pas.
 
1. J'aime le libre mais j'ai horreur des trucs compliqués à installer et paramétrer
2. On fait des €€€ parce que c'est ce créneau qu'on occupe (XO et XCP-ng c'est très clef en main comparé à certaines solutions "concurrentes" )
3. Prometheus c'est 3 lignes de conf, Grafana c'est que de la web UI à paramétrer (et c'est bien fait), Netdata c'est un apt-get install. Donc franchement, c'est très en dessous d'un Nagios en terme de complexité (et pourtant Nagios et ses fichiers plats c'était pas pire). J'ai horreur des usines à gaz genre Centreon ou Zabbix.
 
Ce qui est bon c'est que ça reste des outils simples qui s'imbriquent assez facilement de manière dynamique
 
Mais oui, si ta du Windows, ça élimine Netdata (par contre il doit bien y avoir des trucs en push vers du Prometheus j'imagine dans le monde de MS )

Tu vois les TPE et les artisans pouvoir payer la DÎME toi ?

Y'a des potiers avec des clusters esxi ?

Plam, parler netdata sur un topic Windows voyons..

je taquinais, c'est finalement assez classique dans le monde de l'opensource et pas nécessairement mieux ou moins bien, juste très caractéristique
 
y'a l'air d'y avoir ce truc, wmi exporter : https://github.com/martinlindhe/wmi_exporter#collectors
je connaissais pas

Non mais c'est une remarque juste : ça pourrait être une usine à gaz (j'en ai connu !)

Et franchement ça va par rapport au service rendu. Grafana surtout c'est devenu très très chouette. La création d'alerte c'est vraiment simple et efficace !

Et Top Achat

 
https://github.com/netdata/netdata/issues/92
 
apparemment ca discute de ca pour un support de windows dans netdata.

Ouais j'étais tombé là dessus aussi, et du coup je m'étais dit qu'ils étaient en train de réinventer la roue et qu'ils iraient plus vite à décompiler quelques dll de scom pour voir comment MS le fait

A noter qu'ils sont bien réactif : on a contribué au support des métriques Xen, ça a été vite mergé/validé

reactif tout est relatif, l'issue a 4 ans

c'est pas tellement an issue là aussi faut dire, c'est plus a feature request.

 
Je parlais de celle sur Xen. Là on est dans la feature request majeure qui nécessite du boulot et qui n'est/était pas dans l'objectif de la boîte derrière
 

 
Voilà.

oui enfin écrire un pauvre service pour faire remonter les performance counters, vlà le boulot...

Sur un système pas POSIX avec une API merdique et fermée ?
Miam

alors qu'un .bat en tache planif doit pouvoir faire le taf

 
Bof. La seule difficulté ici, enfin le seul truc sur lequel il y a un peu de boulot, c'est de traduire les métriques récupérées de windows vers netdata pour qu'elles tombent dans les bonnes cases (je ne connais pas l'outil mais je suppose que tout le monde s'attend à ce que la charge cpu, par exemple, se récupère au même endroit et avec le même nom quel que soit le système cible). Le reste, en admettant qu'il soit relativement simple de poster vers netdata, ça doit être 2 ou 3 jours de boulot (en C).
 
Faut arrêter de se noyer dans un verre d'eau dès qu'il n'y a pas écrit POSIX dessus hein

 
Toi je sens que t'es le même genre de user qui nous dit que Xen Orchestra c'est juste des métriques récupérées d'un XenServer dans un thème boostrap
 
C'est pas parce qu'ici on conchie les devs qu'il faut être myope du boulot que représente l'intégration de features ou d'un outil complet

 
C'est tellement simple que personne ne s'en ai occupé  
 
C'est fou le nombre de problèmes qui seraient résolu si les adeptes du "c'est simple..." voulaient bien se donner un peu de peine.

Et tu les trouves où les métriques ? A la seconde ?

"Nan mais c'est facile, t'as même pas fait de développement"

Copyright de mon ancien "tuteur"

Je l'ai laissé se dépatouiller pour mettre l'active directory. J'en rigole encore

 
ben l'api est là: https://docs.microsoft.com/en-us/windows/win32/api/pdh/
 
T'as plusieurs manières de lire tout ce que tu veux selon tes envies (j'ai pas regardé en détail).
 
Après, c'est super compliqué dans le principe:
 

 
Dans la réalité, tu fais un thread pour la lecture des valeurs et un autre pour les pousser. Donc ça ressemble plutôt à ça au final:

 
Oulala, c'était compliqué
 
Pour toute la glue du service, je suis sûr que tu trouves des exemples tout fait (sinon c'est pas bien compliqué à coder non plus).

Et ?

'tain rsync qui n'a pas d'option pour que les filtres d'include/exclude soient case insensitive... faut pas faire les étonnés après quand on préfère payer la DIME

Ca passe pas avec une petite regex ?

Y'a de bonnes chances, si. M'enfin quand même  

 
ah tiens, encore mieux: ils ont écrit la fonction qui va bien pour que tu reçoives les métriques demandées à intervalle spécifié: https://docs.microsoft.com/fr-fr/wi [...] uerydataex
 
Il y a juste à copier-coller l'exemple et c'est torché

 
Merci   Reste à devenir sys ops barbu du scripting

mais tu cherches à le faire sous scom ou rien à voir? Si c'est scom on peut passer en mp pour plus de détails

Et c'est aussi pour ca qu'on aime payer la DIME

 
it was a joke

 
Mouais. Je suis pas ému, surtout que tu peux toujours mettre 0 si réellement ça te pose un problème
 
Sinon en cherchant 3 minutes, on tombe sur ça: https://docs.microsoft.com/fr-fr/wi [...] dfrom=MSDN
 
A savoir tout le squelette en C d'un service, écrit par Microsoft (mais c'est gratuit ).
 
Reste le commentaire sur github cité par Xat qui, à mon avis, n'a pas grande importance. Même en admettant que ce soit réellement un lock global, qu'un programme tiers puisse se démerder pour péter l'api en lockant trop souvent, c'est pas grave. Dans le fond ça emmerdera peut-être 3 utilisateurs et demi, pour lesquels quelqu'un trouvera une solution s'il a le temps.
 
Le seul truc désolant dans cette histoire, c'est qu'aucun utilisateur de cet outil ne fasse le petit développement qui va bien.