-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Tracing and Logging improvements for the UA Core and libraries #1631
Conversation
This pull request introduces 3 alerts and fixes 3 when merging 5ef5c93 into 58bac5a - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts and fixes 3 when merging 0315817 into 58bac5a - view on LGTM.com new alerts:
fixed alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
@mrsuciu thanks, still looking at this code ql build issue and lgtm / Codacy warnings -- 🧷 |
This pull request introduces 2 alerts and fixes 3 when merging 3f00526 into b55ef38 - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 2 alerts and fixes 3 when merging 4ed7fbc into b55ef38 - view on LGTM.com new alerts:
fixed alerts:
|
This pull request introduces 1 alert and fixes 3 when merging a1ce8fe into b55ef38 - view on LGTM.com new alerts:
fixed alerts:
|
@mregen I think one file got missed during the cleanup. in there you're still making use of |
Hi @zewa666, thanks for checking! fix it asap. |
Hi @zewa666 , misunderstanding -- the .NET framework apps are supposed to use the %CommonApplicationData% vs the .NET Core console apps run cross platform, so they need to use %LocalApplicationData%. All good, hope it makes sense.. |
oh ok, well then sorry for the confusion. we've wrongly then picked the .net one for the core framework :) |
Seems like the LoggerUtils partial is not compiled into Utils at least when trying out Core NuGet Package 1.4.367.75 so the ConsoleReferenceServer would not compile once modified for proper use: At least with the following project: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.0" />
<PackageReference Include="Mono.Options" Version="6.12.0.148" />
<PackageReference Include="OPCFoundation.NetStandard.Opc.Ua.Server" Version="1.4.367.75" />
<PackageReference Include="Serilog" Version="2.11.0-dev-01377" />
<PackageReference Include="Serilog.Expressions" Version="3.2.1" />
<PackageReference Include="Serilog.Extensions.Logging" Version="3.1.0" />
<PackageReference Include="Serilog.Sinks.Console" Version="4.0.1" />
<PackageReference Include="Serilog.Sinks.File" Version="5.0.0" />
</ItemGroup>
<ItemGroup>
<None Update="Quickstarts.ReferenceServer.Config.xml">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project> |
Hi @jetersen, to test the latest ref server with Nuget packages please use a 1.4.368 preview package, to access the preview feed add a Nuget.Config --> https://github.com/OPCFoundation/UA-.NETStandard-Samples/blob/master/Nuget.Config. |
@mregen think you tagged the wrong user :) Also I realized my mistake was to use the reference application instead of one from the sample repos 😅 |
Hi @jetersen, its totally fine to use the reference apps here with nuget packages. Just due to the new logging feature the 367 packages have become incompatible, that's why there is the preview feed. If you copy the Nuget.Config to the root of this repos you can pull in the preview packages as well. |
Improvements for Tracing and Logging
The existing Tracing model in the UA .NET Standard stack
The existing codebase up until version 1.4.367 uses the following primitives for logging:
Utils.Trace
functions to log messages in the codebase with message format strings and arguments as format parameters, along with optionalTraceMasks
andExceptions
.ApplicationConfiguration
section forTraceConfiguration
to specify theOutputFilePath
andTraceMasks
.TraceEvent
callback event, which allows an application to capture all messages and filter on its behalf. With some wrapper code it is possible to map theTraceEvent
messages to existing loggers like Serilog and others. Again, the TraceEvent callback is not suitable for high performance logging, but so far the best solution using the .NET UA stack.TraceEvent
to Serilog is provided in the .NET Framework Reference Server sample application.The wishlist for the future logging model
TraceEvents
.Information
level to allow production applications to run with logging always enabled.EventSource
for development, which is available for Etw on Windows and in a different flavor on Linux with adotnet-trace
command.ILogger
interface as replacement for theUtils.Trace
functions to log leveled messages in the codebase with message format strings and arguments as format parameters, similar to the existing approach.System.Diagnostics.Activity
) and scopes (BeginScope
).The proposed solution
ILogger
interface which is defined inMicrosoft.Extensions.Logging.Abstractions
as core abstraction for logging functions. This dependency leads to include a new Nuget package with abstractions, but only to the core library.ILogger
interface is the proposed logging interface for .NET with OpenTelemetry. It is also supported with prebuilt libraries by all popular logging frameworks. Including the UA stack logger in existing applications becomes a lot easier.Opc.Ua.Core
remains a singleton which is used by all depending libraries. Also due to some naming convention limitations the singleton forILogger
remains in theOpc.Ua.Utils
class.TraceEventLogger
is initialized to support the existingTraceEvent
callback.LoggerExtensions
functions are integrated inOpc.Ua.Utils
as static functions instead of the Logging extension functions.Utils.Trace
logging functions are mapped as a best effort to the newILogger
interface. Existing application should still work and log information as previously, even after updating to the latestOpc.Ua.Core
library with the new logging support.ILogger
interface is available directly as a singletonOpc.Ua.Utils.Logger
interface. But using this interface is quite cumbersome, theUtils.LogXXX
functions should rather be used.EventSource
logging there is another singleton with the high performance logging interface exposed asOpc.Ua.Utils.EventLog
.ILogger
with its own implementation by calling theOpc.Ua.Utils.SetLogger
function. Then the existing logging withTraceEvents
is disabled. However tracing withEventSource
is still possible, even after theILogger
is replaced.Utils.Trace
is replaced byUtils.LogXXX
, whereXXX
corresponds to the log level.The supported log levels are:
Critical
,Error
,Warning
,Information
,Debug
andTrace
.Utils.LogXXX
as theEventId
.Caveats and open issues
{0}
by a name, e.g.{ChannelId}
. Currently theEventSource
logger and the existingTraceEvent
do not support the structured logging format strings. A solution is under investigation.Activities
orScopes
from within the UA stack code. How to achieve the goal to support correlation ids is still under investigation.EventId
parameter is still under investigation. Currently it is only used to support the tracemask used by existing logging calls. The tracemask is passed toTraceEvent
for filtering and for backward compatibility.EventSource
.Sample code
The
ConsoleReferenceClient
and theConsoleReferenceServer
have been modified to show how to use a Serilog logging provider with newILogger
interface.The file logging provider uses the
Information
orVerbose
level depending on the chosen flags and the file location used in the configuration file.The console logger uses the
Information
level and is enabled using the command line option-c
.A command file for windows called
dotnettrace.cmd
is provided to capture .NET traces using theEventSource
of theOPC-UA-Core
provider.The trace tool is installed using:
dotnet tool install --global dotnet-trace
,The trace is captured from a running application with the following command:
dotnet-trace collect --name consolereferenceserver --providers OPC-UA-Core
Perfview
on Windows shows the traces captured in the.nettrace
files.