LogEvents with Exceptions are not getting transmitted to Loggly, silently failing about serilog-sinks-loggly HOT 7 CLOSED

Hi Jon, sorry about the delay in replying, thanks for the note.

There are a few sinks that use JSON formatting + some kind of HTTP transport (which I'm guessing is the case, here). Mostly, you'll need to format up the regular fields like Timestamp manually, then use a JsonValueFormatter to convert each property value.

https://nblumhardt.com/2016/07/serilog-2-0-json-improvements/

HTH,
Nick

from serilog-sinks-loggly.

Hi
I found one of the reasons for this problem in loggly-csharp and fixed it neutmute/loggly-csharp#60

However, it seems that default exception serialization produces a string of more than 5MB even for simple cases (where there's a stack trace).

The loggly appender of log4net uses the builtin GetExceptionString method that generates a simplified string. Maybe we coukd do the same? I can send a PR

from serilog-sinks-loggly.

@tamirdresher thanks! Any and all help appreciated. @jonstelly does that sound like it lines up with what you were looking for?

from serilog-sinks-loggly.

That looks great and it definitely seems better to fix this upstream in loggly-csharp.

As for the size of the exception, @tamirdresher, 5MB is pretty big, are you really seeing that with most exceptions? With the following super-simple test the exception JSON is 1255 characters

Running in ASP.NET and elsewhere will definitely give a much deeper stack trace and more data so I'm sure they'll be larger, but what's the primary contributor getting the JSON to 5MB?

static void Main(string[] args)
        {
            DoStuffAsync(args).Wait();
        }

        static async Task DoStuffAsync(string[] args)
        {
            try
            {
                try
                {
                    await Task.Delay(100);
                    throw new ArgumentNullException(nameof(args), "Missing args");
                }
                catch (Exception first)
                {
                    throw new InvalidOperationException("Something bad", first);
                }
            }
            catch (Exception second)
            {
                var json = JsonConvert.SerializeObject(second, Formatting.Indented, new JsonSerializerSettings
                {
                    ReferenceLoopHandling = ReferenceLoopHandling.Ignore
                });
                Console.WriteLine("{0} characters\r\n{1}", json.Length, json);
            }
        }

from serilog-sinks-loggly.

The size was a surprise to me as well.
My use case is indeed an exception that is thrown from the ASP.NET Core controller, but i'm still not sure why it gets to these sizes.
I'll create a repro and share it.
And i hope to fix my PR by tomorrow

from serilog-sinks-loggly.

@jonstelly
I think i figured it out. The problem only occurs in .NET Core because the Exception class was changed and no longer implement ISerializable (https://github.com/dotnet/coreclr/issues/2715) .
Running the same application in .NET Core yields a very large output. The reason is for that is that the TargetSite property is serialized as well.
Looking into the Exception class code in the full .NET Framework shows that when Exceptions were serialized, the TargetSize was ignored and instead, a minification of the value was used

from serilog-sinks-loggly.

Fixed in #22

from serilog-sinks-loggly.