-
Notifications
You must be signed in to change notification settings - Fork 248
Implement an official FileLogger #441
Comments
personally I like the enterprise library semantic logging aka SLAB & feel that should/if this be made coreclr compatible that this would provide a lot of features/benefit for the logging story which could be used by non aspnetcore projects |
@grahamehorner sure but that has little to do with this issue. |
@davidFlow not really given SLAB has many sinks including a simple file and rolling file sink, why reinvent the wheel? also others have asked for EventSource support; killing two birds with one stone. 😀 I've already started a fork of SLAB with a view of making a |
Because even if slab is ported, we're not going to delete this library. Serilog/NLog/log4Net already has a file logger as well but that won't influence our decision to have a basic file logger out of the box. There's also an event source logger in the works for RTM #424 |
|
|
Here's the plan, let me know what you think: By default:
You can configure:
Things to consider:
Rough API: // API:
// Might consider grouping the configuration params in Options
AddFile();
AddFile(folderName = null, queueSize = 100, Func<string, string> nameFactory = defaultnamefactory);
// Examples:
// Default file name, location, queue size, file size
loggerFactory.AddFile();
// New naming convention
loggerFactory.AddFile(nameFactory: previousFileName => {
if (someCondition) {
return newFileName;
}
return previousFileName
});
// Custom folder and log file size (default name)
loggerFactory.AddFile("/someFolder", 1024); Thoughts? |
I think the default should be to name log files by date (UTC). |
|
Is the goal here just to simplify the few lines of code needed in order to get file logging up and running? If so, why not open a discussion with the community implementers of Having complete implementations of m.e.Logging and m.e.DependencyInjection in the framework is a short-term win and huge long-term loss. We (me, the community of people writing open source components for .NET, and others) have supported the vision of a lean, core, cross-platform modular platform on which the community can build from the beginning. Serilog, and Autofac, for example, have been there at every As the core team, you're in a unique position: you can bring the community together, and you can fill gaps in the platform, in a way that no one else can. Do we need better file logging in .NET? Exposing a good API for atomic append writes would mean we can all have awesome file loggers. Reinventing the wheel will just mean we have yet more mediocre components and less investment into .NET open source. When you started m.e.Logging by building NLog and Serilog adapters, and subsequently donating them to the respective projects, it felt like the beginning of a whole new chapter in .NET to me. Let's keep that alive! It's harder to organize the community than it is to ship a few thousand lines of code, but over the long-term it's the best thing for the ecosystem. User experience also doesn't have to be compromised if we go this way. If people want to write: loggerConfiguration.AddFile("logs/app.txt"); ...there's no material differnce whether that However, if you build the APIs to make it possible, there is a big difference in the ecosystem. Instead of one If we set off down the path of trying to ship good-enough implementations of everything in the box, that's all we'll have in a couple of years. I hope this is receieved in the spirit that it is written - I know my position seems biased by my involvement in a bunch of these community projects - but ultimately the most important thing to me is to see .NET grow and thrive. |
I fully agree with what @nblumhardt is saying. I think this is very similar to the current situation in DependencyInjection. I'm very afraid that supporting more providers in this logging implementation will lead to a lack of usage and innovation in well-established and feature-rich logging frameworks like Serilog, NLog etc! People will use this logging implementation because it's included by default, not realizing that there are many better solutions out there. That's why I think, these questions are really important:
IMO, If you truly want to participate in the .NET OSS community, you have to acknowledge the role of the ASP.NET Core web framework as being only one component in a huge ecosystem - and this huge ecosystem already has well-established solutions for logging and Dependency Injection. Having this in mind, your framework libraries should be designed with interoperability as the first priority. IMO this means that the implementation packages I understand that you need your own basic logging implementation for people that don't want to use 3rd party tools, but I'm also sure that this group of people will become smaller and smaller over the next 5-10 years because using OSS libraries clearly is the way our industry is headed towards in this new era of .NET Core. So, having your own implementation should always be a secondary priority. PS: I also want to say that I really like working with .NET Core and ASP.NET Core. You are doing a really great job and you had a great impact on my involvement in OSS! Logging and DI are the only areas I'm having architectural concerns with. |
Makes me sad this doesn't exist. Am in a situation on a remote system where I can't get Console, can't get Debug, so file is a fallback - don't care if its rubbish, just need to see what's going on; so will have to write my own file provider. Don't want to use a 3rd party as something is going wrong and don't want to bring in extra dependencies to try and find out what as that may muddy the waters. How about keeping it very simple, not add rolling logs etc and have a extension called |
Not true -- look into Serilog. And given the engineering that is going into this issue, they're just reinventing serilog's file sink. |
Yeah, take your point... |
Don't agree with Brock on this - this is such a basic core feature - it belongs in the framework. I think they should keep it simple and leave the complex stuff to full logging libs like Serilog, but creating a simple file logger without having to add a third party library seems intuitive to me. After all you can already log to console and a few other things without having to add anything and a basic file log is probably the first thing you think of when you talk about logging. Don't make people jump through hoops to get basic and expected functionality. |
I think we do agree -- if they're going to do this then it should stay dirt simple. It needs to be developer focused at dev time, not production server focused. Let Serilog be the big boy logger. |
"..creating a simple file logger without having to add a third party library seems intuitive to me." Me too. I'd also add that having the file logger sink inherit from a base batching / buffering async sink would be nice ( In most cases the logger should enqueue the log event and let the sink do the usually asynchronous work ). Add common logging configuration for filtering and I'd have everything I need. |
For an idea of what a Serilog-provided From the README: 1. Add the NuGet package to the "dependencies": {
"Serilog.Extensions.Logging.File": "1.0.0"
} 2. In your public void Configure(IApplicationBuilder app,
IHostingEnvironment env,
ILoggerFactory loggerFactory)
{
loggerFactory.AddFile("Logs/myapp-{Date}.txt"); It supports an opinionated set of defaults (e.g. background thread for writes, We'll see how it fares and report back on the experience :-) |
I see the point that @brockallen and @RickStrahl are making about a default, included, stupidly simple file logger, for development use, but, while the idea of just throwing in a basic file logger sounds simple, once you get into it, it starts to get a lot more complex: do we put an upper limit on file size? Roll-over files? Naming? How do we format the entries? Can that be customized? How do you ensure it doesn't have a negative impact on performance? A good compromise might be:
@nblumhardt 's example demonstrates how easy it can be to incorporate a third-party logger. The more I think about it, the more I really don't think there should be a huge effort around an out-of-the-box file logger, other than ensuring it can't bring your system down. |
And to add to what @colin-young just said, since it seems @nblumhardt is making it even easier now, the steps to add Serilog and the exact same to add this proposed file logger. Since everything is NuGet, there is no such thing as an "in the box" anything anymore. |
I was suggesting something along the lines of what @benaadams was looking for, to avoid introducing new dependencies to a misbehaving production system, although when you get to deploying modified code to production, that's really only a small step away from adding a single new dependency in terms of "muddying the waters." By in-the-box I meant in the same assembly so you would get it automatically as soon as you take a dependency on m.e.Logging. I'm not really a fan of adding a file logger to the framework. I think it's a lot more complex than many first assume, and it invites feature-creep. |
We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have. |
For everyone who are looking for simple FileLoggerProvider without dependencies on the logging frameworks (Serilog, NLog, log4net), here is an implementation that works very similar to standard ConsoleLogger but writes result to a file: https://github.com/nreco/logging |
Another implementation without 3rd party dependencies. Full feature set of ConsoleLogger is covered and some more. |
Rick Strahl, a great real world developer who safed my ass a thousand times in 10 years, with his asp blog infos, and a lot of other great ppl here, are 100% right in what they say, imo. THIS is the community. Your community. Plz listen to them. |
@muratg if u want the problem get solove,u shouldn't close this issues. |
A very simple file based logger would be useful.
The text was updated successfully, but these errors were encountered: