Skip to content
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

MinimumLogEventLevel is ignored #30

Open
WebSerGe opened this issue Apr 4, 2021 · 4 comments · May be fixed by #47
Open

MinimumLogEventLevel is ignored #30

WebSerGe opened this issue Apr 4, 2021 · 4 comments · May be fixed by #47
Labels

Comments

@WebSerGe
Copy link

WebSerGe commented Apr 4, 2021

Does this issue relate to a new feature or an existing bug?
Bug
What version of Serilog.Sinks.Elasticsearch is affected?
2.0.3
What is the target framework and operating system?
Net Core 3.1
Please describe the current behavior?
When using minimumLogEventLevel via json based configuration the set value is neither checked nor used. All events are being sent.
a minimal demo of the problem

create empty project
install Serilog
install Serilog.Sinks.Slak

configure something like this:
{
"Name": "Slack",
"Args": {
"WebHookUrl": "https://hooks.slack.com/services/XXXXX",
"CustomChannel": "#errors",
"CustomUserName": "User",
"MinimumLogEventLevel": "Warning",
"BatchSizeLimit": 1,
"ShowExceptionAttachments": true
}
you will find all logs in the channel

@WebSerGe
Copy link
Author

WebSerGe commented Apr 4, 2021

I found the issue, Serilog.Sinks.Slack/Models/SlackSinkOptions.cs contains MinimumLogEventLevel and no more options related to log level. However, if RestrictedToMinimumLevel (which is absent in SlackSinkOption) is added to configuration file appsettings.json then filtering of events works.
RestrictedToMinimumLevel exists in Serilog.Sinks.Slack/SlackLoggerConfigurationExtensions.cs and MinimumLogEventLevel is absent there.

@TrapperHell TrapperHell added the bug label Apr 7, 2021
@TrapperHell
Copy link
Member

Apologies for the delay. I meant to get back to you sooner, but I've been quite busy. Unfortunately there's a couple of issues here, so I can't quite decide what would be the best course of action.

Let's start off with the simple bit: The MinimumLogEventLevel property may be a somewhat misleading since it's available in the options file, but not within the configuration extensions.

The fix for it is somewhat unclear though. It is simple enough to expose the property in the configuration extensions, and the issue would be solved, however we would end up with two ways to configure the logging level. As you've quite rightly mentioned, there also exists the RestrictedToMinimumLevel property, which achieves a somewhat similar function.

There is however a couple of nuances. First off, the latter argument is handled by Serilog's sink configuration (LoggerSinkConfiguration.Sink()) and thus requires no real backing-property in the Options model, or custom-logic to make it work. However at runtime this property can only be raised (ie. the minimum level cannot be lowered). Going off at a tangent, it does seem like the method I've indicated here is due for removal from Serilog at some time (as the message reads: Provided for binary compatibility for earlier versions, should be removed in 3.0. [...]).

On the other hand, the MinimumLogEventLevel property allows for both raising and lowering at runtime, however this is manually controlled by the sink logic (which should already be in place).

My main concern here is that adding another argument that controls logging level in the configuration may make matters all the more confusing, and downright replacing the other argument is probably a bad idea (even though not breaking).

At this point I'm not sure whether to just add this argument as well in the configuration extensions, or if there's a better way of achieving all this. I'll need to think about it some more. In the mean time, feedback is welcome.

@alexvazquez
Copy link

Is this going be fixed?

@TrapperHell
Copy link
Member

Hi @alexvazquez ,

The issue is still open, and intended to be fixed at some point, however I don't think it would be any time soon (at least not from my end). However if you'd like to adjust it to match your needs, I don't think it should be too intensive. You could also issue a pull-request if you do go on about fixing it, and I'll see if I can include it in the base.

I'm pretty time-constrained at the moment, and there are some other matters with the project that I would like to address before going over this.

@mallek mallek linked a pull request Mar 4, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants