Prometheus cherche à devenir une nouvelle génération dans les outils de code ouvert de monitorage. Une approche différente et sans héritage du passé.

Depuis des années, beaucoup d’outils de supervision ont été liés à Nagios par leur architecture et philosophie ou directement étant un fork complet (CheckMk, Centreon, OpsView, Icinga, Naemon, Shinken, Vigilo NMS, NetXMS, OP5 et d’autres).

Prometheus software, toutefois, est fidèle à l’esprit « Open » : si tu veux l’utiliser, tu devras rassembler plusieurs parties différentes.

D’une certaine manière, comme Nagios, vous pouvez dire que c’est une espèce d’Ikea du monitorage : vous pourrez faire avec elle beaucoup de choses, mais vous aurez besoin de rassembler vous-même les pièces et de lui consacrer beaucoup de temps.

Architecture Prometheus monitoring

Prometheus, écrit dans le langage de programmation go, a une architecture basée sur l’intégration de technologies tierces libres :

Prometheus kubernetes monitoring

Au contraire d’autres systèmes plus connus, qui ont aussi beaucoup de plugins et pièces pour présenter des cartes, Prometheus a besoin des tiers pour, par exemple, visualiser des données (Grafana) ou exécuter des notifications (Pagerduty).

Tous ces éléments de haut niveau peuvent être remplacés par d’autres pièces, mais Prometheus fait partie d’un écosystème, non seul outil. C’est pourquoi il a des exporters et pièces clé qui essentiellement sont d’autres projets open source :

  • HAProxy
  • StatsD
  • Graphite
  • Grafana
  • Pagerduty
  • OpsGenie
  • et beaucoup plus.

Voulez-vous surveiller vos systèmes gratuitement avec l’un des meilleurs logiciels de supervision qui existent ?

Pandora FMS, dans sa version Open Source, est gratuit pour toujours et pour le nombre d’appareils que vous voulez.

Nous vous donnons plus de détails ici :

Prometheus et les séries de données

Si RRD vous est familier, vous avez raison.

Prometheus est conçu comme un cadre de collecte de données avec une structure indéfinie (valeur clé), plutôt que comme un outil de supervision. Cela permet de définir une syntaxe pour son évaluation et donc de ne la stocker qu’en cas d’événement de changement. 

Prometheus ne stocke pas les données dans une base de données SQL.

Tout comme Graphite, qui fait quelque chose de similaire, comme d’autres systèmes d’une autre génération qui stockent des séries numériques dans des fichiers RRD, Prometheus stocke chaque série de données dans un fichier spécial. 

Si vous recherchez un outil pour collecter des informations à partir d’une base de données de séries temporelles (en anglais  » Time series database « ), vous devriez jeter un coup d’œil à OpenTSBD, InfluxDB ou Graphite.

À quoi sert Prometheus

Ou plutôt, à quoi Prometheus NE sert PAS.

Ils le disent eux-mêmes sur leur site Internet : si vous comptez utiliser cet outil pour collecter des logs, NE LE FAITES PAS, ils proposent à la place ELK.

Si vous souhaitez utiliser Prometheus pour superviser des applications, des serveurs ou des ordinateurs distants à l’aide de SNMP, vous pouvez le faire et générer de beaux graphiques avec Grafana, mais d’abord…

Configuration dans Prometheus

Toute la configuration du logiciel Prometheus se fait dans des fichiers texte YAML, avec une syntaxe assez complexe. De plus, chaque exportateur utilisé possède son propre fichier de configuration indépendant.

Avant une modification de la configuration, vous devez redémarrer le service pour vous assurer qu’il prend les modifications.

Rapports sur Prometheus

Par défaut, Prometheus monitoring n’a pas des types de rapport.

Vous devrez les programmer vous-même en utilisant leur API pour extraire les données.

Bien sûr, il existe des projets indépendants pour y parvenir.

Tableau de bord et écrans visuels

Pour avoir un tableau de bord dans Prometheus, vous devrez l’intégrer à Grafana.

Il existe une documentation sur la façon de le faire, puisque Grafana et Prometheus coexistent à l’amiable.

Évolutivité dans Prometheus

Si vous avez besoin de traiter plus de sources de données dans Prometheus, vous pouvez toujours ajouter plus de serveurs.

Chaque serveur traite sa propre charge de travail, car chaque serveur Prometheus est indépendant et peut fonctionner même si ses pairs tombent en panne. 

