Métriques applicatives
Exporter les métriques applicatives vers Prometheus
Les métriques applicatives sont collectées grâce à Prometheus, un logiciel utilisé pour la surveillance d'événements et les alertes, qui permet de scraper les données capturées dans l'application.
L'exporteur Prometheus n'est pas pris en charge pour les embedded clusters.
Métriques disponibles
L'exporteur Prometheus donne accès aux métriques suivantes, regroupées par domaine.
Utilisateurs et incidents
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_active_users_total | Gauge | Tous les utilisateurs de l'instance | Aucune |
gim_issues_total | Gauge | Tous les incidents | Severity, Status |
gim_occurrences_total | Gauge | Toutes les occurrences | Hidden, Status |
Activité de scan
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_commits_total | Gauge | Commits traités | Account, Scan type |
gim_repo_scan_active_statuses_total | Gauge | Nombre de scans historiques | scan_feature, status |
gim_check_runs_created | Counter | Check runs GitHub créés | plan, account_id |
gim_check_runs_timed_out | Counter | Check runs GitHub expirés | plan, account_id |
gim_check_runs_runtime_bucket | Histogram | Durée des check runs GitHub | status |
gim_check_runs_error_codes | Counter | Erreurs des check runs GitHub par code | error_code |
Infrastructure
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_postgres_used_disk_bytes | Gauge | Espace disque utilisé par PostgreSQL | Aucune |
gim_redis_used_memory_bytes | Gauge | Mémoire utilisée par Redis | Aucune |
gim_redis_available_memory_bytes | Gauge | Mémoire disponible pour Redis | Aucune |
Workers et files d'attente Celery
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_celery_queue_length | Gauge | Tâches en attente dans la file | queue_name |
gim_celery_active_consumer_count | Gauge | Consommateurs actifs dans la file du broker | queue_name |
gim_celery_worker_tasks_active | Gauge | Tâches en cours de traitement | Aucune |
gim_celery_task_sent_total | Counter | Tâches envoyées à une file | name, queue_name, team |
gim_celery_task_started_total | Counter | Tâches démarrées par un worker | name, queue_name, team |
gim_celery_task_succeeded_total | Counter | Tâches terminées avec succès | name, queue_name, team |
gim_celery_task_failed_total | Counter | Tâches en échec | name, exception, queue_name, team |
gim_celery_task_retried_total | Counter | Tâches réessayées | name, queue_name, team |
gim_celery_task_queue_time_bucket | Histogram | Temps passé en attente dans la file | name, queue_name, team |
gim_celery_task_runtime_bucket | Histogram | Durée d'exécution des tâches | name, queue_name, team |
Requêtes HTTP
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_http_request_started_total | Counter | Requêtes HTTP initiées | api, method, view_name |
gim_http_request_success_total | Counter | Requêtes HTTP réussies | api, method, view_name |
gim_http_request_failure_total | Counter | Requêtes HTTP en échec | api, method, status_code, view_name |
gim_http_request_exception_total | Counter | Requêtes HTTP ayant levé une exception | api, method, view_name, exception |
gim_http_request_view_duration_seconds | Histogram | Durée des requêtes HTTP par vue | api, method, view_name |
Contrôles de santé
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_health_check_result_count | Gauge | Résultats des contrôles de santé | service_name, status |
gim_outdated_health_check_count | Gauge | Contrôles de santé plus anciens que l'intervalle périodique | service_name |
gim_health_check_skipped_total | Counter | Contrôles de santé ignorés | reason, service_name |
gim_health_check_duration_metric | Histogram | Durée d'exécution des contrôles de santé | service_name |
Tâches périodiques
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_periodic_task_period_seconds | Gauge | Périodicité attendue d'une tâche | task_name, queue_name |
gim_periodic_task_not_run_for_seconds | Gauge | Temps écoulé depuis la dernière exécution d'une tâche | task_name, queue_name |
API publique
| Métrique | Type | Description | Dimensions |
|---|---|---|---|
gim_public_api_quota_total | Gauge | Utilisation maximale autorisée de l'API | Account |
gim_public_api_usage_total | Gauge | Utilisation actuelle de l'API | Account |
gim_public_api_token_total | Gauge | Tokens d'API actifs | Account, Type |
Surveillance recommandée
Santé du système
| Métrique | Ce qu'il faut surveiller |
|---|---|
gim_celery_queue_length | L'augmentation du backlog de la file au fil du temps est le premier signe de saturation du système. |
gim_celery_active_consumer_count | Une baisse du nombre de workers signale des problèmes de disponibilité. |
gim_postgres_used_disk_bytes | Surveillez la pression sur le disque avant qu'elle ne devienne critique. |
gim_redis_used_memory_bytes / gim_redis_available_memory_bytes | Un ratio élevé indique une pression sur la mémoire du cache. |
gim_periodic_task_not_run_for_seconds | Comparez avec gim_periodic_task_period_seconds pour détecter les tâches bloquées. |
API et intégrations
| Métrique | Ce qu'il faut surveiller |
|---|---|
gim_http_request_failure_total | Filtrez par status_code pour repérer les pics de taux d'erreur (en particulier les 5xx). |
gim_http_request_view_duration_seconds | Suivez la latence de l'API (P95/P99) pour détecter les ralentissements. |
gim_health_check_result_count | Filtrez par status=not_ok pour détecter les intégrations défaillantes. |
Exemples de requêtes PromQL
# Celery queue saturation (tasks per worker)
gim_celery_queue_length / gim_celery_active_consumer_count
# HTTP 5xx error rate over the last 5 minutes
rate(gim_http_request_failure_total{status_code=~"5.."}[5m])
# API latency P95 over the last 5 minutes
histogram_quantile(0.95, rate(gim_http_request_view_duration_seconds_bucket[5m]))
# Redis memory utilization (%)
gim_redis_used_memory_bytes / (gim_redis_used_memory_bytes + gim_redis_available_memory_bytes) * 100
# Detect stalled periodic tasks (not run for 2x their expected period)
gim_periodic_task_not_run_for_seconds > 2 * gim_periodic_task_period_seconds
Exemples de règles d'alerte
Voici des règles d'alerte Prometheus de départ que vous pouvez adapter à votre environnement :
groups:
- name: gitguardian
rules:
- alert: CeleryQueueBacklog
expr: gim_celery_queue_length > 100
for: 5m
annotations:
summary: "Queue {{ $labels.queue_name }} has {{ $value }} pending tasks"
- alert: RedisMemoryPressure
expr: >
gim_redis_used_memory_bytes
/ (gim_redis_used_memory_bytes + gim_redis_available_memory_bytes) > 0.85
for: 10m
- alert: PeriodicTaskStalled
expr: gim_periodic_task_not_run_for_seconds > 2 * gim_periodic_task_period_seconds
for: 5m
- alert: HighHTTPErrorRate
expr: rate(gim_http_request_failure_total{status_code=~"5.."}[5m]) > 0.1
for: 5m
Visualiser les métriques avec Grafana
GitGuardian ne fournit pas de tableaux de bord Grafana préconstruits, mais toutes les métriques gim_* sont des métriques Prometheus standard et fonctionnent avec n'importe quelle instance Grafana connectée à votre serveur Prometheus.
Pour commencer :
- Ajoutez votre serveur Prometheus en tant que source de données Grafana.
- Créez des panneaux à l'aide des requêtes PromQL ci-dessus.
- Organisez les panneaux en lignes : System health (files d'attente, Redis, Postgres, tâches périodiques) et API & Integrations (taux d'erreur, contrôles de santé).
Activer ou désactiver les métriques applicatives
Les métriques applicatives sont désactivées par défaut. Deux étapes sont nécessaires pour activer les métriques applicatives :
- autoriser la collecte des métriques par l'application
- activer l'export Prometheus
Autoriser la collecte des métriques
Pour autoriser la collecte des métriques, vous devez vous rendre dans la section Preferences
de l'Admin Area, cocher le feature flag prometheus_metrics_active et
enregistrer les paramètres.
Pour la désactiver, vous devez décocher ce paramètre et enregistrer les paramètres.
Installer Prometheus Operator
Les métriques sont collectées par Prometheus à l'aide du Prometheus Operator.
Pour les Existing Clusters, vous devez l'installer manuellement (documentation d'installation).
Activer l'export Prometheus avec KOTS
Pour créer les ressources d'exportation et permettre la découverte automatique, vous devez vous rendre dans la KOTS Admin Console et cocher la case Activate Prometheus Exporter dans la section Prometheus de la section de configuration.
Enregistrez ensuite la configuration, puis Deploy l'application pour appliquer la nouvelle configuration.
Pour la désactiver, vous devez décocher ce paramètre, enregistrer la configuration et l'appliquer via un nouveau déploiement.
Activer l'export Prometheus avec Helm
L'exporteur de métriques applicatives peut être activé en définissant observability.exporters.webAppExporter.enabled=true dans le fichier values.
observability:
exporters:
webAppExporter:
enabled: true
Veuillez noter que l'application Helm propose également un Celery Exporter permettant de surveiller plusieurs métriques Celery comme le « nombre de tâches actives par file ». La liste complète des métriques est disponible ici.
Vous pouvez activer le Celery Exporter dans votre fichier values :
observability:
exporters:
webAppExporter:
enabled: true
statefulAppExporter:
enabled: true
Si vous utilisez Prometheus Operator, vous pouvez utiliser le Service Monitor fourni pour la découverte automatique de l'exporteur par Prometheus :
observability:
exporters:
webAppExporter:
enabled: true
statefulAppExporter:
enabled: true
serviceMonitors:
enabled: true
Sinon, vous pouvez scraper les exporteurs manuellement.
- Les métriques applicatives peuvent être scrapées depuis le service app-exporter à :
http://app-exporter:9808/metrics - Les métriques Celery peuvent être scrapées depuis le service celery-exporter à :
http://celery-exporter:9808/metrics
Comment collecter les métriques
Sur les Existing Clusters, Prometheus doit être installé et configuré manuellement. Si l'Operator Kube-Prometheus est utilisé, toutes les métriques applicatives seront automatiquement listées grâce au service de découverte de l'Operator Kube-Prometheus.
Sinon, une configuration manuelle peut être nécessaire.
La découverte des métriques applicatives est possible via le service headless app-monitoring.
Ce service expose un pod exporter servant les métriques à http://exporter-xxxxx-xxxxx:9808/metrics
Données d'utilisation
GitGuardian collecte des données d'utilisation pour améliorer l'expérience utilisateur et le support. Elle peut être facilement désactivée en
ajustant le paramètre custom_telemetry_active situé dans la section preferences
de l'Admin Area.
Pourquoi conserver les données d'utilisation activées ?
-
Amélioration continue du produit : les données d'utilisation nous aident grandement à comprendre comment notre application est utilisée dans divers environnements. Cela nous permet de cibler spécifiquement les domaines nécessitant des améliorations et d'orienter nos efforts de test. Cela garantit que notre produit évolue pour répondre efficacement aux besoins de nos utilisateurs tout en contribuant à une meilleure qualité et stabilité.
-
Support ciblé et efficace : en cas de problèmes techniques, les données d'utilisation permettent à GitGuardian d'identifier et de résoudre les problèmes beaucoup plus rapidement. Cela signifie une réduction des temps d'arrêt pour vous et une meilleure expérience utilisateur globale.
-
Sécurité et confidentialité : nous tenons à vous rassurer sur le fait que la confidentialité et la sécurité des données sont notre priorité absolue. Nous ne collectons aucune donnée personnelle ou sensible. Notre objectif est uniquement d'améliorer l'expérience utilisateur et les performances de notre produit.
Voici les catégories et métriques que nous collectons :
-
Replicated
- Diverses métriques liées au déploiement telles que l'état du cloud, la version et le temps de fonctionnement
-
System
- Fournisseur SSO
- Type de passerelle réseau
- État de la CA personnalisée et du proxy
- État d'activation des métriques applicatives Prometheus
-
Users & Teams
- Nombre d'invités en attente, d'utilisateurs enregistrés avec différents niveaux d'accès, d'utilisateurs actifs.
-
Billing
- Nombre de développeurs contributeurs comptabilisés dans votre licence, et le nombre exclu du décompte
- Les deux mêmes décomptes ventilés par type de VCS (Azure DevOps, Bitbucket Cloud, Bitbucket Data Center, Gerrit, GitHub, GitHub Enterprise, GitLab)
Il s'agit de décomptes agrégés d'adresses e-mail distinctes d'auteurs de commits. Les adresses e-mail elles-mêmes ne sont jamais transmises.
-
Historical Scan
- Nombre de scans historiques annulés, échoués et terminés
- Durées par percentile des scans historiques
- Nombre de secrets trouvés par jour et de scans de sources par jour dans les scans historiques
- Nombre de scans historiques considérés comme trop volumineux
-
Integrations
- Nombre d'instances, d'installations, de projets, de sites pour les VCS et autres sources de données
- Nombre de sources surveillées et non surveillées, ainsi que les percentiles de taille des sources et les utilisateurs estimés par VCS
-
Secret
- Nombre de détecteurs désactivés par catégorie, retours enregistrés et non enregistrés, et diverses métriques liées aux vérifications de validité des secrets et aux incidents
-
Public API
- Nombre d'appels pour les scans de secrets ggshield, y compris les différents modes et dépôts
- Nombre de tokens d'accès personnels et de comptes de service actifs
- Nombre d'appels à l'API publique
