This guide covers everything you need to run Log in production on Kubernetes: a complete Helm chart, S3-backed storage with a local disk cache, health checks, monitoring, and security.Documentation Index
Fetch the complete documentation index at: https://opendata.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
Deployment
Overview
Since we haven’t yet built partitioning into Log, a production Log deployment consists of a single replica only. The primary means of scaling would be scaling up, which can take you pretty far. Since all data is persisted on S3, data in a single node Log is highly durable. With that said, a production Log deployment consists of:- A single-replica Deployment running the
opendata-logcontainer - An S3 bucket for durable data storage
- A PersistentVolumeClaim backed by a fast SSD for the SlateDB disk cache
- A ConfigMap for SlateDB tuning parameters
- A ServiceAccount with an IAM role for S3 access (IRSA on EKS)
Log uses SlateDB’s epoch-based fencing, which means only one writer can hold
the epoch lock at a time. The Deployment uses the
Recreate strategy so that
the old pod is fully terminated before the new one starts — a RollingUpdate
would cause the new pod to be fenced by the old one and never become ready.Helm chart
Below is a complete Helm chart for deploying Log to production. Create these files undercharts/opendata-log/.
values.yaml
values.yaml
templates/configmap.yaml
templates/configmap.yaml
templates/serviceaccount.yaml
templates/serviceaccount.yaml
templates/pvc.yaml
templates/pvc.yaml
templates/deployment.yaml
templates/deployment.yaml
templates/service.yaml
templates/service.yaml
Install the chart
Disk cache
SlateDB caches frequently accessed data on local disk to avoid repeated reads from S3. For production workloads, use an SSD-backed StorageClass:- EKS: Use
gp3(General Purpose SSD) orio2for higher IOPS. For maximum performance, use instance-store NVMe volumes with a local-static-provisioner. - Size the cache based on your active working set. The default of 100 Gi is a
good starting point; increase if you see frequent cache evictions in the
slatedb_*metrics.
Health checks
Log exposes two health-check endpoints:| Endpoint | Type | Behavior |
|---|---|---|
/-/healthy | Liveness | Returns 200 if the process is running |
/-/ready | Readiness | Returns 200 if the storage check passes, 503 otherwise |
Graceful shutdown
Log handlesSIGTERM and SIGINT signals gracefully:
- Stops accepting new connections
- Drains in-flight requests
- Flushes pending data to durable storage
- Exits cleanly
terminationGracePeriodSeconds: 60 to give the server enough
time to complete the flush before Kubernetes force-kills the pod.
Monitoring
All metrics are exposed at/metrics in Prometheus text format.
Key metrics
| Metric | Type | Labels | Description |
|---|---|---|---|
log_append_records_total | counter | — | Total records appended |
log_append_bytes_total | counter | — | Total bytes appended |
log_records_scanned_total | counter | — | Total records scanned |
log_bytes_scanned_total | counter | — | Total bytes scanned |
http_requests_total | counter | method, endpoint, status | Total HTTP requests handled |
http_request_duration_seconds | histogram | method, endpoint | Request latency distribution |
http_requests_in_flight | gauge | — | Number of HTTP requests currently being served |
Log also exposes
slatedb_* metrics from the underlying SlateDB storage
engine. These are useful for debugging storage-level performance and compaction
behavior.Example PromQL queries
Security
TLS and authentication
Object storage security
The Helm chart uses IRSA (IAM Roles for Service Accounts) so that the pod receives temporary AWS credentials automatically — no static access keys required. Create an IAM role with the following policy and attach it to the ServiceAccount via theserviceAccount.roleArn value:
- Enable encryption at rest on the S3 bucket (SSE-S3 or SSE-KMS).
- Use a VPC endpoint for S3 to keep traffic off the public internet.
- Block all public access on the bucket.
- Add a lifecycle rule to transition old data to Intelligent-Tiering after 30 days and abort incomplete multipart uploads after 7 days.