Netdata sur Google Cloud Run

Netdata est un agent open source de supervision en temps réel de l'infrastructure et des applications, qui collecte des milliers de métriques par seconde et sert des tableaux de bord d'une granularité d'une seconde ainsi qu'une API REST. Ce module déploie Netdata sur Cloud Run v2 au-dessus du socle App_CloudRun, qui provisionne et gère l'infrastructure Google Cloud partagée.

Ce guide se concentre sur les services cloud qu'utilise Netdata et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toute application Cloud Run — identité du service, entrée et équilibrage de charge, mise à l'échelle et concurrence, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_CloudRun plutôt que de les répéter ici.

1. Vue d'ensemble

Netdata s'exécute dans un seul conteneur sur Cloud Run v2, à l'écoute sur le port 19999. Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	Cloud Run v2	Conteneur unique, 1 vCPU / 1 GiB par défaut ; écoute sur le port 19999
Base de données	Aucune	Netdata n'a pas de base de données SQL — les métriques sont stockées sur disque sous `/var/lib/netdata`
Stockage d'objets	Cloud Storage	Un bucket de données, monté comme volume GCS FUSE sur `/var/lib/netdata`
Cache et file d'attente	Aucun	Netdata n'utilise pas Redis (`enable_redis` est forcé à `false`)
Secrets	Secret Manager	`NETDATA_ADMIN_PASSWORD` de 32 caractères, généré par défaut (`enable_admin_password = true`)
Entrée	URL Cloud Run / Cloud Load Balancing	`all` par défaut — public ; une garde au moment du plan exige `enable_admin_password = true` en association

Valeurs par défaut judicieuses à connaître d'emblée :

Aucune base de données. Netdata est un agent autonome ; il n'y a ni instance Cloud SQL, ni job db-init, ni migration de schéma. database_type = NONE.
L'entrée est all (publique) par défaut, associée à un identifiant de mot de passe administrateur généré. Le tableau de bord de Netdata ne possède pas d'authentification intégrée ; une garde au moment du plan rejette donc ingress_settings = "all" sauf si enable_admin_password = true — les deux ont ces valeurs par défaut ensemble, de sorte qu'un nouveau déploiement passe le plan d'emblée.
Le tableau de bord n'est pas authentifié, quelle que soit la valeur de enable_admin_password. Cet indicateur (activé par défaut) génère seulement un NETDATA_ADMIN_PASSWORD stocké dans Secret Manager pour une couche d'authentification côté opérateur (reverse proxy / rattachement à Netdata Cloud) — il n'ajoute pas, à lui seul, de page de connexion au tableau de bord brut. Restreignez ingress_settings à internal ou placez le service derrière enable_iap si le tableau de bord exposé et non authentifié pose problème.
Une seule instance par défaut. min_instance_count = 1, max_instance_count = 1. Chaque instance Netdata détient sa propre base de métriques locale ; elle ne s'étend donc pas horizontalement vers un stockage partagé — conservez une seule instance.
Les métriques persistent dans un bucket GCS FUSE. /var/lib/netdata s'appuie sur un bucket Cloud Storage (enable_gcs_storage_volume = true), de sorte que la base de métriques survit aux redémarrages et aux événements de mise à l'échelle. Cela exige l'environnement d'exécution gen2.
Pas de Redis. enable_redis est explicitement désactivé ; Netdata n'a besoin d'aucun cache ni d'aucune file d'attente.
Le chemin de santé est /api/v1/info. Les sondes de démarrage et de vivacité interrogent ce point de terminaison, qui renvoie un corps JSON 200 une fois l'agent initialisé.
L'image est épinglée à une version via NETDATA_VERSION. application_version = "latest" est résolu en v2.2.6 au moment du build plutôt qu'en un wrapper latest inexistant.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que PROJECT et REGION sont définis. Les noms des services et des ressources figurent dans les sorties du déploiement.

A. Cloud Run — le service Netdata

Netdata s'exécute en tant que service Cloud Run v2 à l'écoute sur le port 19999. Chaque déploiement crée une révision immuable ; comme Netdata conserve ses métriques dans une base unique locale/adossée à GCS, il est normalement exécuté sur une seule instance plutôt qu'avec mise à l'échelle automatique.

Console : Cloud Run → sélectionnez le service pour voir les révisions, le trafic, les journaux et les métriques.

CLI :

