Problems ingesting events into Seq from Serilog

Update based on your edit:

It appears the last few messages before your program ends are the ones being dropped. You need to flush the logger to ensure Serilog forces and waits for any pending logs events before the application has time to exit:

public static void Main() 
{
   try
   {
       // Program Logic here
   } 
   finally
   {
       Serilog.Log.CloseAndFlush(); 
   } 
} 

Original answer:

Structured logging properties can become quite large which leads to larger HTTP requests and increased CPU requirements to process them. The reason your events are getting "lost" is because there are limitations imposed by both Seq (the server) and the Serilog Sink that attempt to alleviate these concerns. Messages (single events or entire batches) can be dropped by either the client or the server depending on the specific configuration and the message/batch size. Notice I said "batch"; calling the Seq extension method chained against WriteTo will add a PeriodicBatchingSink (an implementation of the IBatchedLogEventSink) which wraps the SeqSink. So you don't need to try and wrap it yourself--it's already done.

So how do you alleviate your problems? Well first, you can update the settings on the Server. Seq recommends against this, however there are definite use-cases, especially if you are sending a lot of properties. Under Settings -> System -> Ingestion you can modify the "Raw ingestion payload limit" and/or the "Raw event body limit" settings. Personally, I leave the former at the default value and increased the latter based on some calculations we've made based on how we will configure the Sink itself:

Take heed of the underlined warnings! Make sure you understand the implications of modifying these settings.

Now on the client side you have a few options. The Seq extension method has a few parameters that can be used to tweak the logger's behavior.

If the batched events do not fit within eventBodyLimitBytes after they have been serialized into "compacted JSON", then the entire batch will be dropped. The batchPostingLimit is used by the PeriodBatchingSink to determine how many messages to queue up before it sends the events to the inner sink (which performs the serialization/dropping). You might also consider changing the minimum log level as it defaults to Verbose or passing in a LoggingLevelSwitch

var maxSizeBytes = 512 * 1024; // 512KB, double the default
var batchLimit = 100; // 1/10 the default
logger.WriteTo.Seq(
    "http://seq.server.com", 
    eventBodyLimitBytes: maxSizeBytes, 
    batchPostingLimit: batchLimit, 
    restrictedToMinimumLevel: LogEventLevel.Information
);

Configuring a smaller batch size could decrease the chance that you will exceed the byte limit but that will cause more HTTP requests to be sent which could be a problem of its own. Now remember, you also need to adhere to the configuration of the server; your combined event size needs to be less than the "Raw ingestion payload limit" to ensure that an entire batch isn't dropped and a single event must be smaller than "Raw event body limit".

Since I don't know anything about your actual events, I can't advise on the appropriate settings here. I can only point you in the correct direction. All I can say is that you should perform some calculations that make sense based on the server settings, knowledge of your events (and their attached properties) and your business requirements:

Your other option is to use an "Audit" sink. In this mode, Serilog will throw an exception if a log message cannot be transmitted to the target medium. When using the Seq extension method against AuditTo, a DurableSeqSink is used instead. Logs are persisted to disk first (as temporary storage) and then shipped to Seq one at a time. If you really must guarantee log messages aren't dropped (and that, if they are you are notified) this is the way to go. There's overhead here; messages must be written to a file, you need a new HTTP request per event and you need to guard all of your logging statements with try/catch. The latter point is IMO the biggest reason against this, particularly if you are using the Microsoft.Extensions.Logging.ILogger abstraction around Serilog as consumers typically expect logging to be exception free.

You can also make use of log filters/LoggingLevelSwitch and Serilog's Filter.ByExcluding to control the messages that will be sent. Furthermore, you might also consider tweaking the Destructuring depth and size to ensure that nested properties and collections are only serialized up to a maximum size.

logger.Destructure.ToMaximumDepth(5) // default 10
      .Destructure.ToMaximumStringLength(1000) // made up value, default is int.MaxValue
      .Destructure.ToMaximumCollectionCount(10) // made up, default is int.MaxValue