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).

1. 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.