Feature request: Change ordering of default log formatter

[bilalq]

Use case

I know that users can provide their own LogFormatter instance, but the I believe the default should still be reasonably well-suited for most people.

The problem today is that the output frontloads a bunch of noise that isn't useful and makes the CloudWatch console log stream view useless without expanding and hard to read/skim even when you do.

At a glance, all you see is whether or not an invocation was a cold start and the ARN. Actually interesting information like log level and message are buried.

Solution/User Experience

Technically, V8 and every other JS engine I'm aware of don't guarantee ordering of JS object literals when serializing/deserializing. In practice, when the object key counts are not high, the order as written does get preserved.

If we look here:

https://github.com/aws-powertools/powertools-lambda-typescript/blob/main/packages/logger/src/formatter/PowertoolLogFormatter.ts#L19-L33

Changing:

    return {
      cold_start: attributes.lambdaContext?.coldStart,
      function_arn: attributes.lambdaContext?.invokedFunctionArn,
      function_memory_size: attributes.lambdaContext?.memoryLimitInMB,
      function_name: attributes.lambdaContext?.functionName,
      function_request_id: attributes.lambdaContext?.awsRequestId,
      level: attributes.logLevel,
      message: attributes.message,
      sampling_rate: attributes.sampleRateValue,
      service: attributes.serviceName,
      timestamp: this.formatTimestamp(attributes.timestamp),
      xray_trace_id: attributes.xRayTraceId,
    };

To something like this:

    return {
      level: attributes.logLevel,
      message: attributes.message,
      function_request_id: attributes.lambdaContext?.awsRequestId,
      xray_trace_id: attributes.xRayTraceId,
      service: attributes.serviceName,
      function_arn: attributes.lambdaContext?.invokedFunctionArn,
      function_memory_size: attributes.lambdaContext?.memoryLimitInMB,
      function_name: attributes.lambdaContext?.functionName,
      sampling_rate: attributes.sampleRateValue,
      timestamp: this.formatTimestamp(attributes.timestamp),
      cold_start: attributes.lambdaContext?.coldStart,
    };

Would likely be a lot more usable. This brings the log level, message, and execution ids to the forefront.

With regards to backwards compatibility: No promised API or contractual behavior changes. Technically, if a user had regex based parsing of log lines, that may break. However, I'd argue that given the JS engine already doesn't guarantee order preservation, such a dependency never had guarantees to begin with and should not be considered breakage of backwards compatibility.

Alternative solutions

No response

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[bilalq]

I'm happy to submit a PR for this if the team would be okay to merge it. Also open to hearing feedback on the ordering. My rationale for putting log level first is that it makes it easy to visually scan and see which log entries are for errors vs info vs debug. After that, the message is the most important attribute, IMO. The request and trace ids are then the most useful bits for pulling additional context around a given log line.

[dreamorosi]

Hi @bilalq thank you for taking the time to open an issue.

As you mentioned, we can't guarantee the order of the keys so if my memory serves me correctly, we simply ordered the keys alphabetically when creating the formatter.

I'm okay with changing the ordering as you suggested in your second code example and have level, message, and function_request_id at the front, so if the offer of opening a PR is still valid I'd be happy to review it and help merge it.

As a side note, the Python version of Powertools has level, location, message, and timestamp at the front but also allows customers to override the key position without having to write their own formatter via the log_record_order constructor parameter. I think in the future we should consider having a similar property as well, but this is out of the scope of this issue.

[bilalq]

One correction from the issue description: JSON.stringify serialization does have a well-defined order post ES5.