Understanding OpenStack API logs

Objective

OVHcloud Public Cloud exposes API access logs for three core OpenStack services: Compute (Nova), Block Storage (Cinder), and Network (Neutron). These logs capture every HTTP request made to the API, with details about the caller, the request, and the response.

Typical use cases include:

• Troubleshooting: identify failed API calls, slow responses, or unexpected error codes
• Security auditing: track who called the API, from which IP address, and when
• API debugging: inspect exact request paths, HTTP methods, and response sizes

This guide explains the available OpenStack API log kinds and documents each returned log field.

Requirements

• A Public Cloud project in your OVHcloud account

Instructions

Available log kinds

Three log kinds cover the main OpenStack APIs:

Log fields

Each log entry contains the following fields:

Use cases and examples

Troubleshooting failed API calls

Filter on api_response_code_int >= 500 to identify server-side errors. A 500 on POST /v2.1/servers may indicate a capacity issue or a malformed request body.

Example log entry for a failed instance creation:

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

Use the request_id value to correlate this entry with other service logs for the same request.

Security auditing

The user, project_id, client, and region fields let you trace who performed an action and from where.

Useful audit queries:

• All calls from an unexpected client IP address
• All DELETE requests on sensitive resources (e.g. DELETE /v2.1/servers/{id})
• All accesses from an unrecognised user_agent (e.g. unknown automation scripts)
• All requests from a user that should not have been active

For example, a DELETE /v2.1/servers/{id} entry with api_response_code_int: 204 confirms a successful instance deletion; the user field identifies who triggered it.

Detecting slow API responses

Use api_response_time_num to detect performance degradation. Requests with a response time above 2–3 seconds may signal backend pressure or an overloaded region.

Combine api_response_time_num with path to narrow down which endpoint is slow, and with region to determine whether the issue is region-specific.

Block Storage — quota and conflict errors

For the volume-api log kind, watch for repeated POST /v3/{project_id}/volumes calls returning api_response_code_int: 409 (Conflict). This typically indicates volume name conflicts or quota exhaustion.

A 403 on GET /v3/{project_id}/volumes means the caller (identified by user) lacks permission to list volumes in that project.

Network — permission and routing errors

For the network-api log kind, PUT requests to /v2.0/routers/{id} returning 403 (Forbidden) indicate that the caller does not have sufficient permissions to modify the router. The user field identifies who attempted the change.

A 404 on /v2.0/networks/{id} confirms the network no longer exists or was never created in that region.

Go further

• Introduction to OVHcloud Service Logs with Logs Data Platform
• Getting started with the OpenStack API
• Preparing an environment for using the OpenStack API
• Setting OpenStack environment variables

Join our community of users.