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

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

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

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

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

更新:我应该更清楚,而不仅仅是随便提一下log4net和SQL Server:我们是微软的家,大多数东西用.NET编写.UNIX解决方案对我们没有好处.

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

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

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

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

中央存储库存储必须能够提供所请求的信息,可能:

应用程序开发人员调查事件

客户支持团队调查客户投诉报告的丢失交易

进行取证的安全组织

业务经理要求统计,趋势和汇总信息(BI).

能够为任何严重组织(大小,生命周期)提供此功能的唯一存储是关系引擎,因此可能是SQL Server.对文本文件进行分析实际上并不是很有意义.

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

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

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

有些第三方供应商提供解决方案,有些甚至与log4net集成,如bugcollect.com (完全披露:这是我自己的公司),错误流量控制器或Exceptioneer等.

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

存储+搜索和分析:Elasticsearch
收集和解析:Logstash
可视化:Kibana
队列和缓冲区: 应用程序中的Redis
:NLog