LogDNA agent

Troubleshooting becomes harder when the relevant log files are scattered across machines and short-lived application containers. The LogDNA agent collected those files and sent their records to a central logging service, adding context to help identify where they came from. It was the collection component, not the database used to search logs. Current upstream documentation uses the Mezmo name, so existing installations need to distinguish old packaging from the supported agent configuration.

Current guidance

The historical chart identified logdna/logdna-agent-v2 and packaged an older LogDNA collector. That community chart is deprecated. The upstream agent repository documents the transition to Mezmo naming, including changes to environment-variable prefixes across releases. Preserve the old project identity when auditing an existing installation, then choose the exact supported agent release and instructions for its target service.

This is a log shipping agent rather than a standalone log database. Check the ingestion destination, credentials, file and journald sources, Kubernetes metadata enrichment and redaction settings. A node-level deployment may read logs from many tenants, so scope access and exclusion rules deliberately. Review how non-root operation interacts with log-file permissions and persistent agent state.

Upgrade testing should cover a rotated file, a restarted agent, multiline records and temporary network loss. The upstream documentation describes lookback and statefulness; changing those settings can change which existing lines are resent or skipped. Measure delivery and resource use with representative files before replacing the old DaemonSet. A running pod and accepted API key are not evidence that every application log arrives once or that the historical chart is safe for current clusters.