Database Log Forwarding

TL;DR — Open the Logs tab on a cluster to forward database logs (slow queries, connection events, errors) to your existing observability stack. Four destinations are supported: Datadog, OpenSearch, Papertrail, and rsyslog.

Why Forward Logs

The managed-database dashboard shows you metrics and a high-level event timeline, but for deep debugging — slow queries, lock waits, authentication failures — you need engine-level logs streamed to a log aggregator. Forwarding lets you:

• Search and alert on slow query patterns
• Correlate database events with application traces
• Retain logs longer than the engine's local buffer
• Hook logs into your existing incident-response pipeline

Where to Configure

1. Open your cluster
2. Click the Logs tab

You'll see:

• Destinations — every configured log sink
• Add destination — form to add another sink
• Recent cluster events — a scrolling event feed (provisioning, resize, backup, etc.) regardless of forwarding

Supported Destinations

1. Datadog

After saving, logs appear in Datadog Log Explorer with the service:database tag and cluster name. Pick the correct endpoint for your Datadog site to avoid cross-region transfer.

2. OpenSearch

The destination can be your own EasyCloudify-managed OpenSearch cluster — give the forwarding user write on the matching index pattern.

3. Papertrail

Logs land in your Papertrail dashboard tagged with the cluster name. Use Papertrail's UI for search and alerting.

4. rsyslog

For TLS, your rsyslog server must present a publicly trusted certificate (or one whose CA is widely recognised). Self-signed CAs aren't supported.

Add a Destination

1. From Add destination:
   • Pick a Type from the dropdown
   • Fill in the destination-specific fields (form fields change with the type)
2. Click Add destination

Logs start flowing within a minute. Credentials (API keys, passwords) are stored encrypted and never displayed in the dashboard after save.

Delete a Destination

Click the trash icon on the destination row. Forwarding stops immediately. Already-delivered logs remain in the destination.

What Gets Forwarded

The forwarded log stream includes (engine-dependent):

• Connection events — successful and failed authentication
• Slow queries — based on engine threshold (log_min_duration_statement for PostgreSQL)
• Error logs — fatal and warning-level engine messages
• Replication events — for replicas
• Maintenance events — patching, restarts

Use destination-side filters or queries to narrow the stream.

Read the Recent Cluster Events

Even without log forwarding, the Logs tab shows a scrollable feed of recent cluster events:

• Timestamp
• Event type (e.g. cluster_create, cluster_resize, cluster_backup)
• Human-readable label (e.g. Configuration Updated, Backup Taken)
• Colour coding by event kind

For a longer timeline of cluster lifecycle changes, see the Database Events tab.

Replicas Have Their Own Forwarding

Read replicas have independent log forwarding configuration. Set them up separately on each replica's Logs tab. This lets you, for example, send analytics-replica logs to a different team's Datadog account.

Best Practices

1. Forward to the same region as your destination. Cross-region forwarding adds latency and may cross data residency boundaries.
2. Use a least-privilege user. When forwarding to OpenSearch, the user only needs write on the matching index pattern.
3. Set sensible retention. Indefinite retention is expensive; 30–90 days is usually plenty for postmortems. Archive longer-term data to cold storage if you need it.
4. Test the destination before relying on it. Trigger a known event (e.g. failed login) and confirm it lands in the destination.
5. Alert on the absence of logs in your destination — silent failures are worse than noisy ones.

Troubleshooting

Logs aren't appearing in Datadog

• Double-check the endpoint URL matches your Datadog site (US, EU, US3, etc.)
• Verify the API key is valid in Datadog → Organization Settings → API Keys
• Wait a few minutes after adding the destination — the first batch takes ~60s

OpenSearch authentication fails

The destination expects HTTPS Basic Auth credentials. Verify the user can curl-PUT to the index from a separate machine. Self-signed certificates on OpenSearch are not supported — use a managed OpenSearch cluster or a public CA-signed cert.

Papertrail logs show "rejected"

Check that the destination port matches what Papertrail issued — each Papertrail destination has its own port.

rsyslog TLS handshake fails

TLS-enabled forwarding requires a publicly trusted certificate on your rsyslog server. Switch to a Let's Encrypt cert or open a support ticket if you need a private CA.

How do I stop forwarding temporarily?

Delete the destination. There is no pause/resume — forwarding stops the moment the row is removed.

Related Guides

• Database Monitoring & Performance Insights
• Database Events Timeline
• Database Read Replicas
• Maintenance & Scaling