--- title: "Understanding OpenStack API logs" description: "Find out how to read and use OpenStack API access logs for troubleshooting, security auditing, and API debugging" url: https://docs.ovhcloud.com/en/guides/public-cloud/compute/openstack-api-logs lang: en lastUpdated: 2026-06-03 --- # 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 kind | Service | Description | | ------------- | ---------------------- | -------------------------------------------------- | | `compute-api` | Nova (Compute) | HTTP access logs for instance management API calls | | `volume-api` | Cinder (Block Storage) | HTTP access logs for volume management API calls | | `network-api` | Neutron (Network) | HTTP access logs for network and subnet API calls | ### Log fields Each log entry contains the following fields: | Field | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------------------------------- | | `api_response_code_int` | integer | HTTP status code returned by the API (e.g. `200`, `404`, `500`) | | `api_response_size_int` | integer | Size of the API response body in bytes | | `api_response_time_num` | float | API response time in seconds | | `client` | string | Source IP address of the API client | | `fingerprinted_iplb` | string | IP address of the load balancer that received the request, if applicable | | `http_version` | string | HTTP protocol version used (e.g. `HTTP/1.1`) | | `method` | string | HTTP method (e.g. `GET`, `POST`, `PUT`, `DELETE`) | | `path` | string | API endpoint path requested (e.g. `/v2.1/servers`) | | `program` | string | Internal service name that generated the log entry (e.g. `nova-api`, `cinder-api`, `neutron-api`) | | `project_id` | string | OpenStack project (tenant) UUID the request was made against | | `region` | string | OVHcloud region where the API request was processed | | `request_id` | string | Unique request identifier, useful for correlating logs across services | | `user` | string | OpenStack user UUID who performed the request | | `user_agent` | string | HTTP `User-Agent` header sent by the client | ### 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: ```json { "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](/en/guides/manage-and-operate/observability/logs-data-platform/service-logs.md) - [Getting started with the OpenStack API](/en/guides/public-cloud/compute/starting-with-nova.md) - [Preparing an environment for using the OpenStack API](/en/guides/public-cloud/cross-functional/compute-prepare-openstack-api-environment.md) - [Setting OpenStack environment variables](/en/guides/public-cloud/cross-functional/compute-set-openstack-environment-variables.md) Join our [community of users](https://community.ovhcloud.com/).