我的团队继承了对 100 多个应用程序的支持。这些应用程序没有任何类型的通用架构，因此进行日志记录的应用程序通常使用自定义代码到本地文件或本地数据库来完成，而且都是非托管的。我们想改变这一点。
我们正在慢慢将应用程序迁移到使用 log4net 并标准化记录的事物类型。下一个问题变成：我们应该将日志发送到哪里？
我在想最好使用一个专用于接收所有日志的中央 SQL Server，这将提供易于维护（一个用于备份/存档的地方）并为未来的一些数据挖掘和趋势分析提供可能性。
这是这类事情的最佳实践，还是我们应该考虑一些专用的应用程序日志服务器？
更新：我应该比随便提到 log4net 和 SQL Server 更清楚：我们是微软公司，大多数东西都是用 .NET 编写的。UNIX 解决方案对我们没有好处。
一个警告世界：在一家大商店里有 100 多个应用程序，有成百上千台主机运行这些应用程序，请避开任何会导致紧密耦合的东西。这几乎排除了直接连接到 SQL Server 或任何数据库解决方案的可能性，因为您的应用程序日志记录将取决于日志存储库的可用性。
中央存储库的可用性比“如果无法连接，请不要记录它”稍微复杂一点，因为通常最有趣的事件发生在出现问题时，而不是在事情顺利进行时。如果您的日志记录恰好在事情变得有趣时删除条目，那么它将永远不会被信任来解决事件，因此将无法获得其他利益相关者（即应用程序所有者）的牵引力和支持。
如果您决定自己实现保留并重试失败的日志信息传递，那么您将面临一场艰苦的战斗：这不是一项微不足道的任务，而且比听起来要复杂得多，从保留信息的高效可靠存储开始并以建立良好的重试和智能后备逻辑结束。
您还必须对身份验证和安全问题有一个答案。大型组织有多个具有各种信任关系的域，员工通过 VPN 或在家中直接访问进行冒险，一些应用程序在无人值守的情况下运行，一些服务配置为本地用户运行，一些机器没有加入域等。你最好有回答这个问题的每个应用程序的日志记录模块如何部署，无处不在，将通过中央存储库进行身份验证（以及哪些情况将不被支持）。
理想情况下，您将为日志记录模块使用开箱即用的交付机制。MSMQ 可能是最合适的选择：健壮的异步可靠交付（至少在大多数用例的范围内），安装后可在每个 Windows 主机上使用（可选）。这是主要的痛点，您的应用程序将依赖于非默认操作系统组件。
中央存储库存储必须能够交付请求的信息，也许：
唯一能够为任何重要的组织（大小、生命周期）提供此功能的存储是关系引擎，因此可能是 SQL Server。对文本文件进行分析真的不会走得太远。
因此，我会推荐一个基于消息传递的日志传输/传递 (MSMQ) 和一个关系中央存储库 (SQL Server)，可能在其之上带有一个分析组件（分析服务数据挖掘）。如您所见，这显然是一项不小的壮举，它所涵盖的内容不仅仅是配置 log4net。
至于要记录什么，你说你已经考虑过了，但我想补充一下我的额外 2c：通常，特别是在事件调查方面，你会喜欢请求额外信息的能力。这意味着您想知道事件机器中的某些文件内容、某些注册表项、某些性能计数器值或完整进程转储。能够从中央存储库接口请求此信息非常有用，但始终收集此信息以防万一是不切实际的。这意味着应用程序和中央存储库之间必须存在某种双向通信，当应用程序报告事件时，可以要求它添加额外信息（例如，故障进程的转储）。
我知道这个答案目前可能看起来有点矫枉过正，但我参与这个问题空间已经有一段时间了，在我使用 MS 的那一天，我看过 Watson 博士的许多在线崩溃报告，我可以告诉您存在这些要求，它们是有效的关注点，并且在实施时，解决方案会提供极大的帮助。最终，您无法解决无法衡量的问题。大型组织依赖于对其应用程序库存的良好管理和监控，包括日志记录和审计。
有一些第三方供应商提供解决方案，有些甚至与 log4net 集成，如bugcollect.com （完全披露：这是我自己的公司）、错误流量控制器或Exceptioneer等。
Logstash + Elasticsearch + Kibana + Redis 或 RabbitMQ + NLog 或 Log4net
存储 + 搜索和分析：Elasticsearch
收集和解析：Logstash
可视化：Kibana
队列和缓冲区：Redis
在应用程序中：NLog
到目前为止提到的 1024 字节 Syslog 消息长度限制具有误导性，并且不正确地偏向基于 Syslog 的问题解决方案。
过时的“BSD Syslog 协议”的限制确实是 1024 字节。
BSD syslog 协议 - 4.1 syslog 消息部分
现代“系统日志协议”的限制取决于实现，但必须至少为 480 字节，至少应为 2048 字节，并且可能更高。
例如，Rsyslog 的配置设置称为MaxMessageSize，文档建议至少可以将其设置为 64kb。
提问者的组织是“微软之家”，其中“UNIX 解决方案不好”不应该阻止歧视较少的读者获得准确的信息。
SQL 可以工作，但我使用Splunk来聚合日志。根据 Splunk 允许您为数据设置索引的方式，我能够找到一些令人惊讶的信息，然后使用他们的查询工具制作一些漂亮的图表。您也可以免费下载它的基本版本。
正如其他回复所指出的，最接近行业标准的是syslog。但不要因为您生活在 Windows 世界中而感到绝望。 Kiwi 有一个在 Windows 上运行的系统日志守护程序，它是免费的。 了解更多。
更新
正如@MichaelFreidgeim 指出的那样，Kiwi 现在为其系统日志守护程序收费。但是，还有其他免费的替代品。This other SO answer链接到其中的几个。
如果您有 log4net 日志到本地 EventViewer，您可以在 Windows 2008 机器上挖掘这些日志，请参阅这篇集中审计文章。
然后，您可以在该框中轻松导入这些事件并在其之上提供一些管理和挖掘工具。
正如其他人已经指出的那样，将大量应用程序和主机的日志直接定向到数据库并不是一个好主意。我只是想增加一个支持使用专用集中式日志服务器的优势 - 它将您的应用程序与日志基础架构分离。由于您在 .Net 中，因此有几个不错的选择 - log4net和NLog. 两者都是非常好的产品，但我特别喜欢 NLog，它被证明在负载更重的情况下表现更好，具有更好的配置选项并且得到积极维护。据我所知，Log4Net 已经有几年没有改变了，并且存在一些问题，但仍然是非常强大的解决方案。因此，一旦您使用了这样的框架，您就可以在应用程序级别控制它如何、什么以及何时将其日志传输到集中式服务器。如果有的话。
查看专为您描述的情况而构建的logFaces - 聚合来自大量应用程序和主机的日志，为分析和监控提供集中存储和源。并且在您现有的代码库中进行零更改，并不会侵入性地进行所有这些操作。它将处理大量的应用程序和主机负载，并让您指定要对数据执行的操作。另一方面，您有非常好的 GUI用于实时监控或挖掘数据。您根本不必直接处理数据库。有许多数据库可供选择 - SQL 和 NoSQL。顺便说一句，RDBS 在数据存储量很大的情况下并不是表现最好的。logFaces 可以与MongoDB一起使用- 这种设置通常比最好的传统 RDBS 品牌好十倍左右。特别是与封顶集合一起使用时。
（为了披露，我是logFaces的作者）
如果您在 *nix 机器上运行，传统的解决方案是syslog。
