CloudWatch orders logs by their received time, not the timestamp in the log line about lesslog HOT 4 CLOSED

Thanks for reaching out. As you correctly pointed out, the Timestamp column in CW shows the time that particular log output reached CW. IIRC there is the ability to put log events to CW using its API, which allows the timestamp to be specified (see https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html). However, personally I don't know of a way to override the Timestamp when streaming logs from stderr or stdout to CW.

Not sure, if I understand you correctly, but maybe the following could help: If you merely want to sort the logs by another value, you could include the timestamp when the log was emitted as part of the log context. That should enable you to sort messages in CW Logs Insights accordingly.

from lesslog.

Thanks for the response. I am mostly working with code running in Lambdas, so we're taking advantage of the default behavior of stdout and stderr from the containers being forwarded to CW. That mechanism doesn't expose any way for me to customize the log events being created to the best of my knowledge, as you say. I suppose I could make a logging library that writes to CW directly, instead of using stdout, but that feels pretty heavy handed.

At the moment I'm leaning towards looking for a richer log platform that will let me aggregate easily from multiple Lambdas, and pull the timestamp directly from the log line.

from lesslog.

Have you looked at CloudWatch Logs Insights yet? It might actually serve your purpose well. And since it's based on the CloudWatch logs there is no overhead of re-ingesting or submitting log messages elsewhere. Lesslog allows you to enrich your log messages with contextual information that is formatted in a way that Logs Insights is able to parse. Which allows you to filter, sort, group and search based on information in that context.

from lesslog.

I've looked at it just a little bit. At first glance it appeared that the @timestamp field still comes from event metadata in CW, not the contents of the log line itself. Parsing custom fields appears limited to JSON format logs.

EDIT: Oh, I missed a critical part of your statement, actually. I'll have a further look at your "context" feature and dig into that. If that will create an entry that insights can parse, maybe I can indeed use it to get some mileage. Thanks :-)

from lesslog.