You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the lack of good tracing it is currently relatively hard to figure out rare errors in remove applications.
It seems there are a couple of issues when running in certain container environments.
While trying to improve the resiliency of this library, I'd also like to give you some way to get more information about what's going (wr)on(g). (#51#52)
Adding logging is always a fun one... I don't want to add any external Nuget dependency, so even the fact that Microsoft.Extensions.Logging.Abstractions doesn't have any dependencies to anything else, and it would probably ok to use it. I still don't want to add it now in a minor version update and then deal with different versions of that package...
An internal logging abstraction which is an even simpler version of the Microsoft framework to have at least a nice API to log errors, warnings of debug messages...
Offer different options to hook into those log messages which will be disabled if the consumer doesn't do anything.
Simple static TraceSource
Simple adapter to Microsoft.Extensions.Logging if you want to forward DnsClient's logs to your already existing logging setup
This will probably be just a code example consumers can copy&paste, I'll probably not create a NuGet for just that
Add more logging to
parsing errors
nameserver resolution
Udp and Tcp handlers
I opted for this way over adding it to the configuration of the LookupClient because we need a way to hook into logs even if you don't have access to the LookupClient instance.
For example, if DnsClient is used in the MongoDriver, you don't control the instance or configuration that library uses, but you still need log messages.
Those APIs might be subject to change if it turns out that there are better alternatives or no-one has anything against adding a dependency to Microsoft.Extensions.Logging.Abstractions I'll be happy to just use that instead.
Option 1 - TraceSource
To use the first option, you'll be able to hook into TraceSource like this:
That't all you need to get the logs send to a TraceListener.
(I never used that Tracing framework to expose trace messages, so if there is a better way then a static instance, I'm happy to hear feedback ^^)
Option 2 - Forward to Microsoft.Extensions.Logging
Forwarding the log messages from my internal logging to the Microsoft framework just requires some stitching.
There is a static instance of my own LoggerFactory which can be set to a new implementation.
All you have to do is setup the Microsoft logging configuration and such and then use the wrapper below and make DnsClient use that LoggerFactory instead of the default one.
// Replace with your logging setup..varservices=newServiceCollection();services.AddLogging(o =>{o.AddConsole();o.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Trace);});varprovider=services.BuildServiceProvider();// get an instance of ILoggerFactory and pass it to the wrappervarfactory=provider.GetRequiredService<Microsoft.Extensions.Logging.ILoggerFactory>();// Re-define the LoggerFactory used by the library to the new wrapperDnsClient.Logging.LoggerFactory=newLoggerFactoryWrapper(factory);
The wrapper code (just an example, feel free to improve it ^^)
* Adding filtering of resolved nameservers in case the native fallback is used to remove site local addresses.
* Also changed the cache slightly to not cache results without answers
* Adding basic logging, see #60
* Adding a parser exception
* Changing the ServiceHostEntry to directly have priority and weigth properties fixes#34
* Adding netstandard2.1 target which doesn't need the System.Buffers reference anymore.
* changed how opt records are created and used. Added configuration to disable EDNS and to set the requested buffer size and DnsSec
* Changes the behavior in case of bad responses which were truncated by some middleman proxy or router - fixes#52
* Changing default unknown record handling to preserve the original data so that users can work with those records.
* Reworking error handling see #60
* Adding new setting ContinueOnEmptyResponse #64
With the lack of good tracing it is currently relatively hard to figure out rare errors in remove applications.
It seems there are a couple of issues when running in certain container environments.
While trying to improve the resiliency of this library, I'd also like to give you some way to get more information about what's going (wr)on(g). (#51 #52)
Adding logging is always a fun one... I don't want to add any external Nuget dependency, so even the fact that Microsoft.Extensions.Logging.Abstractions doesn't have any dependencies to anything else, and it would probably ok to use it. I still don't want to add it now in a minor version update and then deal with different versions of that package...
I will probably go for the following:
(see #58)
TraceSource
This will probably be just a code example consumers can copy&paste, I'll probably not create a NuGet for just that
I opted for this way over adding it to the configuration of the LookupClient because we need a way to hook into logs even if you don't have access to the LookupClient instance.
For example, if DnsClient is used in the MongoDriver, you don't control the instance or configuration that library uses, but you still need log messages.
Those APIs might be subject to change if it turns out that there are better alternatives or no-one has anything against adding a dependency to
Microsoft.Extensions.Logging.Abstractions
I'll be happy to just use that instead.Option 1 - TraceSource
To use the first option, you'll be able to hook into TraceSource like this:
That't all you need to get the logs send to a TraceListener.
(I never used that Tracing framework to expose trace messages, so if there is a better way then a static instance, I'm happy to hear feedback ^^)
Option 2 - Forward to Microsoft.Extensions.Logging
Forwarding the log messages from my internal logging to the Microsoft framework just requires some stitching.
There is a static instance of my own LoggerFactory which can be set to a new implementation.
All you have to do is setup the Microsoft logging configuration and such and then use the wrapper below and make DnsClient use that LoggerFactory instead of the default one.
The wrapper code (just an example, feel free to improve it ^^)
The text was updated successfully, but these errors were encountered: