onboard: single-trunk Execute Release workflow (main) (#365)
onboard: single-trunk Execute Release workflow (main)
security: harden execute-release.yml per zizmor
- Route AutoVer release tag/name through env vars in the GitHub release step (avoids template-injection via ${{ steps.* }} in a run block).
- Suppress artipacked on Checkout: persist-credentials must stay true so the deploy-key git config survives for the version/changelog push.
- chore: remove retired dev branch references from workflows
Co-authored-by: Garrett Beatty beattyg@amazon.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
AWS Logging .NET
This repository contains plugins for popular .NET logging frameworks that integrate with Amazon Web Services. The plugins use the Amazon CloudWatch Logs service to write log data to a configured log group. The logs can be viewed and searched using the AWS CloudWatch Console.
For a history of releases view the release change log
AWS Lambda
These packages batch logging messages in a queue and send messages to CloudWatch Logs using a background thread. The use of the background thread means that the messages are not guaranteed to be delivered when used in AWS Lambda. The reason is because the background thread will be frozen once a Lambda event is processed and may not ever be unfrozen if more Lambda events are not received for some time.
When using Lambda it is recommended to use either the
ILambdaContext.Logger.LogLineor the Amazon.Lambda.Logging.AspNetCore package.Required IAM Permissions
Regardless of the framework used, the following permissions must be allowed (via IAM) for the provided AWS credentials.
The practice of granting least privilege access is recommended when setting up credentials. You can further reduce access by limiting permission scope to specific resources (such as a Log Stream) by referencing its ARN during policy creation.
For more information and a sample JSON policy template, please see Amazon CloudWatch Logs and .NET Logging Frameworks on the AWS Developer Blog.
Optional IAM Permissions
The following IAM permissions are optional depending on the configured features of the logger.
logs:PutRetentionPolicyNewLogGroupRetentionInDaysConfiguring the Log Stream Name
Prior to the versions listed below, these libraries followed CloudWatch Logs’ best practice of having the log stream name be generated. The name could be customized by adding a suffix or prefix using the
LogStreamNameSuffixandLogStreamNamePrefixconfiguration properties.Generating the name ensured that each process within an application has its own log stream to write to. Otherwise when one process writes to the same stream, the
sequenceTokenmaintained within the process goes out of sync. This generated errors and retries causing performance issues.In 2023 CloudWatch Logs removed the SequenceToken requirement, which removes the need to split log ingestion across multiple log streams and coordinate the sequence token across multiple clients.
The following versions introduce a new
LogStreamNamesetting, which can be used to specify the full log stream name. When this is setLogStreamNamePrefixandLogStreamNameSuffixwill be ignored.Setting new Log Group Retention Policy
These libraries support setting a log retention policy on any CloudWatch Log Groups which they create. This feature is enabled using the NewLogGroupRetentionInDays configuration property. The DisableLogGroupCreation configuration property must not be set to true. Retention policies configured in this manner are only applied to new Log Groups created directly by these libraries. By default no retention policy is applied to newly created Log Groups.
Note that any value of NewLogGroupRetentionInDays which is not one supported by CloudWatch which can be found here - and listed below - is a configuration error which will result in a non-fatal error applying the policy. The application and logging will continue however no retention policy will be applied.
Supported Logging Frameworks
NLog
NLog uses targets that can be configured to receive log messages. Targets can be configured either through a config file or through code. The default config file that NLog will automatically search for is NLog.config. Here is an example config file that configures the AWS Region and the CloudWatch Logs log group.
The AWS credentials will be found using the standard AWS SDK for .NET credentials search path. In this case it will look for a profile named default, search for environment variables or search for an instance profile on an EC2 instance. To use a specific AWS credential profile use the profile attribute on the target.
Here is an example of performing the same configuration via code.
Checkout the NLog samples for examples on how you can use AWS and NLog together.
Apache log4net
Log4net configures appenders to receive log messages. Appenders can be configured either through a config file or through code. To use a config file add a file to your project. The file can be named anything but for this example call it log4net.config. Make sure that Copy to Output Directory is set to copy. Here is an example config file setting the CloudWatch Log log group and the AWS Region.
The AWS credentials will be found using the standard AWS SDK for .NET credentials search path. In this case it will look for a profile named default, search for environment variables or search for an instance profile on an EC2 instance. To use a specific AWS credential profile add a Profile under the appender node.
Add the following code during the startup of the application to have log4net read the configuration file.
Here is an example of performing the same configuration via code.
Checkout the Log4net samples for examples of how you can use AWS and log4net together.
ASP.NET Core Logging
ASP.NET Core introduced a new logging framework that has providers configured to send logs to destinations. The AWS.Logger.AspNetCore NuGet package provides a log provider which adds CloudWatch Logs as a destination for the logs.
Note: Starting with version 2.0.0 of AWS.Logger.AspNetCore this library targets netstandard2.0 and the dependencies have been upgraded to the ASP.NET Core 2.1 versions. For older versions of .NET Core, which Microsoft has made end of life, use versions before 2.0.0.
The WebSample in this repository demonstrates how to configure this provider.
The configuration is setup in the appsettings.json file. In versions before 2.0.0 the
AWS.Loggingwas used as the configuration section root. Starting with 2.0.0 the library has switched to use the standardLoggingconfiguration section root. For backwards compatibility if theLoggingsection does not contain aLogGroupthen the library will fallback toAWS.Logging.In a typical ASP.NET Core application the
Program.csfile contains aCreateWebHostBuildermethod. To include AWS.Logger.AspNetCore add a call toConfigureLoggingand in theAction<ILoggingBuilder>passed into ConfigureLogging callAddAWSProvider. This will look up the configuration information from the IConfiguration added to the dependency injection system.Serilog
Serilog can be configured with sinks to receive log messages either through a config file or through code. To use a config file with Serilog, follow the instructions here to install the necessary extensions and NuGet packages. In the json file, make sure AWS.Logger.SeriLog is in the Using array. Set the LogGroup and Region under the Serilog node, and add AWSSeriLog as a sink under the WriteTo node. Here is an example.
Add the following code to configure the logger to read from the json file.
The AWS Credentials will be found using the standard .NET credentials search path. It will search for a profile named default, environment variables, or an instance profile on an EC2 instance. In order to use a profile other than default, add a Profile under the Serilog node.
Below is an example of doing the same configuration as above via code. The AWS sink can be added to the logger by using the WriteTo method.
Checkout the Serilog samples for examples of how you can use AWS and Serilog together.