Log Management: Centralized Logging for Web Applications

Why Logs Matter

Every running application produces a stream of events: requests received, queries executed, errors thrown, jobs completed. These events — your logs — are the most detailed record of what your application actually did at runtime.

The problem is that in a modern deployment with multiple services, containers, and environments, logs are scattered. Chasing them across servers wastes time during the worst possible moment: when something is broken and users are waiting.

Centralized log management solves this by aggregating all log output into a single, searchable location.

The Anatomy of a Good Log Entry

Not all logs are equally useful. A raw print statement might tell you *something* happened; a structured log entry tells you *what* happened, *when*, *where*, and in what *context*.

A good log entry includes:

• Timestamp — Always in UTC, always precise to milliseconds
• Log level — ERROR, WARN, INFO, DEBUG
• Service/component name — Which part of your system generated this
• Message — Human-readable description of the event
• Structured context — Key-value pairs like user_id, request_id, duration_ms

Structured logging (JSON format) is strongly preferred over plain text because it can be queried and filtered programmatically.

Log Levels: Using Them Correctly

In production, run at INFO level. DEBUG output is too noisy and can expose sensitive data.

Centralized vs. Distributed Logging

With a single application on a single server, you can SSH in and tail logs. But this approach breaks down the moment you have:

• Multiple container replicas running the same service
• Multiple services (API server, background worker, edge functions)
• Ephemeral infrastructure that gets replaced on every deploy

Centralized logging pulls all of this output into one place. Instead of SSHing into containers, you query a log store.

What to Log in Web Applications

Request/Response Cycle

Log every inbound request with the HTTP method, path, status code, and response time. This gives you an audit trail and makes it easy to correlate user-reported issues with specific requests.

Application Errors

Unhandled exceptions should always produce an ERROR log with the full stack trace. Don't swallow exceptions silently — if something broke, you need to know.

Background Jobs and Cronjobs

Log when a job starts, when it completes, and how long it took. If you're running cronjobs on a schedule (as PandaStack supports), you want to know immediately if a job fails or runs longer than expected.

Database Queries

Slow queries are often the root cause of performance problems. Log queries that exceed a threshold (e.g., 500ms) with the full query text and execution time.

Authentication Events

Log login attempts, failures, and token refreshes. These events are critical for security auditing.

Structuring Logs Across Services

If you're deploying multiple services on PandaStack — for example, a Docker container for your API, a PostgreSQL database, and edge functions via OpenWhisk — each service will produce its own logs. The key is consistency:

• Use the same structured format across all services
• Include a service field so you can filter by component
• Include a request_id or trace_id that spans multiple services for a single user action

This makes it possible to reconstruct the full journey of a request even when it touches multiple services.

Log Retention and Storage

You don't need to keep logs forever, but you do need to keep them long enough to:

• Debug issues that surface days after they occur
• Satisfy compliance requirements (audit logs often have 90-day or 1-year requirements)
• Analyze trends and patterns

A common approach: keep raw logs for 30 days, aggregate metrics indefinitely.

Alerting on Logs

Logs aren't just for post-incident debugging — they can drive real-time alerts. Set up alerts to fire when:

• ERROR log rate spikes above a threshold
• A specific error message appears (e.g., "database connection refused")
• A critical job produces no output (silent failure)

PandaStack supports alerting via email, Slack, and webhooks, which you can pair with log-driven triggers from your monitoring setup.

Conclusion

Centralized log management transforms debugging from a painful scavenger hunt into a focused query. Start by structuring your logs consistently, ensure all your services write to a centralized location, and pair your log setup with uptime alerts. For more on deploying and monitoring applications on PandaStack, visit [docs.pandastack.io](https://docs.pandastack.io).