Audit Logging System
Relevant source files
The following files were used as context for generating this wiki page:
The Audit Logging System in Daytona is a comprehensive framework designed to track, store, and manage administrative and operational actions performed across the platform. It ensures accountability and compliance by capturing detailed information about user actions, targeting specific resources, and providing a queryable history for administrators.
The system is built on a decoupled architecture that supports local storage, periodic publishing to external sinks (like OpenSearch), and automated lifecycle management including retention policies and cleanup of dangling logs.
Sources: apps/api/src/audit/services/audit.service.ts, apps/api/src/audit/adapters/audit-opensearch.adapter.ts
System Architecture
The Audit Logging System utilizes a service-oriented approach with specialized adapters for storage and publishing. The AuditService acts as the primary orchestrator, managing the lifecycle of an audit entry from creation to archival.
Core Components
| Component | Description |
|---|---|
| AuditService | The core business logic layer responsible for creating, updating, and managing the lifecycle of audit logs. |
| AuditLogRepository | TypeORM repository used for transient storage of logs before they are published or for local persistence. |
| AuditLogStorageAdapter | Interface for retrieving logs. The primary implementation uses OpenSearch for high-performance querying. |
| AuditLogPublisher | Interface for exporting logs to external systems. Executed via cron jobs to offload logs from the primary database. |
Sources: apps/api/src/audit/services/audit.service.ts:25-45, apps/api/src/audit/adapters/audit-opensearch.adapter.ts:20-30
Data Flow for Audit Log Lifecycle
The following diagram illustrates how an audit log moves from initial creation through the publishing phase and final deletion from the transient repository.
Functional Logic and Operations
Log Creation and Resolution
When an action is initiated, a log entry is created with an initial state. If a log remains "dangling" (missing a status code for over 30 minutes), a specialized cron job resolves it by setting the status code to 0 (Unknown).
- createLog(dto): Inserts a new
AuditLogentity into the local repository. - updateLog(id, dto): Updates an existing log with status codes, error messages, or target IDs.
- resolveDanglingLogs(): Runs every minute to find and close incomplete logs older than 30 minutes.
Sources: apps/api/src/audit/services/audit.service.ts:68-144
Publishing and Storage
Daytona supports exporting audit logs to OpenSearch via the AuditOpenSearchStorageAdapter. This adapter handles:
- Index Templates: Automatically configures shards, replicas, and mappings.
- Data Streams: Utilizes OpenSearch data streams for time-series audit data.
- ISM Policies: Implements Index State Management for automated rollover and deletion based on
retentionDaysconfiguration.
Sources: apps/api/src/audit/adapters/audit-opensearch.adapter.ts:38-160
Querying and Pagination
The system supports both offset-based and cursor-based pagination to handle large volumes of data.
Data Models
AuditLog Entity
The primary data structure for auditing contains identifying information for the actor, the action, and the target.
| Field | Type | Description |
|---|---|---|
id | string | Unique identifier for the audit entry. |
actorId | string | ID of the user who performed the action. |
actorEmail | string | Email of the user for easy identification in logs. |
action | string | The specific operation performed (e.g., "Create", "Delete"). |
targetType | string | The type of resource affected. |
statusCode | number | HTTP or internal status code of the result. |
createdAt | Date | Timestamp of when the action occurred. |
Sources: apps/api/src/audit/adapters/audit-opensearch.adapter.ts:114-130, libs/api-client-go/model_paginated_audit_logs.go:20-30
Configuration Options
The system is configured via TypedConfigService with the following key parameters:
| Option | Default/Limit | Description |
|---|---|---|
audit.publish.enabled | Boolean | Whether to export logs to an external sink. |
audit.publish.batchSize | Max 50,000 | Number of logs processed in a single publish cycle. |
audit.retentionDays | Numeric | Days to keep logs before automated deletion. |
audit.consoleLogEnabled | Boolean | If true, outputs audit entries to the application console. |
Sources: apps/api/src/audit/services/audit.service.ts:47-65, apps/api/src/audit/adapters/audit-opensearch.adapter.ts:140-150
API Endpoints
The Audit API facilitates retrieval of logs for global administrators or specific organization owners.
GET /audit: Retrieves all audit logs. Supportspage,limit,from,to, andnextToken.GET /audit/organizations/{organizationId}: Filters logs specifically for a given organization.
Sources: libs/api-client/src/api/audit-api.ts:40-100
Summary
The Audit Logging System provides a robust mechanism for tracking platform activity. By separating the initial capture into a local repository and asynchronously publishing to high-performance storage like OpenSearch, it ensures that audit logging does not impact API performance while still providing long-term, searchable records and automated data retention management.