Request Logging on Services¶

Requests to services can be logged to get better insight into the traffic flow. These request logs can contain the request metadata or even the complete request and response body.

Because a service is a proxy to a deployment, requests to services are logged in the same way as other deployment requests. They are stored at the particular deployment version that the service is connected to and can be viewed in the same way as other deployment requests, through the UbiOps WebApp or via the API or CLI.

For requests to services, additional information is stored compared to other requests:

• Request path, method and body
• Response status code and body

Request Filtering¶

Because some services may handle a large volume of requests, UbiOps does not store every request made to a service. Instead, there are various ways that UbiOps filters which requests to store. Some of these filters can be configured on a per-service basis, while others are applied globally.

Configurable Filters¶

• Path-based Exclusion: A regex pattern can be configured to exclude requests from logging based on their path. This allows services to avoid logging certain endpoints, such as health checks and status endpoints. Any request with a path matching the pattern will not be logged.

• File Extension Exclusion: A list of file extensions can be provided that determine which request bodies will be excluded from logging. The extensions are matched against the file extension inferred from the Content-Type header. If a request or response body has an excluded extension, the entire request/response will be excluded from logging.

• Disable request logging: It is possible to completely disable request logging for a service. When disabled, no requests will be logged for that service. This setting is controlled from the request logging settings on the deployment version that the service is attached to.

Non-configurable Filters¶

Some filters are applied globally and cannot be configured on a per-service basis:

• Size-based Exclusion: Request and response bodies larger than a certain size are not stored. This limit is 256 KiB by default and can be increased on request. Bodies exceeding this limit are ignored, but their request/response metadata is still stored.

• Rate Limiting: To prevent excessive logging during high-traffic periods or for applications with bursty traffic patterns (e.g., webapps), UbiOps applies throttling on request logging. A maximum of 5 requests per second per service are logged, although this limit can be raised on UbiOps Private installations. Additional requests beyond this limit are silently dropped (not logged).

Request and response Bodies¶

If you elect to enable "full" request retention, this will include the request en response bodies of the HTTP requests.

These bodies are stored in a way that preserves their original content type. The content type is determined from the Content-Type header of the request or response, and is used when returning the body through the retrieval endpoints. If the Content-Type header is missing or cannot be interpreted, a default of text/plain is used.

Request and response bodies can be viewed in the WebApp or retrieved via the API. See the API Swagger Documentation for request input and request output for more information.

For requests with a Content-Type of multipart/form-data, UbiOps will parse the multipart form and extract the first file found in the form. This file will be stored as if it is the entire request/response body. The reason for doing so is that it allows us to cleanly serve request/response bodies, as opposed to serving a full multipart form which can be complex and difficult to parse. By only storing the first file, we ensure that users can easily retrieve the uploaded file without having to deal with multipart parsing themselves. If the form data contains other fields (non-file fields), these are not stored. This also implies that if no file is found in the form, nothing will be stored for the request/response body.