Comprendre les logs d'API OpenStack

Objectif

Le Public Cloud OVHcloud expose des logs d'accès API pour trois services OpenStack essentiels : Compute (Nova), Block Storage (Cinder) et Network (Neutron). Ces logs capturent chaque requête HTTP adressée à l'API, avec des informations détaillées sur l'appelant, la requête et la réponse.

Principaux cas d'usage :

• Dépannage : identifier les appels API en échec, les réponses lentes ou les codes d'erreur inattendus
• Audit de sécurité : suivre qui a appelé l'API, depuis quelle adresse IP et à quel moment
• Débogage d'API : inspecter les chemins de requête exacts, les méthodes HTTP et les tailles de réponse

Ce guide explique les types de logs d'API OpenStack disponibles et documente chaque champ retourné.

Prérequis

• Un projet Public Cloud dans votre compte OVHcloud

En pratique

Types de logs disponibles

Trois types de logs couvrent les principales API OpenStack :

Champs des logs

Chaque entrée de log contient les champs suivants :

Cas d'usage et exemples

Dépannage des appels API en échec

Filtrez sur api_response_code_int >= 500 pour identifier les erreurs côté serveur. Un 500 sur POST /v2.1/servers peut indiquer un problème de capacité ou un corps de requête mal formé.

Exemple d'entrée de log pour une création d'instance en échec :

{
  "api_response_code_int": 500,
  "api_response_size_int": 312,
  "api_response_time_num": 0.342,
  "client": "198.51.100.42",
  "http_version": "HTTP/1.1",
  "method": "POST",
  "path": "/v2.1/servers",
  "program": "nova-api",
  "project_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "region": "GRA11",
  "request_id": "req-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "user": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "user_agent": "python-openstackclient/5.8.0"
}

Utilisez la valeur request_id pour corréler cette entrée avec d'autres logs de service pour la même requête.

Audit des accès API

Les champs user, project_id, client et region permettent de retracer qui a effectué une action et depuis quel endroit.

Requêtes d'audit utiles :

• Tous les appels depuis une adresse IP client inattendue
• Toutes les requêtes DELETE sur des ressources sensibles (ex. DELETE /v2.1/servers/{id})
• Tous les accès depuis un user_agent non reconnu (ex. scripts d'automatisation inconnus)
• Toutes les requêtes d'un user qui n'aurait pas dû être actif

Par exemple, une entrée DELETE /v2.1/servers/{id} avec api_response_code_int: 204 confirme la suppression réussie d'une instance ; le champ user identifie qui en est à l'origine.

Détection des réponses API lentes

Utilisez api_response_time_num pour détecter une dégradation des performances. Les requêtes dont le temps de réponse dépasse 2–3 secondes peuvent signaler une pression sur le backend ou une région surchargée.

Combinez api_response_time_num avec path pour cibler l'endpoint problématique, et avec region pour déterminer si le problème est spécifique à une région.

Block Storage — erreurs de quota et de conflit

Pour le type de log volume-api, surveillez les appels répétés POST /v3/{project_id}/volumes retournant api_response_code_int: 409 (Conflit). Cela indique généralement des conflits de noms de volumes ou un dépassement de quota.

Un 403 sur GET /v3/{project_id}/volumes signifie que l'appelant (identifié par user) ne dispose pas des permissions nécessaires pour lister les volumes dans ce projet.

Network — erreurs de permission et de routage

Pour le type de log network-api, les requêtes PUT sur /v2.0/routers/{id} retournant 403 (Interdit) indiquent que l'appelant ne dispose pas des permissions suffisantes pour modifier le routeur. Le champ user identifie qui a tenté la modification.

Un 404 sur /v2.0/networks/{id} confirme que le réseau n'existe plus ou n'a jamais été créé dans cette région.

Aller plus loin

• Introduction à OVHcloud Service Logs avec Logs Data Platform
• Débuter avec l'API OpenStack
• Préparer l'environnement pour utiliser l'API OpenStack
• Charger les variables d'environnement OpenStack

Échangez avec notre communauté d'utilisateurs.