Diagnostiquer¶
Journaux¶
az containerapp logs show -g rg-aim-prod -n ca-aim-api --tail 100 --format text
az containerapp logs show -g rg-aim-prod -n ca-aim-api --follow
Les journaux applicatifs sont visibles — ça n'a pas toujours été le cas
uvicorn configure ses propres loggers mais laisse la racine sans gestionnaire :
tout log.warning d'un module métier disparaissait purement et simplement.
C'est ainsi qu'un problème d'archivage a pu passer inaperçu. La journalisation
est désormais configurée explicitement au démarrage.
Côté client¶
Vérifie la configuration, l'authentification et les clients accessibles.
Symptômes courants¶
« AIM n'est pas configuré sur cette machine »¶
aim login n'a jamais été lancé, ou AIM_HOME pointe ailleurs.
401 sur toutes les commandes¶
Session Azure expirée : az login. Si c'est une clé d'API, elle a peut-être été
révoquée — aim key list.
« Client introuvable » sur un client qui existe¶
Tu n'en es pas membre. C'est le comportement voulu : un 403 révélerait son
existence. Demande un accès à un propriétaire.
aim sync dit utiliser le cache¶
L'API est injoignable : VPN, proxy, ou service arrêté. Vérifie :
Le repli est normal et voulu — voir Travailler hors ligne.
Le MCP répond 421 « Invalid Host header »¶
Le nom d'hôte n'est pas déclaré au contrôle anti-DNS-rebinding. Vérifie
AIM_ALLOWED_HOSTS :
az containerapp show -g rg-aim-prod -n ca-aim-api \
--query "properties.template.containers[0].env[?name=='AIM_ALLOWED_HOSTS'].value" -o tsv
Il doit valoir le FQDN de l'ingress.
Le MCP répond 307¶
Un client qui appelle /mcp/ avec une barre finale. L'endpoint est exactement
/mcp.
L'extraction échoue sur un document¶
Le message est dans le flux et dans le rapport final. Causes fréquentes :
| Message | Cause | Remède |
|---|---|---|
| « réponse coupée » persistante | Passage très dense, re-découpé trois fois sans succès | Découper le document en amont |
| « Schéma invalide » | Le modèle n'a pas respecté le format | Relancer ; si ça persiste, AIM_MODEL |
| Erreur d'API Anthropic | Quota ou clé | Vérifier le secret anthropic-key |
Un déploiement « réussit » mais le code n'a pas changé¶
Le script le détecte désormais et échoue. En cas de doute :
az containerapp revision list -g rg-aim-prod -n ca-aim-api \
--query "[?properties.trafficWeight>\`0\`].{rev:name,image:properties.template.containers[0].image,etat:properties.runningState}" -o table
az storage plante avec No module named expat¶
Problème du Python de Homebrew sur macOS, pas d'AIM. Contourner par l'API REST :
TOKEN=$(az account get-access-token --resource https://storage.azure.com/ --query accessToken -o tsv)
curl -s -H "Authorization: Bearer $TOKEN" -H "x-ms-version: 2021-12-02" \
"https://staimdxqjgx747khfs.blob.core.windows.net/raw?restype=container&comp=list"
Un piège de diagnostic vécu
Un listage de blobs renvoyant AuthorizationPermissionMismatch et filtré par
grep ressemble exactement à « aucun blob ». Toujours regarder la réponse brute
avant de conclure à une absence.
Base de données¶
Elle n'est pas joignable depuis Internet. Pour une inspection ponctuelle, passer par un conteneur dans le même réseau virtuel :
Puis avec python et psycopg, en réutilisant AIM_DSN.
Coûts inattendus¶
Vérifier d'abord Log Analytics, qui facture à l'ingestion. Si le volume grimpe,
chercher un logger trop bavard : les SDK Azure tracent chaque en-tête HTTP en INFO
s'ils ne sont pas mis en sourdine.