Logz.io CloudWatch shipper misparses NodeJS Lambda logs (no log level)

TL;DR: if the Logz.io CloudWatch shipper mangles NodeJS Lambda logs, the parser assumed the 3-part Python format (timestamp, requestID, message) but NodeJS lines have 4 parts including the log level. Upgrade the shipper to a version containing the PR #42 fix; the maintainer confirmed AWS Lambda log formats differ per runtime.

Steps

1. Upgrade the Logz.io CloudWatch logs shipper past PR #42.

   Expected: the parser handles the 4-part NodeJS format (timestamp, requestID, logLevel, message).

2. Send fresh NodeJS Lambda invocations and check Logz.io.

   Expected: log levels parse correctly and START/END/REPORT lines are ignored again. Success check: NodeJS logs look as clean as the Python ones.

When to use this

• NodeJS Lambda logs arrive misparsed in Logz.io while Python function logs are fine.
• START/END/REPORT lines leak through instead of being filtered.

When NOT to use this

• All runtimes misparse; check the shipper config instead.
• Logs never arrive at all; that is a delivery problem.

Compatibility

• Logz.io CloudWatch logs shipper with the PR #42 fix; mixed-runtime (NodeJS + Python) setups.

Variant phrasings

• "logzio lambda nodejs logs misparsed"
• "logz.io cloudwatch shipper log level missing"

Root cause

AWS Lambda log formats differ per runtime, and the parser had only been tested against the Python 3-part format. On NodeJS functions the log level landed in the message slot and the real message shifted, while the START/END/REPORT filter missed.

Edge cases

• The reporter-verified local workaround was changing the parse to 4 parts by hand, but upgrading is the real fix; do not fork the parser.

In the thread Logz.io CloudWatch shipper misparses NodeJS Lambda logs (no log level), the question was: The Logz.io CloudWatch logs shipper parses AWS Lambda log lines assuming a 3-part format (timestamp, requestID, message), but NodeJS Lambda logs have a 4-part format that includes the log level. On NodeJS functions the shipper misparses the log level, and the START/END/REPORT lines still get through instead of being ignored. The verified resolution: The maintainer confirmed this: AWS Lambda logs differ per runtime, and the parser had only been tested against the Python format. The reporter-verified local fix changed the parse to 4 parts (timestamp, requestID, logLevel, message); the permanent fix was merged in PR #42, so upgrading the shipper is the real fix for mixed-runtimes setups. Original discussion: https://vectle.com/threads/thrvL6FFCjhneY7dnAWek6Ug