Bien entendu, il faudra « diviser » les serveurs par zones fonctionnelles pour pouvoir les différencier, pa exemple : « service A, service B ». Pour que chaque serveur soit indépendant. 

Cela ne semble pas être un moyen de « mise à l’échelle » tel que nous le comprenons, puisqu’il n’y a aucun moyen de synchroniser, de récupérer des données, il n’a pas de haute disponibilité ni de cadre d’accès commun aux informations sur les différents serveurs indépendants.

Mais comme nous l’avons prévenu au début, il ne s’agit pas d’une solution « fermée » mais d’un cadre pour concevoir votre propre solution finale.

Bien sûr, ne doutez pas que Prometheus est capable d’absorber beaucoup d’informations, dans un autre ordre de grandeur que d’autres outils plus connus.

Supervision des systèmes avec Prometheus : exporters et collecteurs

D’une manière ou d’une autre, chaque « façon » différente d’obtenir des informations avec cet outil nécessite un logiciel qu’ils appellent un « exporter ».

Il s’agit toujours d’un binaire avec son propre fichier de configuration YAML qui doit être géré indépendamment (avec son propre démon, fichier de configuration, etc.).

Ce serait l’équivalent d’un plugin dans Nagios.

Ainsi, par exemple, Prometheus a des exportateurs pour SNMP (snmp_exporter), des journaux de supervision (grok_exporter), etc.

Exemple de configuration d’un exportateur snmp en tant que service :

Prometheus monitoring exporter SNMP
SNMP de l’exportateur de supervision Prometheus

Pour obtenir des informations d’un hébergeur, on peut installer un « node_exporter » qui fonctionne comme un agent classique, similaire à Nagios.

Ces « node_exporter » collectent des métriques de différents types, dans ce qu’ils appellent des « collecteurs ».

Par défaut, Prometheus a des dizaines de ces collecteurs activés. Vous pouvez les consulter tous en naviguant jusqu’à  l’annexe 1 : collecteurs actifs.

Et, en plus, il existe de nombreux « exporters » ou plugins, pour obtenir des informations à partir de différents systèmes matériels et logiciels.

Bien que le nombre d’exportateurs soit pertinent (environ 200), il n’atteint pas le niveau des plugins disponibles pour Nagios (plus de 2000).

Voici un exemple d’exporter Oracle

Conclusion

L’approche de Prometheus en matière de monitorage moderne est beaucoup plus flexible que les outils plus anciens. Grâce à sa philosophie, nous pouvons l’intégrer plus facilement dans des environnements hybrides.

Cependant, il vous manquera des rapports, des tableaux de bord et un système de gestion de configuration centralisé.

C’est-à-dire une interface qui permet d’observer et de superviser des informations regroupées en services/hôtes.

Parce que Prometheus est un écosystème de traitement de données, pas un système de surveillance informatique typique.

Sa puissance en traitement de données est bien supérieure,, mais l’utilisation de ces données au quotidien la rend extrêmement complexe à gérer, car elle nécessite de nombreux fichiers de configuration, de nombreuses commandes externes distribuées, et tout doit être maintenu manuellement.

Annexe 1 : Collecteurs actifs sur Prometheus

Voici les collecteurs que Prometheus apporte en tant qu’actifs standard :

Ces « node_exporter » collectent des métriques de différents types, dans ce qu’ils appellent des « collectors », ce sont les collecteurs de séries qui sont activés :

