Zrozumieć logi API OpenStack

Wprowadzenie

OVHcloud Public Cloud udostępnia logi dostępu do API dla trzech podstawowych usług OpenStack: Compute (Nova), Block Storage (Cinder) oraz Network (Neutron). Logi te rejestrują każde żądanie HTTP wysłane do API wraz ze szczegółami dotyczącymi wywołującego, żądania oraz odpowiedzi.

Typowe przypadki użycia obejmują:

• Rozwiązywanie problemów: identyfikowanie nieudanych wywołań API, powolnych odpowiedzi lub nieoczekiwanych kodów błędów
• Audyt bezpieczeństwa: śledzenie, kto wywołał API, z jakiego adresu IP oraz kiedy
• Debugowanie API: analizowanie dokładnych ścieżek żądań, metod HTTP oraz rozmiarów odpowiedzi

Niniejszy przewodnik wyjaśnia dostępne typy logów API OpenStack oraz dokumentuje każde zwracane pole logów.

Wymagania początkowe

• Projekt Public Cloud na Twoim koncie OVHcloud

W praktyce

Dostępne typy logów

Trzy typy logów obejmują główne interfejsy API OpenStack:

Pola logów

Każdy wpis logu zawiera następujące pola:

Przypadki użycia i przykłady

Rozwiązywanie problemów z nieudanymi wywołaniami API

Filtruj według api_response_code_int >= 500, aby zidentyfikować błędy po stronie serwera. Kod 500 przy POST /v2.1/servers może wskazywać na problem z pojemnością lub nieprawidłowo sformułowaną treść żądania.

Przykładowy wpis logu dla nieudanego tworzenia instancji:

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

Użyj wartości request_id, aby skorelować ten wpis z innymi logami usług dotyczącymi tego samego żądania.

Audyt bezpieczeństwa

Pola user, project_id, client oraz region pozwalają ustalić, kto wykonał daną akcję i skąd.

Przydatne zapytania audytowe:

• Wszystkie wywołania z nieoczekiwanego adresu IP client
• Wszystkie żądania DELETE dotyczące zasobów wrażliwych (np. DELETE /v2.1/servers/{id})
• Wszystkie dostępy z nierozpoznanego user_agent (np. nieznane skrypty automatyzacji)
• Wszystkie żądania od użytkownika user, który nie powinien być aktywny

Na przykład wpis DELETE /v2.1/servers/{id} z api_response_code_int: 204 potwierdza pomyślne usunięcie instancji; pole user identyfikuje, kto je zainicjował.

Wykrywanie powolnych odpowiedzi API

Użyj api_response_time_num, aby wykryć pogorszenie wydajności. Żądania z czasem odpowiedzi przekraczającym 2–3 sekundy mogą sygnalizować obciążenie backendu lub przeciążony region.

Połącz api_response_time_num ze path, aby ustalić, który punkt końcowy jest powolny, oraz z region, aby określić, czy problem dotyczy konkretnego regionu.

Block Storage — błędy limitów i konfliktów

W przypadku typu logów volume-api zwracaj uwagę na powtarzające się wywołania POST /v3/{project_id}/volumes zwracające api_response_code_int: 409 (Conflict). Zwykle wskazuje to na konflikty nazw wolumenów lub wyczerpanie limitów.

Kod 403 przy GET /v3/{project_id}/volumes oznacza, że wywołujący (zidentyfikowany przez user) nie ma uprawnień do wyświetlania wolumenów w tym projekcie.

Network — błędy uprawnień i routingu

W przypadku typu logów network-api żądania PUT do /v2.0/routers/{id} zwracające 403 (Forbidden) wskazują, że wywołujący nie posiada wystarczających uprawnień do modyfikacji routera. Pole user identyfikuje, kto próbował wprowadzić zmianę.

Kod 404 przy /v2.0/networks/{id} potwierdza, że sieć już nie istnieje lub nigdy nie została utworzona w tym regionie.

Sprawdź również

• Wprowadzenie do logów usług OVHcloud z Logs Data Platform
• Pierwsze kroki z API OpenStack
• Przygotowanie środowiska do korzystania z API OpenStack
• Ustawianie zmiennych środowiskowych OpenStack

Dołącz do grona naszych użytkowników.