feat(lambda): support for advanced logging #28039
Conversation
otaviomacedo
added
the
pr/do-not-merge
otaviomacedo
removed
the
pr/do-not-merge
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
| * Sets the logFormat for the function. | ||
| * @default Text format | ||
| */ | ||
| readonly logFormat?: string; |
There was a problem hiding this comment.
Why is this not typed (enum)? Same for log level.
(there's still time to change this before it becomes a breaking change)
There was a problem hiding this comment.
A breaking change can be avoided by setting the type to LogFormat | keyof typeof LogFormat which would allow using either the enum or type-safe strings as the value.
Suggested change in #28127 which aims to solve this.
There was a problem hiding this comment.
Thank you for your suggestion.
if LogFormat type is changed to logFormat?: LogFormat | keyof typeof LogFormat;, An error like the following occurs in the code: logFormat: 'Text'.
Type '"Text"' is not assignable to type 'LogFormat | "TEXT" | "JSON" | undefined'. Did you mean '"TEXT"'?ts(2820)
Would you mind telling me a solution that accepts both lambda.LogFormat.TEXT and string 'Text'.
There was a problem hiding this comment.
I might solve this problem by myself. I suggest changes in #28127.
…up` (#28737) #28039 introduced support for custom logging configurations for AWS Lambda Functions. This change deprecates the `logRetention`, `logRetentionRole` and `logRetentionRetryOptions` properties in favor of using a custom logging configuration. By default, Lambda functions send logs to an automatically created default log group named `/aws/lambda/<function name>`. However you cannot change the properties of this auto-created log group using the AWS CDK, e.g. you cannot set a different log retention. To overcome the limitation, a custom resource was introduced and configuration exposed via the `logRetention` properties. This is what we are deprecating in this change. With the introduction of custom logging configuration and the new `logGroup` property, users can now create a fully customizable `LogGroup` ahead of time, and instruct the Lambda function to send logs to it. Migrating from `logRetention` to `logGroup` will cause the name of the log group to change. Don't attempt to use the name of the auto-created log group, this will cause subtle issue. We recommend using auto-naming for lambda log groups, they can easily be accessed via the Lambda Console. If you want use a well-known name, we recommend using a pattern like `/<your service>/lambda/<function name>`. Be aware that a names log group can prevent a stack from being recreated without manual intervention after it has been deployed (error `Resource already exists`). This is because `LogGroups` are retained by default. Either way, users will have to adjust and documentation will need to be updated. Any code referencing the old log group name verbatim will have to be changed as well. Keep in mind that in AWS CDK code, you can access the log group name directly from the `LogGroup` construct: ```ts declare const myLogGroup: logs.LogGroup; myLogGroup.logGroupName; ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Structured logging enables automated analysis of the logs, thus enables customers to perform quick exploratory and automated monitoring the health of their applications, and helps them troubleshoot their production issues faster. Structured logging is now considered to be a monitoring best practice.
Lambda is developing Advance Logging Controls to give developers and operators more control over their function logs. The feature allows customers to capture logs in JSON format and control the level of details in emitted logs. To ensure compatibility and enable these capabilities, four new fields (LogFormat, ApplicationLogLevel, SystemLogLevel, and LogGroup) will be added to the existing LoggingConfig structure. Also, even adding custom log group for Log group section to have the flexibility of changing the name instead of having it as default. This update empowers customers to define their logging behavior and efficiently manage their function logs, reflecting Lambda's commitment to delivering a user-friendly logging solution that addresses the evolving needs of users.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license