-
Notifications
You must be signed in to change notification settings - Fork 796
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
Access sinks #1929
Comments
Agree. This is a common problem of design with an implicit configuration of sinks from configuration. As I understand Graylog repository may provide needed overload accepting delegate to set Also note that sinks are often considered to be immutable after creating. You provided I propose to add special API for one-time sinks configuration. See #1930. @nblumhardt If OK I'm glag to discuss naming and other details. |
Of course, more changes are needed in the Graylog repository because as you say, once the options is instantiated and the sink constructor is called, it is not possible to change any settings: But I didn't want to create noise on this issue because it is a concrete problem of that Graylog extension implementation on Serilog. |
@bdovaz please don't @ anyone in an issue like this. |
I understand and exactly because of that I suggested generic API to configure any sink regardless of its implementation capabilities. One-time setup is important thing for me in terms of overall design. I would not expose some list of sinks from configuration object. |
What I meant (and maybe I was misunderstood) with that sentence is that even if we have exposed your new API design (which I think is great) is that if you look at how the graylog sink consumes the options class, it is too late to change properties of the configuration instance. In that specific sink more changes are needed and we would have to analyze extension by extension if we have to change the design of each one so that this is possible in all of them. Because there is no common pattern of options + sink. The ideal pattern of options classes is Microsoft's IOptions<> but I understand that you don't want to have a hard dependency on the Serilog core towards Microsoft extensions. |
Hi all! Sorry about the patchy availability here, I'm taking a short break and only jumping online sporadically. Back to full speed late next week. This sounds like a problem unique to Serilog.Settings.Configuration, to me. Using some kind of static factory method or constructor should enable this without too much additional machinery. It's slightly awkward, but it's also a fairly niche scenario. The other solution, which I personally prefer, is to just configure the sink in code, and pull the dynamically-varied configuration from your own custom configuration section (probably just a couple of flat values that identify the Graylog endpoint). Simple and reliable :-) |
I wouldn't say it's quite a niche scenario, more like a more advanced scenario for more complex use. Composing the settings of each sink with a mix of reading the appsettings file and further configuration of properties that are not possible to configure from a json (because they are not primitive types deserializable from json like a Func<>, Action<>, etc) or that you want to override under certain more complex conditions other than appsettings.{EnvironmentName}.json which is what the base Microsoft.Extensions.Configuration system supports. It is true that the problem is in the context of this One option is the API design shown by @sungam3r. Another option that would only affect the Serilog configuration package could be something like this (if it is possible to do it without touching anything in the Serilog core package which I don't know either): Add this property in the following class: public sealed class ConfigurationReaderOptions
{
public Action<ILogEventSink>? OnSinkCreated { get; init; }
} Usage: var logger = new LoggerConfiguration()
.ReadFrom.Configuration(configuration, new ConfigurationReaderOptions {
OnSinkCreated = sink => {
if (sink is GraylogSink graylogSink) {
// Change sink configuration if possible
}
}
)
.CreateLogger(); |
I 100% understand that and already told about that particular case. Serilog code may expose suggested new APIs to configure sinks in any way sink supports.
Or couse, but the more interesting question is about how to provide additional tuning when starting entirely from Pros and in the same time cons of suggested |
I'm happy leaving this discussion open if it might flush out some workable solution, but I feel like direct access to sinks goes against the grain of the Serilog design, which deliberately hides them so that sinks can be implemented using techniques like wrapping, which would get in the way of this kind of usage. Take for example the way For these reasons I think it's a ship that has sailed. There are definitely other ways Serilog could approach this, with various pros and cons, but because a design has been chosen I think a solution would need to embrace the decisions that have already been made. Since Serilog.Settings.Configuration is calling those sink creation extension methods, perhaps instead of looking to access the raw sink, an extension point could be created there for resolving parameters to the extension method? E.g. Hope this helps, |
Just for information - I updated proposal in #1930 with the latest changes from |
Is your feature request related to a problem? Please describe.
@nblumhardt I am using
Serilog.Settings.Configuration
and theSerilog.Sinks.Graylog
sink.The problem I have is that it seems that the use case of mixing and reading the appsettings configuration and then configuring or overriding a sink from code is not covered.
Graylog's sink allows for example to set up a transport factory which is obviously something that cannot be set up in a json file: https://github.com/whir1/serilog-sinks-graylog/blob/master/src/Serilog.Sinks.Graylog.Core/GraylogSinkOptions.cs#L211C28-L211C28
Describe the solution you'd like
Although the ideal solution requires more changes in the Graylog repository, this Serilog Core repository should at least expose information that so far is not exposed:
serilog/src/Serilog/LoggerConfiguration.cs
Line 22 in 3016aa3
Proposal:
And then:
Describe alternatives you've considered
Right now I'm doing it through reflection:
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: