ILogger<T>
We currently think about removint a lot of direct NLog references as preparation for future projects. Now we have some Class A that instanciates at points in Time B. But at CreationTime of T we dont know yet all informations about the category to use.
i cant imagine we are the first one to be in this position.
39 Replies
Inject ILoggerFactory instead.
ILoggerFactory Interface (Microsoft.Extensions.Logging)
Represents a type used to configure the logging system and create instances of ILogger from the registered ILoggerProviders.
Though, I wonder why your log categories vary so much.
sorry i did miss a point in my question. B never knows the information. Only A knows it.
now we used NLog-`Properties
They are a lot of TCP Clients and we want/need to be able do identify them. but we know the resulting user id only after a few messages and only from the outside.
we found Scopes. a coworker currently does tests with that. if they are able to be used there.
definitely can use scopes
this is not something to use categories for
if you send your logs to something that supports structured logs (e.g. seq), you can see and query all that data
asp net core uses scopes to add request id, connection id,.. etc to logs
but as we see, if i use a dictionary in scopes, its just .ToString() and NLog does show the values. thats just NLog specific?
(i.E.: whats the intent of the dictionary thats shown all over the docs. is it just for structured logging? )
what dictionary?
ahhh
i mean you could configre it to show in every log message..
we ran into more issues. i try to verbalize it:
- we have 1 place (Tcp listener (simplified), where we create some clients(class)
- there we know this user id.
- we want to identify in log what class for what userid the log is from.
- we have this code used in 'legacy' but also work on a azure implementation. so we need to kind of spread our legs here to archieve all...
(but also dont want to do tooo much custom stuff/workarounds)
where do you log to
legacy uses nlog into file.
azure for now uses the console (not decided if we want more later)
according to https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-8.0#logscopes
console supports scopes? i dont remember honestly
thats a doc i have seen. the scopes in console look like just 'ToString' done onto the dictionary. thats currently where its a bit of area where we are not sure how and what to do. (trying to do the right thing here).
but to answer here.. you can put any object and use it to add arbitrary data to scope. ofc usually its something simple as dict, list, string, but could be a class too
1 sec, i get a log example in a moment.
now if you still use nlog (i thought you already migrated) then idk if it will be nlog specific
nlog is in legacy where it works. for the azure implementation we want to ditch the NLog dependency.
thats an example of the console:
fail: ConsoleApp2.LogInitializer[0] => System.Collections.Generic.Dictionary`2[System.String,System.Object] With just name
yea so how is that logged in code
we have a bit of unexpected time on our hands, so we decided we invest a bit into learning/researching for our future log situation.
def gonna be worth
thats the relevant lines
var logger = logFactory.CreateLogger<LogInitializer>();
var logProperties = new Dictionary<string, object>();
logProperties["Name"] = "Michael";
using (logger.BeginScope(logProperties))
logger.LogError("With just name");
the next thing would be some nested object, on how to give it the correct scope, since it doesnt and should not know about that (a simple parser for example doesnt need some userid or such (i hope i can articulate clear what i mean - english is not 1st language.)
thats the goal 🙂
what i postet is just testing and sandbox code. to isolate the behaviour
logger.BeginScope("something something {Foo}", logProperties)
probably need a template
i try in 1 moment. i now get the project for the tests sent to me 🙂
cool
this topic sparked my personal interest more than i could ever admit to my wife
😆
i will quickly take a look into templates for console log.
i meant your code in .BeginScope is missing template string argument
so i gave an example
how to add
ahhh
i understand what you mean.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.loggerextensions.beginscope?view=net-8.0
public static IDisposable? BeginScope (this Microsoft.Extensions.Logging.ILogger logger, string messageFormat, params object?[] args);
yea
messageFormat, template whatever
"{}" as template... works like a charm 🙂
-top is console
- bottom is NLog
thank you so much for your help. this archieves exactly what we need
{} works but this means if you ever send that log to something that ingests structured logs, those values wont have a "key"
generally no harm to just put something like {ConnectionProperties}
but ye np
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
thanks @TeBeCo im gonna look into this enritcher later today.
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
it does. i think i will build a mvp project and document this maybe this evening. this shows maybe the full intent
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View
the current increment we dont have. we just have 10 liner tests of features (maybe also a wrong approach)
Unknown User•2w ago
Message Not Public
Sign In & Join Server To View