Logging: Design all up logging approach #218
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-cleanup
Milestone
Comments
rowanmiller
changed the title
divega
changed the title
divega
changed the title
divega
changed the title
23 tasks
|
We made some progress for beta but we'll keep this item active to track further work. |
|
Please keep me, @sonjakhan, @davidfowl, and @lodejard in the loop on this because I would like @sonjakhan to produce some guidance for the team as a whole as part of the core Logging work. We'd like to learn where each sub-team sees value in logging, and generalize it. |
divega
changed the title
|
We had an all up aspnet brownbag on this the other day |
rowanmiller
changed the title
ajcvickers
added a commit
that referenced
this issue
Mar 14, 2017
Issues #6924 #218 This change allows ILogger to be a singleton service and hence services that need to do logging no longer need to be scoped services. The end result turned out a bit different from discussed in #218, but follows essentially the same principles. The singleton configuration API wasn't turning out well, so I switched to extending the mechanism we already have for building new service providers as necessary. This means that, when EF is managing the internal service provider, all the options work as before, but if the app changes, for example, the warnings config, then this may require a new service provider to be built. (I added a warning if more than 20 service providers are built as a heuristic against applications doing crazy stuff where the service provider is being rebuilt all the time.) There are a few more restrictions when the internal service provider is being controlled by the application: * For options that are directly services (ILoggerFactory, IMemoryCache) the application must configure them directly in the internal service provider. This removes the need for any re-direction. * For other options, they can only be configured once per service provider, as was discussed in the design meeting. At the moment this is only the logging options, but it could be used for other options if necessary going forward. Also included here is some re-shaping of the OptionsExtensions classes to bake in their immutable nature and make it harder to accidentally mutate them. WarningsConfiguration was previously mutating, and this has been updated to not mutate. Also, WarningsConfiguration and CoreOptionsExtension are needed by providers, and hence these have now been moved to a public namespace.
ajcvickers
added a commit
that referenced
this issue
Mar 14, 2017
Issues #6924 #218 This change allows ILogger to be a singleton service and hence services that need to do logging no longer need to be scoped services. The end result turned out a bit different from discussed in #218, but follows essentially the same principles. The singleton configuration API wasn't turning out well, so I switched to extending the mechanism we already have for building new service providers as necessary. This means that, when EF is managing the internal service provider, all the options work as before, but if the app changes, for example, the warnings config, then this may require a new service provider to be built. (I added a warning if more than 20 service providers are built as a heuristic against applications doing crazy stuff where the service provider is being rebuilt all the time.) There are a few more restrictions when the internal service provider is being controlled by the application: * For options that are directly services (ILoggerFactory, IMemoryCache) the application must configure them directly in the internal service provider. This removes the need for any re-direction. * For other options, they can only be configured once per service provider, as was discussed in the design meeting. At the moment this is only the logging options, but it could be used for other options if necessary going forward. Also included here is some re-shaping of the OptionsExtensions classes to bake in their immutable nature and make it harder to accidentally mutate them. WarningsConfiguration was previously mutating, and this has been updated to not mutate. Also, WarningsConfiguration and CoreOptionsExtension are needed by providers, and hence these have now been moved to a public namespace.
Proposal for logging categoriesNotes:
Categories:
|
|
Updated categories above based on design meeting discussion. Only change was to remove the .Design subcategory since it was deemed unnecessary. |
ajcvickers
added a commit
that referenced
this issue
Apr 12, 2017
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
ajcvickers
added a commit
that referenced
this issue
Apr 13, 2017
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
ajcvickers
added a commit
that referenced
this issue
Apr 13, 2017
Issues #7217 #218 This change: * Consolidates interception and sensitive logging into one service and uses that service everywhere in the EF code. * Adds a LoggerCategory class which contains nested classes that define EF logging categories. * Used together, this means any EF service can depend on `IInterceptingLogger<TLoggingCategory>` and have D.I. fill create the correct service using its open generics feature. The TLoggingCategory is constrained so that only types specifically defined as LoggingCategories can be used. For example, `IInterceptingLogger<LoggingCategory.Database.Sql>`. * Application code can get logging categories using, for example, `LoggingCategory.Database.Sql.Name`. This means that any application can immediately see in code what logging categories there are to do appropriate filtering. * All services depend on the specific generic `IInterceptingLogger<TLoggingCategory>` that they will use--never ILogger. This makes it very clear which category is being logged to and makes it safe to share loggers where safe, and impossible where the categories should be different.
ajcvickers
added a commit
that referenced
this issue
Apr 26, 2017
…cSource Issues #218 #6802 (Doesn't cover #6946 - Template-based format strings.) This change introduces unique event IDs and a pattern such that every time an event is logged it is sent to both ILogger and DiagnosticSource. Specifically: * EventIds are globally unique across core/relational/any given provider. (As discussed in #218) * The same EventIds are used for ILogger and DiagnosticSource (ILogger uses the int/name tuple, DiagnosticSource uses just the name) * EventIds align with logger categories * Automated tests for the EventId/LoggerExtensions pattern--every EventId has a LoggerExtension method that works as expected. * Warnings configuration is updated to use the new event ids * Updated IsEnabled to handle warnings as errors and ignored warnings more transparently.
ajcvickers
added a commit
that referenced
this issue
Apr 26, 2017
…cSource Issues #218 #6802 (Doesn't cover #6946 - Template-based format strings.) This change introduces unique event IDs and a pattern such that every time an event is logged it is sent to both ILogger and DiagnosticSource. Specifically: * EventIds are globally unique across core/relational/any given provider. (As discussed in #218) * The same EventIds are used for ILogger and DiagnosticSource (ILogger uses the int/name tuple, DiagnosticSource uses just the name) * EventIds align with logger categories * Automated tests for the EventId/LoggerExtensions pattern--every EventId has a LoggerExtension method that works as expected. * Warnings configuration is updated to use the new event ids * Updated IsEnabled to handle warnings as errors and ignored warnings more transparently.
ajcvickers
added a commit
that referenced
this issue
Apr 27, 2017
…cSource Issues #218 #6802 (Doesn't cover #6946 - Template-based format strings.) This change introduces unique event IDs and a pattern such that every time an event is logged it is sent to both ILogger and DiagnosticSource. Specifically: * EventIds are globally unique across core/relational/any given provider. (As discussed in #218) * The same EventIds are used for ILogger and DiagnosticSource (ILogger uses the int/name tuple, DiagnosticSource uses just the name) * EventIds align with logger categories * Automated tests for the EventId/LoggerExtensions pattern--every EventId has a LoggerExtension method that works as expected. * Warnings configuration is updated to use the new event ids * Updated IsEnabled to handle warnings as errors and ignored warnings more transparently.
ajcvickers
added a commit
that referenced
this issue
Apr 27, 2017
…cSource Issues #218 #6802 (Doesn't cover #6946 - Template-based format strings.) This change introduces unique event IDs and a pattern such that every time an event is logged it is sent to both ILogger and DiagnosticSource. Specifically: * EventIds are globally unique across core/relational/any given provider. (As discussed in #218) * The same EventIds are used for ILogger and DiagnosticSource (ILogger uses the int/name tuple, DiagnosticSource uses just the name) * EventIds align with logger categories * Automated tests for the EventId/LoggerExtensions pattern--every EventId has a LoggerExtension method that works as expected. * Warnings configuration is updated to use the new event ids * Updated IsEnabled to handle warnings as errors and ignored warnings more transparently.
ajcvickers
added a commit
that referenced
this issue
May 13, 2017
Issue #6946 The T4 template for resource strings has been updated so that if the resource name starts with "Log", then we generate an EventDefinition using information from the comment section. This brings together the event ID, log-level, and a typed, cached delegate that can be called to log the event to an ILogger. It also contains a mechanism to generate the message for use when testing and when throwing warnings-as-errors. All the XxxLoggerExtensions class now use this mechanism. As part of this, IInterceptingLogger was consolidated into IDiagnosticsLogger. There are no longer any Log methods here because logging is done through the definitions using the cached delegates. A fallback mechanism--RawEventDefinition--can be used for messages with more than six parameters. There are only a handful of these, and they are for design-time scenarios and so don't need to be super fast. Part of #218 Also, see #8456
ajcvickers
added a commit
that referenced
this issue
May 15, 2017
Issue #6946 The T4 template for resource strings has been updated so that if the resource name starts with "Log", then we generate an EventDefinition using information from the comment section. This brings together the event ID, log-level, and a typed, cached delegate that can be called to log the event to an ILogger. It also contains a mechanism to generate the message for use when testing and when throwing warnings-as-errors. All the XxxLoggerExtensions class now use this mechanism. As part of this, IInterceptingLogger was consolidated into IDiagnosticsLogger. There are no longer any Log methods here because logging is done through the definitions using the cached delegates. A fallback mechanism--RawEventDefinition--can be used for messages with more than six parameters. There are only a handful of these, and they are for design-time scenarios and so don't need to be super fast. Part of #218 Also, see #8456
ajcvickers
added
the
closed-fixed
ikesler
added a commit
to ikesler/consensus
that referenced
this issue
Jan 9, 2022
unfortunately, trimming is not working with EF yet: dotnet/efcore#26383 and dotnet/efcore#218 SQLLite EF provider includes an unmanaged module which is not part of single-file publish - IncludeNativeLibrariesForSelfExtract option required single-file build cannot be debugged - this is why PublishSingleFile msbuild property is used in dockerfie only
ikesler
added a commit
to ikesler/consensus
that referenced
this issue
Jan 9, 2022
* working on Viber; fixing ELK issues (too many indexes) * change history threshold to days * Finished Agent and Viber handler - MVP, working locally successfully * fixes * better ignoring * better ignoring * Set up ClickOnce deployment and updates for Agent; Refactor Agent logging * logging fixes * new custom deployment ClickOnce was not good solution because 1. Cannot build ClickOnce package in Docker 2. Unstable support in dotnet CLI. I was able to publish ClickOnce package successfully only from VisualStudio. dotnet or event msbuild CLI - no luck, only errors * fixing deployment and update flow unfortunately, trimming is not working with EF yet: dotnet/efcore#26383 and dotnet/efcore#218 SQLLite EF provider includes an unmanaged module which is not part of single-file publish - IncludeNativeLibrariesForSelfExtract option required single-file build cannot be debugged - this is why PublishSingleFile msbuild property is used in dockerfie only * cleanup * improve startup after system reboot hide console window. In Windows application mode the console host still appeared: AvaloniaUI/Avalonia#6672 and dotnet/runtime#3828 * a comment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: