集中日志记录的最佳实践是什么?[关闭]

一个谨慎的世界:在一家大商店里有100多个应用程序,可能有成百上千的主机运行这些应用程序,避开任何导致紧密耦合的东西。这几乎排除了直接连接到SQL Server或任何数据库解决方案的可能性,因为应用程序日志记录将取决于日志存储库的可用性。

可利用性 中央存储库比“如果你不能连接,就不要记录”要复杂一些,因为通常最有趣的事件发生在有问题的时候,而不是事情进展顺利的时候。如果您的日志记录恰好在事情变得有趣时删除条目,那么它将永远不会被信任来解决事件,因此也无法获得对其他利益相关者(即应用程序所有者)的牵引和支持。
如果您决定自己执行保留和重试失败的日志信息传递,那么您将面临一场艰难的战斗:这不是一项微不足道的任务,而且比听起来复杂得多,从保存的信息的有效和可靠存储开始,到设置好的重试和疏忽的回退逻辑结束。

你还必须对 认证 和安全性。大型组织有多个具有不同信任关系的域,员工通过VPN或从家中直接访问,一些应用程序以无人值守的方式运行,一些服务配置为以本地用户的身份运行,一些计算机未加入域等。您最好了解每个应用程序的日志记录模块、EVerywhere被部署,将向中央存储库进行身份验证(以及哪些情况将不被报告)。

理想情况下,您将为您的日志模块使用开箱即用的交付机制。msmq可能是最合适的:在每台Windows主机上都有可靠的异步可靠交付(至少在大多数用例范围内是这样)。 何时安装 (可选)。这是主要的症结所在,您的应用程序将依赖于非默认操作系统组件。

中央存储库存储必须能够传递请求的信息,可能是:

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

唯一能够为任何重要组织(大小、生存期)提供此功能的存储是关系引擎,所以很可能是SQL Server。对文本文件进行分析真的不会走那么远。

因此,我建议您使用基于消息传递的日志传输/传递(msmq)和关系中心存储库(SQL Server),其中可能还包含一个Nalitical组件(Analysis Services数据挖掘)。正如您所看到的,这显然不是一个小的壮举,它所涵盖的范围比配置log4net稍微多一点。

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

我知道这个答案现在看起来有点过分了,但是我有一段时间都在处理这个问题,我以前在MS的时候看过沃森博士的许多在线崩溃报告,我可以告诉你这些要求存在,它们是有效的关注点,当实现这个解决方案时,它有助于实现巨大的上一年。最终,你无法修复你无法测量的东西。大型组织依赖于对其应用程序库存的良好管理和监控,包括日志记录和审计。

有些第三方供应商提供解决方案,有些甚至与log4net集成,例如 bugcollect.com (完全披露:那是我自己的公司) Error Traffic Controller 或 Exceptioneer 等等。

logstash+elasticsearch+kibana+redis或rabbitmq+nlog或log4net

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

SQL可以工作,但我已经使用了 Splunk 聚合日志。我能够根据splunk允许您对数据设置索引的方式找到一些令人惊讶的信息,然后使用它们的查询工具生成一些好的图。你也可以免费下载它的基本版本。

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

的限制 过时的 “BSD系统日志协议”实际上是1024字节。

The BSD syslog Protocol - 4.1 syslog Message Parts

的限制 现代的 “系统日志协议”依赖于实现,但必须至少为480字节,至少应为2048字节,甚至可能更高。

The BSD syslog Protocol - 6.1. Message Length

例如,rsyslog的配置设置被调用 MaxMessageSize ,文档建议可以将其设置为至少64KB。

rsyslog - Configuration Directives

询问者的组织是“微软之家”,“Unix解决方案不好”,这不应阻止歧视性较小的读者获得准确的信息。

正如其他回应所指出的,最接近行业标准的是 syslog .但不要因为你生活在一个窗户的世界而绝望。 Kiwi有一个在Windows上运行的系统日志daemaon,它是免费的。 Find out more .

更新
正如@michaelfreidgeim指出的,kiwi现在为其系统日志守护进程收费。不过,还有其他免费的选择。这个 other SO answer 链接到其中几个。

如果您有本地事件查看器的log4net日志,可以在Windows 2008框中挖掘这些日志,请参见 centralized auditing article .

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

正如其他人已经指出的,将应用程序和主机的数量级的日志直接指向数据库不是一个好主意。我只想再增加一个优势,支持使用专用的集中日志服务器——它将您的应用程序与日志基础设施分离。既然你在.NET中,有两个很好的选择- log4net 和 NLog . 两者都是非常好的产品,但我特别喜欢NLOG,它在较重的负载下表现得更好,具有更好的配置选项,并且得到了积极的维护。据我所知,log4net已经有几年没有改变了,也有一些问题,但仍然有非常强大的解决方案。所以,一旦您使用了这样的框架,您就可以在应用程序级别上控制它如何、什么以及何时将日志传输到集中式服务器。如果有的话。

看一看 logFaces 它是专门为您描述的情况而构建的——从应用程序和主机的数量级聚合日志,为分析和监控提供集中的存储和源。这样做不会干扰到现有代码库的零更改。它将处理大量的应用程序和主机,并允许您指定要对数据做什么。另一方面,你有 very nice GUI 用于实时监控或挖掘数据。您不必直接处理数据库。有许多数据库可供选择-包括SQL和NoSQL。顺便说一句,RDB并不是拥有非常大数据存储的最佳执行者。logfaces可以与 MongoDB -这种设置通常比最好的传统RDB品牌好十倍左右。尤其是与封顶收藏一起使用时。

(关于披露,我是logfaces的作者)

如果您在*nix机器上运行,传统的解决方案是 syslog .

在Unix上,有 syslog .
另外,您可能想退房 this case study .