Construire un agent IA pour monitorer son infrastructure GCP
Votre infrastructure GCP génère des milliers d’événements par heure. Cloud Monitoring les collecte. Vertex AI peut les interpréter. Et un petit agent Python peut faire le lien — sans dashboard, sans ticket, sans réunion.
Voici comment construire en 30 minutes un agent qui surveille, triage et vous notifie quand quelque chose mérite vraiment votre attention.
Le problème réel
Les alertes classiques souffrent de deux défauts inverses : trop nombreuses (on les ignore) ou trop tardives (le problème est déjà là). La cause profonde : elles répondent à des seuils statiques, pas au contexte.
Un CPU à 85% sur un GKE node un dimanche matin à 3h et le même CPU à 85% pendant un batch de fin de mois — ce n’est pas le même signal.
Un LLM peut faire cette distinction. Un seuil ne peut pas.
Architecture en 4 composants
Cloud Monitoring → Cloud Functions → Vertex AI (Gemini) → Notifications
(métriques) (déclencheur) (analyse) (Slack / PagerDuty)
1. Cloud Monitoring collecte les métriques (CPU, mémoire, latence, erreurs 5xx, coûts).
2. Cloud Functions s’exécute sur un trigger Pub/Sub toutes les 15 minutes. Elle récupère les dernières anomalies via l’API Monitoring.
3. Vertex AI (Gemini Flash) reçoit un contexte structuré — métriques, historique 7 jours, heure, environnement — et retourne une analyse en JSON : sévérité, cause probable, action recommandée.
4. La notification n’est envoyée que si la sévérité est ≥ MEDIUM. Fini les alertes pour rien.
Le code essentiel
La Cloud Function en Python :
import functions_framework
import vertexai
from vertexai.generative_models import GenerativeModel
from google.cloud import monitoring_v3
import json, datetime
PROJECT_ID = "votre-projet"
LOCATION = "europe-west1"
@functions_framework.http
def analyze_infrastructure(request):
# 1. Récupérer les anomalies des dernières 15 min
metrics = get_recent_anomalies(PROJECT_ID)
if not metrics:
return "nothing to analyze", 200
# 2. Appel Gemini Flash (modèle rapide, coût minimal)
vertexai.init(project=PROJECT_ID, location=LOCATION)
model = GenerativeModel("gemini-1.5-flash-002")
prompt = build_prompt(metrics)
response = model.generate_content(
prompt,
generation_config={"response_mime_type": "application/json"}
)
analysis = json.loads(response.text)
# 3. Notifier seulement si pertinent
if analysis.get("severity") in ("MEDIUM", "HIGH", "CRITICAL"):
send_notification(analysis)
return json.dumps(analysis), 200
def build_prompt(metrics: list) -> str:
context = json.dumps(metrics, indent=2, ensure_ascii=False)
now = datetime.datetime.utcnow().isoformat()
return f"""Tu es un SRE senior spécialisé GCP. Analyse ces métriques d'infrastructure.
TIMESTAMP: {now}
MÉTRIQUES ANORMALES:
{context}
Réponds UNIQUEMENT en JSON avec ce schéma:
{{
"severity": "LOW|MEDIUM|HIGH|CRITICAL",
"summary": "Une phrase, max 120 caractères",
"root_cause": "Cause probable en 2-3 phrases",
"recommended_action": "Action immédiate concrète",
"false_positive_probability": 0.0-1.0,
"context_notes": "Éléments de contexte pertinents (heure, pattern connu, etc.)"
}}
Règles:
- Si false_positive_probability > 0.7 → severity = LOW
- Sois conservateur : mieux vaut un faux négatif qu'une alerte inutile
- Tiens compte de l'heure UTC pour contextualiser (batch de nuit, heures creuses, etc.)"""
Détecter les anomalies sans seuils statiques
Au lieu de « alerte si CPU > 80% », on utilise l’écart-type :
from google.cloud import monitoring_v3
from datetime import datetime, timedelta
def get_recent_anomalies(project_id: str) -> list:
client = monitoring_v3.MetricServiceClient()
project_name = f"projects/{project_id}"
now = datetime.utcnow()
interval = monitoring_v3.TimeInterval({
"end_time": now,
"start_time": now - timedelta(hours=1),
})
metrics_to_check = [
"compute.googleapis.com/instance/cpu/utilization",
"run.googleapis.com/request_latencies",
"cloudsql.googleapis.com/database/memory/utilization",
]
anomalies = []
for metric_type in metrics_to_check:
results = client.list_time_series(
request={
"name": project_name,
"filter": f'metric.type="{metric_type}"',
"interval": interval,
"view": monitoring_v3.ListTimeSeriesRequest.TimeSeriesView.FULL,
}
)
for series in results:
points = [p.value.double_value for p in series.points]
if len(points) < 3:
continue
mean = sum(points) / len(points)
std = (sum((x - mean)**2 for x in points) / len(points)) ** 0.5
last = points[0]
# Anomalie = dernier point à plus de 2σ de la moyenne récente
if std > 0 and abs(last - mean) > 2 * std:
anomalies.append({
"metric": metric_type,
"resource": dict(series.resource.labels),
"current_value": round(last, 4),
"mean_1h": round(mean, 4),
"std_dev": round(std, 4),
"deviation_sigma": round(abs(last - mean) / std, 2),
})
return anomalies
Cette approche s’adapte automatiquement aux patterns de charge de chaque ressource.
Déploiement en 3 commandes
# Déployer la Cloud Function
gcloud functions deploy analyze-infra \
--gen2 \
--runtime python312 \
--trigger-topic infra-monitor \
--region europe-west1 \
--service-account monitor-agent@${PROJECT_ID}.iam.gserviceaccount.com \
--set-env-vars PROJECT_ID=${PROJECT_ID}
# Créer le job Cloud Scheduler (toutes les 15 min)
gcloud scheduler jobs create pubsub infra-monitor-trigger \
--schedule "*/15 * * * *" \
--topic infra-monitor \
--message-body "check"
# IAM minimal (principe de moindre privilège)
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:monitor-agent@${PROJECT_ID}.iam.gserviceaccount.com" \
--role="roles/monitoring.viewer"
Coût réel
Pour une infrastructure de taille moyenne (~50 services) :
| Composant |
Invocations/mois |
Coût estimé |
| Cloud Functions |
~3 000 |
< 0,10 € |
| Vertex AI (Gemini Flash) |
~3 000 tokens × 3 000 |
< 1,50 € |
| Cloud Scheduler |
1 job |
0,10 € |
| Total |
|
< 2 € / mois |
Le ROI s’est amorti dès la première fausse alerte évitée à 2h du matin.
Ce que l’agent ne fait pas
Il ne corrige pas les problèmes — il les triage. La décision d’action reste humaine. C’est voulu.
Un agent qui se corrige lui-même sur une infrastructure de production sans supervision, c’est exactement le type de risque que les SRE sérieux évitent. Le LLM analyse et recommande. L’humain décide et agit.
Cette limite est une feature, pas un bug.
Le code complet est disponible sur demande. Si vous l’adaptez à votre infra, partagez vos retours en commentaire — notamment sur les faux positifs que vous observez.
30 ans de carrière IT. 8 ans sur Google Cloud Platform. Des centaines de migrations, des dizaines de designs d’architecture, des milliers d’heures de documentation.
Et depuis 18 mois, une partie croissante de ce travail passe par Claude ou Gemini.
Ce n’est pas que je délègue mes décisions — l’architecture reste un jugement humain, et les conséquences d’un mauvais choix sur GKE à 3h du matin sont très réelles. Mais certaines tâches qui prenaient 2 heures prennent maintenant 20 minutes. Et ça change le rythme de travail.
Voici les 5 prompts que j’utilise le plus souvent, avec la logique derrière chacun.
1. Le prompt de revue d’architecture
Quand : Avant de présenter un design à la direction ou à l’équipe.
Tu es un architecte cloud senior spécialisé GCP avec 10 ans d'expérience.
Voici mon architecture pour [contexte du projet].
[Description ou schéma en texte]
Identifie :
1. Les points de défaillance unique (SPOF)
2. Les risques de coût non anticipés
3. Les problèmes de sécurité (IAM, réseau, secrets)
4. Ce que tu changerais si tu étais responsable de la production
Sois direct. Pas de compliments, juste les problèmes.
Pourquoi ça marche : L’instruction « pas de compliments » est critique. Sans elle, les LLM ont tendance à valider avant de critiquer. Là, vous obtenez directement les points de friction — exactement ce dont vous avez besoin avant une présentation.
J’ai utilisé ce prompt avant un design GKE multi-région. Claude a identifié un problème de coût sur le trafic inter-régions que j’avais sous-estimé d’un facteur 3. Ça valait les 3 minutes de prompt.
2. Le prompt de comparaison de solutions
Quand : Face à un choix d’architecture (Cloud Run vs GKE, Cloud SQL vs AlloyDB, Pub/Sub vs Eventarc, etc.)
Compare [Option A] et [Option B] pour le cas d'usage suivant :
[Description précise du contexte : volume, équipe, contraintes]
Structure ta réponse ainsi :
- Tableau comparatif sur les critères : coût, complexité opérationnelle, scalabilité, lock-in, maturité
- Recommandation claire avec justification en 3 phrases
- Ce que tu n'as pas assez d'information pour évaluer
Contexte additionnel : [taille de l'équipe, budget, niveau de compétences]
Pourquoi ça marche : La section « ce que tu n’as pas assez d’information pour évaluer » est la plus utile. Elle vous dit exactement quelles questions poser à l’équipe avant de trancher.
3. Le prompt de génération de Terraform
Quand : Besoin d’un module Terraform pour une ressource standard.
Génère un module Terraform pour [ressource GCP] avec les contraintes suivantes :
- Provider : google ~> 6.0
- [Contrainte 1 : ex. réseau VPC privé sans IP publique]
- [Contrainte 2 : ex. chiffrement CMEK avec Cloud KMS]
- [Contrainte 3 : ex. labels standards organisation]
Le module doit :
- Être paramétrable (variables.tf propre)
- Inclure les outputs utiles
- Respecter le principe de moindre privilège sur l'IAM
- Avoir des commentaires sur les choix non évidents
N'utilise pas de ressources dépréciées. Vérifie la compatibilité provider 6.x.
Pourquoi ça marche : Sans l’instruction sur les ressources dépréciées, vous obtenez souvent du Terraform qui compilait en 2022 mais pas aujourd’hui. La contrainte « principe de moindre privilège » évite les roles/editor par défaut qui trainent dans trop de codebases.
Mise en garde : Relisez toujours le Terraform généré. Claude est excellent pour la structure, mais il peut halluciner des arguments d’attributs qui n’existent pas ou inverser des valeurs booléennes. Plan avant apply, toujours.
4. Le prompt de post-mortem structuré
Quand : Après un incident en production. Le plus sous-utilisé de cette liste.
Aide-moi à rédiger un post-mortem pour l'incident suivant.
Timeline des faits :
[Liste chronologique de ce qui s'est passé]
Contexte technique :
[Architecture concernée, composants impliqués]
Impact :
[Durée, utilisateurs affectés, SLA]
Génère :
1. Un résumé exécutif (5 phrases maximum, sans jargon)
2. Une timeline structurée
3. L'analyse des causes profondes (5 Pourquoi)
4. Les actions correctives avec priorité et propriétaire
5. Les signaux d'alerte qui auraient pu détecter le problème plus tôt
Ton : factuel, sans chercher des coupables.
Pourquoi ça marche : Le post-mortem est souvent rédigé dans l’urgence, sous stress, par l’équipe épuisée qui vient de passer la nuit dessus. Avoir un squelette structuré accélère la rédaction de 70% et améliore la qualité — notamment la section « 5 Pourquoi » qui est souvent bâclée.
5. Le prompt de préparation à une présentation technique
Quand : Avant de présenter une décision d’architecture à des non-techniciens (DSI, direction métier, RH, achats).
Je dois présenter [sujet technique] à [audience : DSI non-technique / direction métier / comité achat].
Voici les points clés que je veux communiquer :
[Liste des points techniques]
Aide-moi à :
1. Traduire chaque point en langage métier (pas de jargon)
2. Anticiper les 5 questions les plus probables de cette audience
3. Préparer des réponses concises (max 2 phrases par question)
4. Identifier les risques que cette audience va sur-estimer et ceux qu'elle va sous-estimer
Contexte : l'objectif de la réunion est [décision à prendre / information à transmettre].
Pourquoi ça marche : J’ai utilisé ce prompt pour préparer la présentation de notre stratégie de migration GCP devant le CODIR. La section « risques sur/sous-estimés » était particulièrement utile — elle m’a permis d’anticiper les questions sur le lock-in cloud (sur-estimé) et de préparer les arguments sur les coûts cachés du on-premise (sous-estimé).
Ce que j’ai appris en 18 mois
La précision du contexte est tout. Un prompt vague donne une réponse vague. Plus vous donnez de contraintes réelles — taille d’équipe, budget, niveau de maturité, contraintes réglementaires — plus la réponse est utile.
Demandez toujours les limites. « Ce que tu n’as pas assez d’information pour évaluer » devrait être dans tous vos prompts techniques. Les LLM ont tendance à combler les trous avec des hypothèses implicites. Forcer l’explicitation de ces limites vous protège des faux positifs.
Itérez dans la même conversation. Le premier output est rarement le bon. « Va plus loin sur le point 3 », « Reformule pour un public non-technique », « Ajoute les implications FinOps » — la conversation est le vrai outil, pas le prompt unique.
Gardez vos prompts dans un fichier. J’ai un prompts.md dans mon vault Obsidian. Chaque prompt qui a bien fonctionné y atterrit, annoté avec le contexte et le résultat obtenu. C’est une ressource qui s’améliore avec le temps.
La limite que je ne franchis pas
L’architecture finale reste ma décision, pas celle du LLM.
Pas parce que Claude serait mauvais — sur certains aspects techniques, il m’a surpris plusieurs fois. Mais parce que la responsabilité d’un choix d’infrastructure en production, avec les données de 10 millions de clients en jeu, ne peut pas être déléguée à un outil dont je ne contrôle pas entièrement le raisonnement.
L’IA augmente ma vitesse de réflexion. Elle ne remplace pas mon jugement.
C’est la distinction qui compte.
Vous utilisez des prompts différents dans votre pratique quotidienne ? Partagez-les en commentaire — les meilleurs workflows naissent souvent d’une conversation.