Serilog server does not receive any data on 5.2.2 by .NET

[MiiChielHD]

Hi,

With WPF applications I used 5.1.1 , which still send loggings fine to our local instance of SEQ Server. Yet when using 5.2.2 (WPF NET 6.0) it doesn't receive anything. I tried to create a new project with WPF .NET Framework 4.8, still not working. I reverted back to 5.1.1 and it now works.

I have a ASP.NET Core 6 console application running on ubuntu, with Serilog SEQ 5.2.2 and those loggings are being received by our instance of SEQ Server perfectly.

Our instance of SEQ Server runs 2022.1.7929

Is this a problem on our side?

[nblumhardt]

Thanks for the note! Do you see any output in Serilog's SelfLog?

[MiiChielHD]

No output in selflog, yet I use WriteTo.Debug and Write.ToFile as well.

I do see a text in the Output window of visual studio (cause by WriteTo.Debug),
yet no text in the file by WriteTo.File, but the file has been created.
Edit: I noticed that using Log.CloseAndFlush() made the text write to the log file.

Also the test.txt stays empty, Log.CloseAndFlush() do not affect this result.

I revert back to 5.1.1 and test.txt stays empty, yet the logging to SEQ works again.

[bddckr]

We've run into the same issue. Downgrading to 5.1.1 fixes it, but so does setting messageHandler = new HttpClientHandler() when setting up the sink (see #180). So we're going with the latter.

We use this sink with net6.0-windows on Windows 10+ PCs, Xamarin.Mac (we're updating that to net6.0-osx soon) for a Mac app, a CLI using net6.0 with runtime identifier targeting Windows/Mac/Linux as well as a net6.0-android app. Of all of those targets, the issue only affects the Android app and only on devices running Android API level <=27.

The SocketsHttpHandler introduced with #180 seems at fault here. Perhaps its implementation is giving issues on specific targets?

[MiiChielHD]

"Perhaps its implementation is giving issues on specific targets?"

Is this a general question for a future update or is your reaction insinuating I should use a different implementation of the HttpHandler?

[bddckr]

It's a general question, specifically for the maintainers of this sink. I'm saying using HttpClientHandler works for us, while the PR I linked makes this sink use SocketsHttpHandler by default. At least that's what I think is happening.

There are known benefits when using SocketsHttpHandler, so we'd love to get back to using it, though.

What's confusing to me is that SocketsHttpHandler is supposed to be the solution to give us one implementation for all platforms... something that I seem to have disproved, at least when it comes to net6.0-android. I just found dotnet/runtime#78716, which might actually be the underlying issue my team is running into on Android. You are using WPF, though, so clearly something related is going on. Does specifying HttpClientHandler in the .WriteTo.Seq(...) call as the messageHandler fix the issue for you as well while using version 5.2.2?

[MiiChielHD]

"Does specifying HttpClientHandler in the .WriteTo.Seq(...) call as the messageHandler fix the issue for you as well while using version 5.2.2?"

Could you give me a more clear coding example what to write exactly? My knowledge about the HttpClientHandler and the rest of the topic is way to limited. Thnx

[bddckr]

In your screenshot above you used .WriteTo.Seq("some URL", apiKey: "some API key"). Replace that with .WriteTo.Seq("some URL", apiKey: "some API key", messageHandler: new HttpClientHandler()). That should do it! Make sure to switch back to 5.2.2 of this sink.

[MiiChielHD]

Aha. I switched back to 5.2.2, I made sure the logging still worked at 5.1.1 just before that. With 5.2.2 it did not work, adding the new HttpClientHandler() didn't fix it unfortunately...

[nblumhardt]

@bddckr thanks for the note regarding the Android compatibility issue! Sounds like a very challenging set of platforms to support - hopefully the workaround you have now will hold up until the underlying issue is found and resolved.

@MiiChielHD my guess is that the changed message handler is interfering with something like default internet proxy settings being picked up; WinHttpHandler might provide the bit of magic that's missing:

.WriteTo.Seq("some URL", apiKey: "some API key", messageHandler: new WinHttpHandler())

Let me know if this helps!

Nick

[MiiChielHD]

Hey Nick, Nope this doesn't work either. Again I tried 5.1.1 first to test if the it logs and yes it did. Then tried 5.2.2 with WinHttpHandler... no success.

Note that with WinHttpHandler with 5.1.1 also does not work.

Without WinHttpHandler it works with 5.2.0 as well, it breaks at 5.2.1;

Earlier on I went back to 5.1.1 as a good guess that it would work at least. It did yet I did not try a higher version before 5.2.2. Anyway its a change in 5.2.1 that breaks it.

[nblumhardt]

Interesting! Thanks for the follow-up. The only change in 5.2.1 is an update to the Serilog.Sinks.PeriodicBatching dependency:

https://github.com/datalust/serilog-sinks-seq/pull/186/files

Is your project using version 3.1.0 of that package? Do you have some success if you add:

<PackageReference Include="Serilog.Sinks.PeriodicBatching" Version="3.1.0" />

to your top-level project's (e.g. executable's) CSPROJ file?

[MiiChielHD]

Unfortunately with 5.2.1 and PeriodicBatching 3.1.0 it doesn't work either... Back to 5.2.0 with PeriodicBatching 3.1.0 it doesn't work either. Without PeriodicBatching it works again on 5.2.0

[nblumhardt]

Thanks again @MiiChielHD - we'll dig in further here, and let you know what we find. (The next few weeks the team will be on vacation at different times, so it may take a while to reach some conclusions.)

[MiiChielHD]

@nblumhardt No problem, hope you will find the problem in the future.

[MiiChielHD]

I'm back again, same problem, I tried using AuditTo.Seq(http://adress:port", apikey:"key")

This time I'm using .net Framework 4.5.2

The error i get is:
Geen toegang tot een verwijderd object.
Objectnaam: System.Net.Http.HttpClient.

Or in english, not access to deleted object, objectname: System.Net.Http.HttpClient

I also tried using messageHandler: new HttpClientHandler(), no luck;

Is there a possibility that the problem is that our server is not https but http?

[nblumhardt]

Hi @MiiChielHD, thanks for looping back.

I can finally see the problem! In your screenshot above - you're constructing your logger in a using statement:

using (var log = ...)
{
    Log.Logger = log;
}

// More code here

At the end of the using block, the logger/logging pipeline will be disposed/torn down. The object in Log.Logger is the same one - although there's still a logger in there, it's already been shut down, so it's not going to work properly.

Some sinks don't perform any tear-down on dispose - Console() for example - so those may keep working. The Seq sink disposes its HttpClient so it will fail with the error you're reporting.

Getting rid of the using part will fix this - assuming that your current code is still using the same pattern.

HTH,
Nick

[MiiChielHD]

@nblumhardt Aah! That solves it... Great catch! Thank you, the newest version of Serilog.Sinks.Seq also works on .Net framework 4.5.2;

I think you can close the topic now :).