集中式日志记录的最佳实践是什么？

Question

我的团队继承了对100多个应用程序的支持。应用程序没有任何类型的通用体系结构，因此进行日志记录的应用程序通常使用自定义代码来执行本地文件或本地数据库，并且它们都是非托管的。我们想改变它。

我们正在慢慢地将应用程序迁移到使用log4net并标准化记录的事物类型。接下来的问题是：我们应该在哪里发送日志？

我认为使用专用于接收所有日志的中央SQL Server会很好，这将提供简单的维护（一个备份/归档的位置），并提供一些数据挖掘和趋势分析的未来可能性。

这是这种事情的最佳做法，还是我们应该关注一些专用的应用程序日志记录服务器？

更新：我应该更清楚，而不仅仅是随便提一下log4net和SQL Server：我们是微软的家，大部分都是用.NET编写的。 UNIX解决方案对我们没有好处。

Answer 1

一个值得关注的世界：在一家大型商店中有超过100个应用程序，有数百个可能正在运行这些应用程序的主机，避开任何导致紧密耦合的东西。这几乎排除了直接连接到SQL Server或任何数据库解决方案，因为您的应用程序日志记录将取决于日志存储库的可用性。

中央存储库的

可用性比“如果你无法连接，不记录它”复杂一点，因为通常最有趣的事件发生在有问题时，而不是事情进展顺利。如果您的日志记录在事情变得有趣时完全丢弃条目，那么它将永远不会被信任解决事件，因此无法获得牵引力并支持其他利益相关者（即应用程序所有者）。
如果您决定自己实施保留并重试失败的日志信息传递，那么您将面临一场艰苦的战斗：这不是一项微不足道的任务，而且要比保留信息的有效和可靠存储更加复杂。最后是实施良好的重试和智能后备逻辑。

您还必须解决身份验证和安全性问题。大型组织具有多个具有各种信任关系的域，员工通过VPN或从家中直接访问，一些应用程序无人值守运行，一些服务配置为以本地用户身份运行，一些计算机未加入域等等。您最好拥有问题是如何部署每个应用程序的日志记录模块，以及如何使用中央存储库进行身份验证（以及哪些情况将不被移植）。

理想情况下，您将为日志记录模块使用开箱即用的交付机制。 MSMQ可能是最适合的：强大的异步可靠交付（至少在大多数用例的范围内），可在每个Windows主机安装时提供（可选）。哪个是主要的痛点，您的应用程序将依赖于非默认的OS组件。

中央存储库存储必须能够提供所请求的信息，可能是：

• 应用程序开发人员调查事件
• 客户支持团队调查客户投诉报告的丢失交易
• 进行取证的安全组织
• 业务经理要求统计，趋势和汇总信息（BI）。

唯一能够为任何严重组织（大小，生命周期）提供此功能的存储是关系引擎，因此可能是SQL Server。对文本文件进行分析实际上不会有所作为。

因此，我建议使用基于消息传递的日志传输/传递（MSMQ）和关系中央存储库（SQL Server），或者在其上部使用aanalitycal组件（Analysis Services数据挖掘）。正如你所看到的，这显然不是一件小事，它仅仅涵盖了配置log4net。

关于记录什么，你说你已经考虑过了，但我想在我的额外2c中加油：经常，特别是在事件调查中，你会想要请求额外信息的能力。这意味着您希望了解事件计算机中的某些文件内容，某些注册表项，某些性能计数器值或完整的进程转储。能够从中央存储库接口请求此信息非常有用，但总是收集此信息是不切实际的，以防万一需要。这意味着应用程序和中央存储库之间必须存在某种双向通信，当应用程序报告事件时，可以要求它添加额外信息（例如，故障转移过程）。从应用程序日志记录和中央存储库之间的协议到中央存储库识别事件重复的能力，以及收集登录库的能力，必须有很多基础设施来实现这样的事情。所需的额外信息，尤其是操作员将事件标记为需要关于下次发生的额外信息的能力。

