Audit Logging

Service Logs

All Lakehousecat backend services write structured logs to the configured object storage (SeaweedFS or S3). The following services produce logs:

Service	Description
LHC	Core backend — API requests, authentication events, administrative actions, configuration and metadata management
LLM	LLM middleware — natural language to SQL translation, model calls, pipeline execution, result interpretation
Semantic	Semantic layer service — schema context delivery, datasource and semantic model management, business terminology mapping
Analytics	Analytics service — query execution against ClickHouse, chart generation, data transformations
Audio	Audio service — speech-to-text transcription, voice input processing

Log entries follow the format:

<timestamp> - <logger_name> - <level> - <message>

Logs include timestamps, log levels, service identifiers, and structured context fields.

Log Configuration

Log behavior is configured at the Operator level in the Lakehousecat CR YAML:

spec:
  platform:
    logging:
      level: "info"       # debug, info, warning, error
      format: "json"
      enableStackTrace: true
      enableCaller: true

The Operator can change the log level without redeploying services. Supported levels:

Level	Description
debug	Verbose output including internal processing details
info	Normal operational events (default)
warning	Non-critical issues that may require attention
error	Errors that affected request processing

What Is Currently Logged

The following event categories are captured in service logs:

• Authentication events — login, logout, failed authentication attempts
• Administrative actions — user creation, role changes, system configuration updates
• Data management — datasource operations, data load events
• Model operations — Custom Model creation, updates, deletions
• API activity — inbound requests with status codes and durations

note

These service-level logs cover infrastructure and API-level events. For per-entity change history (create, update, configure, share), see the Audit Log tab on each entity within the application — available for Data Sources, Custom Models, Charts, Dashboards, Job Definitions, Users, and Groups.

The same history is available from the command line with lhc audit-logs, which adds filtering by actor, action, entity type and time range — the form most audit questions actually take.

What the audit log does not record

Reads are not audited: viewing a chart, opening a dashboard or running a query leaves no entry. Sign-ins appear in the service logs above, not in the per-entity audit log. An empty audit history therefore means that no change was recorded — it is not evidence that an object was never accessed.

Consuming Logs

Lakehousecat does not include a built-in log viewer or alerting system. Logs are stored in object storage and are available for customers to consume with their preferred tooling:

• Grafana + Loki — log aggregation and visualization
• Elastic Stack — log forwarding and search
• AWS CloudWatch / Azure Monitor — cloud-native log processing
• Any S3-compatible log consumer

The specific integration depends on the customer's infrastructure and policies. Lakehousecat does not prescribe or restrict how logs are processed downstream.

Access

Logs are stored in the object storage bucket configured for the instance. Access to the bucket requires credentials managed outside Lakehousecat (at the infrastructure level). End users and application-level roles do not have direct access to raw log files.

Future Topics

The following are planned for future phases and are not currently in scope:

• Log rotation and retention policies — currently determined by the underlying object storage configuration
• Automated alerting — no built-in alerting; customers implement this with their monitoring tools
• Regulatory compliance reporting — SOC 2, GDPR audit evidence generation