OpenStack API-Logs verstehen

Als Markdown ansehen

Erfahren Sie, wie Sie OpenStack API-Zugriffslogs zur Fehlerbehebung, für Sicherheitsaudits und zum Debuggen der API lesen und nutzen

Ziel

OVHcloud Public Cloud stellt API-Zugriffslogs für drei zentrale OpenStack Services bereit: Compute (Nova), Block Storage (Cinder) und Network (Neutron). Diese Logs erfassen jede an die API gerichtete HTTP-Anfrage mit Angaben zum Aufrufer, zur Anfrage und zur Antwort.

Typische Anwendungsfälle sind:

  • Fehlerbehebung: fehlgeschlagene API-Aufrufe, langsame Antworten oder unerwartete Fehlercodes identifizieren
  • Sicherheitsaudits: nachvollziehen, wer die API von welcher IP-Adresse und wann aufgerufen hat
  • API-Debugging: exakte Anfragepfade, HTTP-Methoden und Antwortgrößen prüfen

Diese Anleitung erläutert die verfügbaren OpenStack API-Log-Typen und dokumentiert jedes zurückgegebene Log-Feld.

Voraussetzungen

  • Ein in Ihrem OVHcloud Account

In der praktischen Anwendung

Verfügbare Log-Typen

Drei Log-Typen decken die wichtigsten OpenStack APIs ab:

Log-TypServiceBeschreibung
compute-apiNova (Compute)HTTP-Zugriffslogs für API-Aufrufe zur Verwaltung von Instanzen
volume-apiCinder (Block Storage)HTTP-Zugriffslogs für API-Aufrufe zur Verwaltung von Volumes
network-apiNeutron (Network)HTTP-Zugriffslogs für API-Aufrufe zu Netzwerken und Subnetzen

Log-Felder

Jeder Log-Eintrag enthält die folgenden Felder:

FeldTypBeschreibung
api_response_code_intGanzzahlVon der API zurückgegebener HTTP-Statuscode (z. B. 200, 404, 500)
api_response_size_intGanzzahlGröße des API-Antworttexts in Bytes
api_response_time_numGleitkommazahlAPI-Antwortzeit in Sekunden
clientZeichenketteQuell-IP-Adresse des API-Clients
fingerprinted_iplbZeichenketteIP-Adresse des Load Balancers, der die Anfrage erhalten hat, sofern zutreffend
http_versionZeichenketteVerwendete Version des HTTP-Protokolls (z. B. HTTP/1.1)
methodZeichenketteHTTP-Methode (z. B. GET, POST, PUT, DELETE)
pathZeichenketteAngefragter Pfad des API-Endpunkts (z. B. /v2.1/servers)
programZeichenketteInterner Servicename, der den Log-Eintrag erzeugt hat (z. B. nova-api, cinder-api, neutron-api)
project_idZeichenketteUUID des OpenStack Projekts (Tenant), gegen das die Anfrage gerichtet war
regionZeichenketteOVHcloud Region, in der die API-Anfrage verarbeitet wurde
request_idZeichenketteEindeutige Anfragekennung, nützlich zum Korrelieren von Logs über Services hinweg
userZeichenketteUUID des OpenStack Benutzers, der die Anfrage ausgeführt hat
user_agentZeichenketteVom Client gesendeter HTTP-User-Agent-Header

Anwendungsfälle und Beispiele

Fehlgeschlagene API-Aufrufe beheben

Filtern Sie auf api_response_code_int >= 500, um serverseitige Fehler zu identifizieren. Ein 500 bei POST /v2.1/servers kann auf ein Kapazitätsproblem oder einen fehlerhaften Anfragetext hinweisen.

Beispiel für einen Log-Eintrag bei einer fehlgeschlagenen Instanzerstellung:

{
  "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"
}

Verwenden Sie den Wert von request_id, um diesen Eintrag mit anderen Service-Logs derselben Anfrage zu korrelieren.

Sicherheitsaudits

Die Felder user, project_id, client und region ermöglichen es Ihnen nachzuvollziehen, wer eine Aktion ausgeführt hat und von wo.

Nützliche Audit-Abfragen:

  • Alle Aufrufe von einer unerwarteten client-IP-Adresse
  • Alle DELETE-Anfragen auf sensible Ressourcen (z. B. DELETE /v2.1/servers/{id})
  • Alle Zugriffe von einem nicht erkannten user_agent (z. B. unbekannte Automatisierungsskripte)
  • Alle Anfragen von einem user, der nicht hätte aktiv sein dürfen

Ein Eintrag DELETE /v2.1/servers/{id} mit api_response_code_int: 204 bestätigt beispielsweise eine erfolgreiche Löschung einer Instanz; das Feld user identifiziert, wer sie ausgelöst hat.

Langsame API-Antworten erkennen

Verwenden Sie api_response_time_num, um Performance-Einbußen zu erkennen. Anfragen mit einer Antwortzeit von mehr als 2–3 Sekunden können auf eine Belastung des Backends oder eine überlastete Region hinweisen.

Kombinieren Sie api_response_time_num mit path, um einzugrenzen, welcher Endpunkt langsam ist, und mit region, um festzustellen, ob das Problem regionsspezifisch ist.

Block Storage – Kontingent- und Konfliktfehler

Achten Sie beim Log-Typ volume-api auf wiederholte Aufrufe von POST /v3/{project_id}/volumes, die api_response_code_int: 409 (Conflict) zurückgeben. Dies weist in der Regel auf Konflikte bei Volume-Namen oder auf erschöpfte Kontingente hin.

Ein 403 bei GET /v3/{project_id}/volumes bedeutet, dass dem Aufrufer (identifiziert durch user) die Berechtigung fehlt, die Volumes in diesem Projekt aufzulisten.

Network – Berechtigungs- und Routing-Fehler

Beim Log-Typ network-api weisen PUT-Anfragen an /v2.0/routers/{id}, die 403 (Forbidden) zurückgeben, darauf hin, dass der Aufrufer nicht über ausreichende Berechtigungen verfügt, um den Router zu ändern. Das Feld user identifiziert, wer die Änderung versucht hat.

Ein 404 bei /v2.0/networks/{id} bestätigt, dass das Netzwerk nicht mehr existiert oder in dieser Region nie erstellt wurde.

Weiterführende Informationen

Treten Sie unserer User Community bei.

War diese Seite hilfreich?