Container logging
Version: 23.09
The Container Logging Feature is designed to provide logging capabilities for objects stored in the object storage system. This feature will provide insights into object-level activities and audit trails, which will help them understand access patterns, usage statistics, and security incidents.
Logging can be enabled at container level, for the purpose of auditing and analyzing all operations on objects.
Logs are generated into a separate target container in the same account. A container that has logging enabled cannot be used as the target for any audit logs, neither its own logs, nor audit logs for any other container.
A target container containing audit logs can be used to collect logs for multiple containers that have logging enabled. Write permissions on the target container are required.
Enabling logging is activated either when creating a container, or in the Container Logging tab in the details pane for existing containers. See Create Containers and Details Pane.
The configuration includes an option to define a logging prefix, so that locating and identifying log objects is simplified.
In order to avoid additional workload on the Object Storage platform and to avoid any impact on client performance, the logs will be delivered once a day. The interval for sending the logs to the target container will be shortened in the Object Storage next release.
There is no extra charge for enabling Container logging. However, the logs that are stored in the system will increase storage consumption. The logs collected and stored can be deleted at any time.
Log Rotation and Flush Policy
The maximum log file size is 200 MB.
Log upload is controlled by both size and time:
Logs are uploaded immediately once the file reaches 200 MB.
If the size threshold is not reached, logs are uploaded within 24 hours.
Administrators can manually flush the most recent audit logs from the management console.
The flush operation typically completes within 5–10 minutes.
Enabling Container Logging
Container Logging can be enabled/disabled at any time from the following interfaces:
From Zadara’s Object Storage Object Storage management console
While using S3 API (aws cli package or S3 compatible software that supports enabling S3 Server Logging)
Log record structure
In order to make use of existing tools and avoid the overhead when using the audit logs Zadara log structure is similar to the AWS S3 Server Logging option, while not all attributes can match due to the differences in the platform, logs that doesn’t have a Zadara Object Storage presence or are not currently implemented will have the value of - (dash).
Log filenames have the format:
<user defined prefix>-<ISO formatted log delivery date>
Example (no user defined prefix):
2023-12-02-22-07-22
The log record structure:
Field name |
Description |
|---|---|
Container Owner |
The canonical user ID of the source container’s owner. |
Container |
The name of the container that the request was processed against. Malformed requests will not appear in the log. |
Time |
The date and time that the request was received in UTC format. In |
Remote IP |
The requester’s IP address. Proxies and firewalls might obscure the actual IP address of the requesting machine. |
Requester ID |
The user ID of the request, and “-” for unauthenticated requests. |
Request ID |
A generated string that uniquely identifies the request. |
Operation |
The object operation type: GET/POST/PUT/DELETE/HEAD |
Key |
The request’s object name (key). For example, |
Request-URI |
The Request-URI part of the HTTP request message. |
HTTP status |
The numeric HTTP status code of the response. |
Error Code |
The error code, or “-” if no error occurred. |
Bytes Sent |
The number of response bytes sent, excluding HTTP protocol overhead, or “-” if zero. |
Object Size |
The object’s total size in bytes. |
Total Time |
The number of milliseconds that the request was in flight from the server’s perspective, measured from the time that the request is received to the time that the last byte of the response is sent. Measurements made from the client’s perspective might be longer because of network latency. |
User-Agent |
The value of the HTTP |
Version Id |
The version ID in the request, or “-” if the operation doesn’t take a “versionId” parameter. |
Host Id |
The VC that handled the request. |
Container Logging log format examples
Container logging example for HEAD request
- savihou-manual [23/Nov/2023:02:23:44 +0000] 172.23.224.102 7c6d15bdf0d74802a9c751dd5c55bfa2 txe6a729193f9e479f876cd-00655eb7b0 HEAD - "HEAD / HTTP/1.1" 200 - - - 0.0106 - - "APN/1.0 Veeam/1.0 Backup/12.0" - - - - - - - - -
Container logging example for GET request
- savihou-manual [23/Nov/2023:06:58:01 +0000] 172.23.224.102 7c6d15bdf0d74802a9c751dd5c55bfa2 tx39562231422843d99a776-00655ef7f9 GET - "GET /?delimiter=%2F&max-keys=1000&prefix= HTTP/1.1" 200 - 320 - 0.0216 - - "S3 Browser/11.4.5 (https://s3browser.com)" - - - - - - - - -
Container logging example for PUT request
- savihou-manual [23/Nov/2023:02:24:36 +0000] 172.23.224.102 7c6d15bdf0d74802a9c751dd5c55bfa2 tx8ebb2ddeb8fc4535826de-00655eb7e4 PUT 10k-objects-1/randobj-828 "PUT /10k-objects-1/randobj-828 HTTP/1.1" 200 - - 4096 0.0712 - - "aws-sdk-go/1.45.18 (go1.10.4; linux; amd64)" - - - - - - - - -