fix(logger): change logging to use stdout

[dreamorosi]

Description of your changes

As reported by user @olanb7 on the community Slack and in #747 before this PR Logger would output logs like this:

2022-04-08T10:58:44.811Z	b6511ee9-4873-404e-b60c-a23cb45d3ff2	INFO {"cold_start":false,"function_arn":"arn:aws:lambda:eu-west-2:12345:function:test","function_memory_size":1024,"function_name":"test","function_request_id":"b6511ee9-4873-404e-b60c-a23cb45d3ff2","level":"INFO","message":"test message","service":"test","timestamp":"2022-04-08T10:58:44.811Z"}

These logs, although containing a structured JSON, are not JSON as they are always prefixed by 2022-04-08T10:58:44.811Z b6511ee9-4873-404e-b60c-a23cb45d3ff2 INFO.

This also confirmed by a line in the Lambda docs (emphasis mine):

The Node.js runtime logs the START, END, and REPORT lines for each invocation. It adds a timestamp, request ID, and log level to each entry logged by the function.

This behaviour works well with CloudWatch but the presence of these prefixes was an issue for customers wanting to use these structured logs elsewhere (both 3rd party services and AWS Managed Grafana).

From this PR onwards Logger will be using its own internal and private version of the Console class that only outputs the structured JSON log without any prefix:

{"cold_start":false,"function_arn":"arn:aws:lambda:eu-west-2:12345:function:test","function_memory_size":1024,"function_name":"test","function_request_id":"b6511ee9-4873-404e-b60c-a23cb45d3ff2","level":"INFO","message":"test message","service":"test","timestamp":"2022-04-08T10:58:44.811Z"}

Aside from 3-lines change in the Logger class, all the rest of the changes in this PR are related to the unit and integration tests.

How to verify this change

See the results of checks inside this PR and e2e tests (to be run).

Also see screenshot below:

Related issues, RFCs

#747

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

N/A

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[dreamorosi]

e2e test results here (passing) https://github.com/awslabs/aws-lambda-powertools-typescript/actions/runs/2162686619

[ijemmy]

Thanks for cleaning up those small things.

I have one question just to double check.

[ijemmy]

Why double cast? Is this intentional?

[dreamorosi]

It's only to please the TypeScript compiler.

If doing null as boolean it would give me this error:

error TS2352: Conversion of type 'null' to type 'boolean' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

jest.spyOn(process.stdout, 'write').mockImplementation(() => null as boolean);

[ijemmy]

Got it. Thanks.

[flochaz]

LGTM

[mrerichoffman]

I'm curious does this change break tracing in cloudwatch? I thought that the default console log formatting is used to correlate logs across requests in cloudwatch tracing and x-ray.

[dreamorosi]

Hi @mrerichoffman, thanks for the message. I think I have an idea of what you're referring to but I'd like to make sure we are on the same page.

Would you mind please opening and elaborating on what you're (not) seeing and what you're expecting to see and where? This would also help others find the same issue in the future since this is an old PR.

Thank you!