arpExposes ARP statistics from /proc/net/arp.
bcacheExposes bcache statistics from /sys/fs/bcache/.
bondingExposes the number of configured and active slaves of Linux bonding interfaces.
btrfsExposes btrfs statistics
boottimeExposes system boot time derived from the kern.boottime sysctl.
conntrackShows conntrack statistics (does nothing if no /proc/sys/net/netfilter/ present).
cpuExposes CPU statistics
cpufreqExposes CPU frequency statistics
diskstatsExposes disk I/O statistics.
dmiExpose Desktop Management Interface (DMI) info from /sys/class/dmi/id/
edacExposes error detection and correction statistics.
entropyExposes available entropy.
execExposes execution statistics.
fibrechannelExposes fibre channel information and statistics from /sys/class/fc_host/.
filefdExposes file descriptor statistics from /proc/sys/fs/file-nr.
filesystemExposes filesystem statistics, such as disk space used.
hwmonExpose hardware monitoring and sensor data from /sys/class/hwmon/.
infinibandExposes network statistics specific to InfiniBand and Intel OmniPath configurations.
ipvsExposes IPVS status from /proc/net/ip_vs and stats from /proc/net/ip_vs_stats.
loadavgExposes load average.
mdadmExposes statistics about devices in /proc/mdstat (does nothing if no /proc/mdstat present).
meminfoExposes memory statistics.
netclassExposes network interface info from /sys/class/net/
netdevExposes network interface statistics such as bytes transferred.
netstatExposes network statistics from /proc/net/netstat. This is the same information as netstat -s.
nfsExposes NFS client statistics from /proc/net/rpc/nfs. This is the same information as nfsstat -c.
nfsdExposes NFS kernel server statistics from /proc/net/rpc/nfsd. This is the same information as nfsstat -s.
nvmeExposes NVMe info from /sys/class/nvme/
osExpose OS release info from /etc/os-release or /usr/lib/os-release
powersupplyclassExposes Power Supply statistics from /sys/class/power_supply
pressureExposes pressure stall statistics from /proc/pressure/.
raplExposes various statistics from /sys/class/powercap.
schedstatExposes task scheduler statistics from /proc/schedstat.
sockstatExposes various statistics from /proc/net/sockstat.
softnetExposes statistics from /proc/net/softnet_stat.
statExposes various statistics from /proc/stat. This includes boot time, forks and interrupts.
tapestatsExposes statistics from /sys/class/scsi_tape.
textfileExposes statistics read from local disk. The –collector.textfile.directory flag must be set.
thermalExposes thermal statistics like pmset -g therm.
thermal_zoneExposes thermal zone & cooling device statistics from /sys/class/thermal.
timeExposes the current system time.
timexExposes selected adjtimex(2) system call stats.
udp_queuesExposes UDP total lengths of the rx_queue and tx_queue from /proc/net/udp and /proc/net/udp6.
unameExposes system information as provided by the uname system call.
vmstatExposes statistics from /proc/vmstat.
xfsExposes XFS runtime statistics.
zfsExposes ZFS performance statistics.
Collecteurs actives par default dans Prometheus

Annexe 2: Exemple d’exportateur Oracle

Voici un exemple du type d’informations renvoyées par un exportateur Oracle, qui est appelé en configurant un fichier et une série de variables d’environnement qui définissent les informations d’identification et le SID :

  • oracledb_exporter_last_scrape_duration_seconds
  • oracledb_exporter_last_scrape_error
  • oracledb_exporter_scrapes_total
  • oracledb_up
  • oracledb_activity_execute_count
  • oracledb_activity_parse_count_total
  • oracledb_activity_user_commits
  • oracledb_activity_user_rollbacks
  • oracledb_sessions_activity
  • oracledb_wait_time_application
  • oracledb_wait_time_commit
  • oracledb_wait_time_concurrency
  • oracledb_wait_time_configuration
  • oracledb_wait_time_network
  • oracledb_wait_time_other
  • oracledb_wait_time_scheduler
  • oracledb_wait_time_system_io
  • oracledb_wait_time_user_io
  • oracledb_tablespace_bytes
  • oracledb_tablespace_max_bytes
  • oracledb_tablespace_free
  • oracledb_tablespace_used_percent
  • oracledb_process_count
  • oracledb_resource_current_utilization
  • oracledb_resource_limit_value

Pour avoir une idée de comment configurer un exportateur, voyons un exemple, avec un fichier de configuration d’exportateur JMX :

---
startDelaySeconds: 0
hostPort: 127.0.0.1:1234
username: 
password: 
jmxUrl: service:jmx:rmi:///jndi/rmi://127.0.0.1:1234/jmxrmi
ssl: false
lowercaseOutputName: false
lowercaseOutputLabelNames: false
whitelistObjectNames: ["org.apache.cassandra.metrics:*"]
blacklistObjectNames: ["org.apache.cassandra.metrics:type=ColumnFamily,*"]
rules:
  - pattern: 'org.apache.cassandra.metrics<type=(\w+), name=(\w+)><>Value: (\d+)'
    name: cassandra_$1_$2
    value: $3
    valueFactor: 0.001
    labels: {}
    help: "Cassandra metric $1 $2"
    cache: false
    type: GAUGE
    attrNameSnakeCase: false
Shares

Téléchargez gratuitement le rapport le plus complet sur la surveillance sécurisée d'IDG research.