Closed andreiZi closed 6 months ago
Hi @andreiZi,
Could I ask you to share your configuration for that sink?
Caz for me it looks like #141.
And looks like it's not related to .NET version (probably)
Sure
var loggerConfiguration = new LoggerConfiguration()
.MinimumLevel.Is(isDev ? Serilog.Events.LogEventLevel.Verbose : Serilog.Events.LogEventLevel.Information)
.Enrich.FromLogContext()
.WriteTo.GrafanaLoki(serilogLokiUrl)
.Enrich.WithProperty("AppName", appName)
.ReadFrom.Configuration(configuration);
Referring to issue #141, it seems related to the problem I'm experiencing. It took some time and debugging to trace the cause, but I'm glad to have found it. 😄
Is there a workaround available, or must I ensure that my Grafana is always operational to prevent this issue?
I would propose to set the reasonable limit during the log configuration.
It could be done by queueLimit
parameter all parameters are described there.
The only reason why it was not done in v8 because it's a breaking change of the default behavior and there is a way to configure it. But in v9 it would be for sure changed
Thank you I will do this, you can close this issue as it seems to be resolved and is a duplicate of #141. If i notice something is still off I will document my findings here. :)
Thank you for the help & fast response tho!
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue.
Which version of Serilog.Sinks.Grafana.Loki are you using?
v8.0.2
Which version of .NET are you using?
net8.0
Describe the bug
Hello,
I recently upgraded my services to .NET 8 and encountered a significant memory leak that caused all my services to crash, with RAM usage spiking to 2-3 GB.
Here are the relevant discussion threads:
Despite resolutions in all reported issues, the problem persisted, and strangely, I seemed to be the only one still experiencing it.
Upon analyzing the dump and comparing it with my .NET 6 applications, I discovered that the symbol:
System.Collections.Generic.Dictionary<System.String, Serilog.Events.LogEventPropertyValue>+Entry[]
was newly introduced and was causing the memory leak. After removing the associated package, all memory leaks ceased across all systems.
I've posted very detailed explanations in the threads linked above, so I recommend going through them.
My hypothesis is that this package attempts to cache logs when Loki is unreachable (we haven’t yet set up Loki in the system). This is similar to the behavior expected with tools like Seq, where if Seq is not operational, it doesn't impact the system—however, this was just an assumption. Interestingly, I also experienced the issue with Loki running, noting that the memory consumption rose slowly but was still present.
To Reproduce
Expected behavior
No memory leak
Log/SelfLog output or exception with stacktrace
Output
dumpheap -stat
.NET 6
.NET 8
Application or code sample, which could be used to reproduce a bug
No response
Additional context
No response
I have read the documentation