Skip to main content

Logging

Both Workers and Load Balancer include a built-in logging system for monitoring, debugging, and auditing.

Where are logs stored?​

  • In-memory: Logs are kept in memory (RAM) up to a configurable limit (MAX_LOGS in your .env).
  • /logs endpoint: You can retrieve the latest logs via the /logs endpoint (requires authentication).
  • Console: All logs are also printed to the standard output (console), so you can collect them with Docker, systemd, or any log aggregation tool.

How to access logs​

  • Worker:
    • GET /logs (requires Authorization header)
  • Load Balancer:
    • GET /logs (requires Authorization header)
    • The dashboard can also display logs for each Worker.

Log levels and methods​

You can use the following methods in your code (imported from @andera-top/worker-core/dist/utils/logger for Workers, or from ./utils/logger for the Load Balancer):

  • log(...) – Info-level logs (default)
  • warn(...) – Warnings
  • error(...) – Errors
  • debug(...) – Debug-level logs (if enabled)

Example usage in a Worker function:

import { log, warn, error, debug } from '@andera-top/worker-core/dist/utils/logger'

log('[MYFUNC]', 'Function started')
warn('[MYFUNC]', 'This is a warning')
error('[MYFUNC]', 'Something went wrong')
debug('[MYFUNC]', 'Debug details:', { foo: 42 })

Log configuration​

  • Log level: Set LOG_LEVEL in your .env to control verbosity (debug, info, warn, error).
  • Max logs: Set MAX_LOGS to control how many log lines are kept in memory (default: 1000).

Best practices​

  • Use log levels appropriately: log for normal events, warn for recoverable issues, error for failures, debug for detailed troubleshooting.
  • Use clear prefixes (e.g., [MYFUNC], [SERVICE]) to make logs easy to filter.
  • Aggregate logs with your favorite tool (Docker, systemd, ELK, etc.) for long-term storage and analysis.