gcloud run services list --project "$PROJECT" --region "$REGION" \
  --filter="metadata.name~netdata"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"
# Confirm the injected listener port / admin password env:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)'

Consultez App_CloudRun pour la mise à l'échelle, la concurrence, l'environnement d'exécution et la répartition du trafic.

B. Cloud Storage — persistance des métriques

Un bucket Cloud Storage dédié est provisionné et monté comme volume GCS FUSE sur /var/lib/netdata, où Netdata conserve sa base de métriques, son journal d'alarmes et son état de santé. L'historique de supervision persiste ainsi d'un redémarrage de révision et d'un redéploiement à l'autre. GCS FUSE exige l'environnement d'exécution gen2.

Console : Cloud Storage → Buckets.

CLI :

gcloud storage buckets list --project "$PROJECT" --filter="name~netdata"
gcloud storage ls gs://<data-bucket>/          # bucket name is in the Outputs

Consultez App_CloudRun pour GCS Fuse et les options CMEK.

C. Secret Manager

Par défaut (enable_admin_password = true), un unique secret de 32 caractères (secret-<prefix>-netdata-admin-password) est généré et injecté en tant que NETDATA_ADMIN_PASSWORD. Aucun autre secret applicatif n'est créé (il n'y a pas de mot de passe de base de données puisqu'il n'y a pas de base de données).

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~netdata-admin-password"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Consultez App_CloudRun pour les détails d'injection et de rotation.

D. Réseau et entrée

Par défaut, le service utilise ingress_settings = "all" (public) associé à enable_admin_password = true — la garde de validation du module exige l'indicateur de mot de passe dès que l'entrée vaut all, et les deux ont ces valeurs par défaut ensemble. Le tableau de bord lui-même n'a de toute façon pas de connexion intégrée ; pour un déploiement réellement verrouillé, définissez ingress_settings = "internal" (VPC uniquement) ou placez le service public derrière enable_iap / un équilibreur de charge HTTPS externe + une authentification basique. L'output netdata_url indique l'URL du service (port 19999).

Console : Cloud Run (URL du service) ; Network services → Load balancing.

CLI :

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

Consultez App_CloudRun.

E. Cloud Logging et Monitoring

Les journaux des conteneurs sont envoyés à Cloud Logging ; les métriques Cloud Run sont envoyées à Cloud Monitoring, avec un test de disponibilité facultatif (ciblant /api/v1/info) et des règles d'alerte.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Comportement de l'application Netdata

Aucune initialisation de base de données. Il n'y a ni job db-init ni migration de schéma. L'agent écrit sa base de métriques round-robin directement dans /var/lib/netdata (le volume GCS FUSE) au premier démarrage.
Persistance des métriques. L'historique de supervision ne survit aux redémarrages que parce que /var/lib/netdata s'appuie sur le bucket Cloud Storage. Si vous désactivez enable_gcs_storage_volume (ou si le bucket est vide), chaque nouvelle révision démarre avec une base de métriques vierge.
Tableau de bord non authentifié. Le tableau de bord local et l'API REST de Netdata sur le port 19999 n'ont pas de connexion intégrée, même si ingress_settings = "all" et enable_admin_password = true sont tous deux les valeurs par défaut du module. Définissez ingress_settings = "internal" ou placez un proxy d'authentification en amont si le tableau de bord exposé publiquement et non authentifié pose problème. enable_admin_password fournit un identifiant stable pour ce proxy / pour le flux de rattachement à Netdata Cloud — il ne verrouille pas à lui seul le tableau de bord brut.
Chemin de santé. Les sondes de démarrage et de vivacité ciblent /api/v1/info, qui renvoie un corps JSON 200 une fois l'agent initialisé. Vérifiez-le :
```
# from within the VPC (or after port-forwarding / LB):
curl -s "$NETDATA_URL/api/v1/info" | head
```
Fonctionnement sur une seule instance. Comme chaque instance possède sa propre base de métriques locale, conservez min_instance_count = max_instance_count = 1. Une extension horizontale produit des agents indépendants et non fédérés, et non un tableau de bord partagé.
Netdata Cloud (facultatif). Pour centraliser plusieurs agents, rattachez cette instance à Netdata Cloud après le déploiement (via un jeton de rattachement / des variables d'environnement de rooms) — une étape opérateur, non provisionnée par le module.

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à Netdata ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_CloudRun avec leur comportement standard.