我理解这个答案似乎有点过头了，但我参与了这个问题空间已经有一段时间了，我看过许多来自Watson博士的在线崩溃报告，当时我和MS一起工作，我可以告诉你，这些要求存在，它们是有效的关注点，并且在实施时解决方案有很大帮助。最终，你无法修复你无法衡量的东西。一个大型组织依赖于良好的管理和对其应用程序库存的监控，包括日志记录和审计。

有些第三方供应商提供解决方案，有些甚至与log4net集成，例如bugcollect.com（完全披露：这是我自己的公司），Error Traffic Controller或Exceptioneer等。< / p>

Answer 2

Logstash + Elasticsearch + Kibana + Redis或RabbitMQ + NLog或Log4net

存储+搜索＆amp;分析：Elasticsearch
收集和收集解析：Logstash
可视化：Kibana
队列和缓冲区：Redis
在申请中：NLog

Answer 3

SQL可行，但我使用Splunk来聚合日志。我能够根据Splunk允许您设置数据索引的方式找到一些令人惊讶的信息，然后使用他们的查询工具制作一些不错的图表。您也可以免费下载它的基本版本。

Answer 4

到目前为止提到的1024字节Syslog消息长度限制是误导性的，并且错误地偏向于基于Syslog的解决方案。

过时“BSD Syslog协议”的限制确实是1024字节。

The BSD syslog Protocol - 4.1 syslog Message Parts

现代“Syslog协议”的限制是依赖于实现的，但必须至少为480字节，应该至少为2048字节，并且可能更高。

The BSD syslog Protocol - 6.1. Message Length

例如，Rsyslog的配置设置称为MaxMessageSize，文档建议可以将其设置为至少高达64kb。

rsyslog - Configuration Directives

提问者的组织是“微软的房子”，其中“UNIX解决方案不好”不应该阻止较少歧视的读者获取准确的信息。

Answer 5

正如其他答复所指出的那样，与行业标准最接近的是syslog。但不要绝望，因为你生活在Windows世界。 Kiwi有一个在Windows上运行的syslog daemaon，它是免费的。 Find out more

<强>更新
正如@MichaelFreidgeim指出的那样，Kiwi现在收取他们的syslog守护进程的费用。但是，还有其他免费的替代品。这个other SO answer链接到其中几个。

Answer 6

如果您有log4net登录到本地EventViewer，您可以在Windows 2008框中挖掘这些日志，请参阅此centralized auditing article。

在该框中，您可以轻松导入这些事件，并在其上提供一些管理和挖掘工具。

Answer 7

正如其他人已经指出的那样，将日志从应用程序和主机的大小直接导向数据库并不是一个好主意。我只是想增加一个优势，支持使用专用的集中式日志服务器 - 它将您的应用程序与日志基础架构分离。由于你在.Net，有几个不错的选择 - log4net和NLog。两者都是非常好的产品，但我特别喜欢NLog，它被证明是更好的表现，负载更重，配置选项更好，并且积极维护。据我所知，Log4Net在几年内没有改变并且有一些问题，但仍然是非常强大的解决方案。因此，一旦您使用此类框架，您就可以在应用程序级别控制如何，何时以及何时将其日志传输到中央服务器。如果有的话。

查看专为您描述的情况而构建的logFaces - 从提供集中存储的应用程序和主机的大小聚合日志以及分析和监视的来源。并且在您现有代码库中零改变的情况下，不要干扰这一切。它将处理大量的应用程序和主机，并允许您指定要对数据执行的操作。另一方面，您有very nice GUI用于实时监控或挖掘数据。您根本不必直接处理数据库。有许多数据库可供选择 - 包括SQL和NoSQL。 BTW，RDBS并不是拥有超大数据存储的最佳表现者。 logFaces可以与MongoDB一起使用 - 这种设置通常比最好的传统RDBS品牌高出10倍左右。特别是与封顶集合一起使用时。

（对于披露，我是logFaces的作者）

Answer 8

如果你在* nix机器上运行，传统的解决方案是syslog。

Answer 9

在Unix上，有syslog 另外，您可能需要查看this case study。