Skip to main content

À propos des métriques collectées

Les indicateurs Collectd constituent une solution de surveillance héritée pour les instances GitHub Enterprise Server, maintenue parallèlement à une préversion publique des indicateurs OpenTelemetry.

Les métriques collectées sont collectées par défaut et sont entièrement prises en charge dans cette version. Les mesures OpenTelemetry constituent la base future de la surveillance, qui seront disponibles à partir de GitHub Enterprise Server 3.18.

Remarque

Les métriques de Collectd doivent être en cours de clôture puis mis hors service dans une version ultérieure de GitHub Enterprise Server. Nous vous recommandons d’inclure, dans votre stratégie de surveillance à long terme, une migration vers les métriques OpenTelemetry. Consultez À propos des métriques OpenTelemetry.

À propos des métriques collectées

Collecté est un démon qui collecte régulièrement les statistiques de performances système et les stocke de différentes manières. Pour GitHub Enterprise Server, collectd collecte des indicateurs provenant de multiples composants et services du système, offrant ainsi une visibilité sur l’état et les performances de la plateforme.

Composants clés

La pile de surveillance collectd comprend les composants suivants :

  • Collectd : le démon principal qui collecte les statistiques de performance du système
  • Graphite : sert de source de données pour les visualisations de tableau de bord

Collecte de métriques

Collectd collecte des métriques à partir de différentes sources, notamment :

  • Métriques système : utilisation du processeur, utilisation de la mémoire, E/S disque, statistiques réseau
  • Métriques d’application : statistiques HAProxy, métriques de file d’attente resque, performances de la base de données
  • Métriques personnalisées : métriques spécifiques au service via des plug-ins et des scripts personnalisés

Architecture

Appareil unique

Dans un déploiement d’appliance unique, collectd s’exécute localement et stocke les métriques dans les fichiers RRD (Round Robin Database). Le Console de gestion lit ces fichiers pour afficher les tableaux de bord de surveillance.

Environnement de cluster

Dans les environnements de cluster, collectd fonctionne de manière distribuée.

  • Serveurs de métriques : nœuds désignés qui collectent et stockent des métriques à partir de tous les nœuds de cluster
  • Clients de métriques : tous les autres nœuds qui transfèrent leurs métriques aux serveurs de métriques
  • Redondance : les métriques sont répliquées sur plusieurs serveurs de métriques afin d’assurer la prise en charge du basculement

Configuration des métriques collectées

Les métriques collectées sont activées par défaut sur GitHub Enterprise Server instances.

Supervision externe avec collectd

Vous pouvez configurer des systèmes de supervision externes pour collecter et analyser les métriques collectées à partir de votre instance GitHub Enterprise Server. Cela permet l’intégration à l’infrastructure de supervision existante et fournit des fonctionnalités de visualisation et d’alerte supplémentaires.

Pour plus d’informations sur la configuration de la supervision externe, consultez Mise en place d’une surveillance externe avec collectd.

Informations de référence sur les métriques collectées

GitHub Enterprise Server collecte différentes mesures au moyen de collectd, couvrant les ressources système, les performances applicatives et l’état des services. La compréhension de ces métriques est essentielle pour la supervision et la résolution des problèmes efficaces.

Pour obtenir la liste complète des métriques disponibles, consultez Métriques collectées pour GitHub Enterprise Server.

Considérations relatives à la migration

À mesure que GitHub Enterprise Server évolue vers les indicateurs OpenTelemetry, prenez en considération les éléments suivants :

  • Coexistence : les métriques collectées et OpenTelemetry peuvent s’exécuter simultanément pendant la période de transition
  • Parité des fonctionnalités : les métriques OpenTelemetry fournissent des fonctionnalités de surveillance équivalentes et améliorées
  • Planification : Commencer à évaluer les métriques OpenTelemetry pour vos workflows de supervision
  • Calendrier : prévoyez l’éventuelle en cours de clôture, puis la mis hors service des métriques collectd dans les prochaines versions

Étapes suivantes