Serilog MSSQL Sink不会将日志写入数据库

本文介绍了Serilog MSSQL Sink不会将日志写入数据库的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我创建了一个.Net类库（4.6.2），并创建了serilog实现，该实现由其他接口（例如控制台应用程序）调用。现在，当我使用文件接收器类型时，日志将被写入文件，但是使用MSSQL接收器，日志记录就不会这样做。 使用autoCreateTable选项提供的列选项创建日志表

I have created a .Net class library (4.6.2) and created serilog implementation which is called by other interfaces such as console app. Now when I use File sink type, the logs are getting written to the files but with MSSQL sink, its not doing so. The log tables are getting created with column options as provided with autoCreateTable options

ILogger logger = new LoggerConfiguration() .WriteTo.MSSqlServer(connectionString, tableName, autoCreateSqlTable: autoCreateSqlTable, restrictedToMinimumLevel: LogEventLevel.Verbose, columnOptions: GetSQLSinkColumnOptions(), batchPostingLimit: batchPostingLimit) .CreateLogger();

我还启用了serilog的自记录功能，但未显示任何异常。找不到相同的有用解决方案。

I have else enabled selflogging of serilog but no exceptions are displayed. Not found any helpful solution for the same.

但是正在生成日志表。我已经检查了用户的权限，并且也具有正确的权限。

The log table is however getting generated. I have checked the permissions for the user and that is also having the correct permissions.

下面是代码的快照。

public static class GenericLogger { private static ILogger _usageLogger; private static ILogger _errorLogger; static GenericLogger() { var logTypes = LogConfigurationHelper.GetLogTypes(); if (logTypes != null && logTypes.Count > 0) { foreach (var logType in logTypes) { ConfigureLogger(logType.Id); // Intitalizes logs based on //configuration. } } Serilog.Debugging.SelfLog.Enable(msg => { Debug.Print(msg); Debugger.Break(); }); } ///The write log function /// public static void WriteError(LogDetail infoToLog) { if (infoToLog.Exception != null) { infoToLog.Message = GetMessageFromException(infoToLog.Exception); } _errorLogger.Write(LogEventLevel.Information, "{Timestamp}{Product}{Layer}{Location}{Message}" + "{Hostname}{UserId}{UserName}{Exception}{ElapsedMilliseconds}" + "{CorrelationId}{CustomException}{AdditionalInfo}", infoToLog.TimeStamp, infoToLog.Product, infoToLog.Layer, infoToLog.Location, infoToLog.Message, infoToLog.Hostname, infoToLog.UserId, infoToLog.UserName, infoToLog.Exception?.ToCustomString(), infoToLog.ElapsedMilliseconds, infoToLog.CorrelationId, infoToLog.CustomException, infoToLog.AdditionalInfo); // To add ((IDisposable) _errrorLog).Dispose(); } }

推荐答案

下面是一些可以帮助您进行故障排除的想法：

Below are some ideas that could help you troubleshoot:

您是否正在使用详细测试或 Debug 事件？那可能就是原因。您没有为Serilog指定全局最低级别（仅为接收器指定了最低级别，它充当过滤器），而默认最小值为信息 ，表示详细

Are you testing with Verbose or Debug events only? That could be the reason. You didn't specify a global minimum level for Serilog (you only specified for the minimum level for the sink, which acts as a filter), and the default minimum is Information, which means Verbose and Debug are being ignored... Specify the global MinimumLevel for Serilog:

ILogger logger = new LoggerConfiguration() .MinimumLevel.Verbose() .WriteTo.MSSqlServer(connectionString, tableName, autoCreateSqlTable: autoCreateSqlTable, restrictedToMinimumLevel: LogEventLevel.Verbose, columnOptions: GetSQLSinkColumnOptions(), batchPostingLimit: batchPostingLimit) .CreateLogger();

您要处置记录仪吗？ Serilog.Sinks.MSSqlServer 是一个定期批处理接收器，因此您需要确保在最后处置记录器，以强制其将日志刷新到数据库。参见记录器的生命周期。

Are you disposing your logger? Serilog.Sinks.MSSqlServer is a "periodic batching sink", so you'll need to make sure you dispose the logger at the end to force it to flush the logs to the database. See Lifecycle of Loggers.

((IDisposable) logger).Dispose();

即使您使用 1 batchPostingLimit ，在将日志发送到数据库之前，它默认等待 5 秒。如果您的应用程序在那段时间之前关闭并且您没有处置记录器，则消息将丢失。

Even though you're using 1 for batchPostingLimit, it waits 5 seconds by default before sending the logs to the database. If your app closes before that period and you didn't dispose the logger, the messages are lost.

故障排除，请使用 AuditTo 代替 WriteTo （并删除 batchPostingLimit ，不适用于审核）。 WriteTo 是安全的，可以吃掉任何异常，而 AuditTo 可以让异常冒出来。

For the sake of troubleshooting, use AuditTo instead of WriteTo (and remove the batchPostingLimit which is not applicable for auditing). WriteTo is safe and will eat any exceptions, whilst AuditTo will let exceptions bubble up.

ILogger logger = new LoggerConfiguration() .AuditTo.MSSqlServer( connectionString, tableName, restrictedToMinimumLevel: LogEventLevel.Verbose, autoCreateSqlTable: true) .CreateLogger();

当然，一旦找出问题所在，请回到 WriteTo 。

Of course, once you figure out what's wrong, go back to WriteTo.