事件日志实用性

Event Log practicality

我们目前有一个自定义日志系统。它是一个将日志推送到 Microsoft SQL 服务器的单个 dll。这些日志是通过网页查看的,高级 sorting/filtering/paging/download。我从头开始构建系统,我是 Entity Framework 的新手,在 SQL 方面不是很强大。

一位同事坚持认为 Windows 事件日志是比 SQL 服务器更好的选择,因为它可以节省带宽,因此速度更快。此外,这是一个久经考验的真实解决方案。

我质疑使用 Windows 事件日志来处理大量日志记录的实用性。目前在 SQL 中,我们有一个日志 table,它托管了从约 600 个应用程序的约 100 台不同机器接收到的约 1.5 亿条日志,总计约 90gb。

使用 Windows 事件日志是否是针对此类负载的可行解决方案?然后为管理员 server/user 创建一种无需中介 SQL 即可 request/sort/filter/page 那些日志的方法?还是我只是因为构建了当前系统而蒙蔽了双眼?

附加信息

Log 是单个 table Log(Id, AppId, Type, Lvl, Source, Msg, Time)

1.5 亿日志涵盖 7 天的错误,3 天的所有其他内容

规范化 Source 和 Msg 会大大减少 table 的大小,因为有很多重复的消息。

对当前系统的抱怨最多的是在某些应用程序请求日志时网页超时。超时仍为 30 秒,日志总数限制为 10,000,届时您必须优化搜索。超时实际上只发生在平均有 800k+ 日志的应用程序上。其他应用 return 结果平均最多 10 秒。

我正在对索引进行更改,并考虑过规范化 table 以提高效率,但这是一个持续的过程。如果 Windows 事件日志是一个更好的解决方案,但我宁愿花时间实现它。

这是我个人的意见

Windows 分布式系统的事件日志不是一个好主意。

您为应用程序集中日志的想法很棒。这样可以帮你做统计,你有备份机制,可以用sql服务器做集群等

如果人们抱怨性能问题,也许是时候考虑优化您的解决方案了。指数也许?看看什么可以被索引。确保 SQL 服务器在使用 WHERE 条件时可以使用您的搜索参数 (SARGS)。

你能把你的数据拆分成多个表吗?也许应该研究规范化您的数据。

您还可以查看您的用户使用的预制过滤器并使它们可用并对其进行处理(性能)

这只是一个开始。可能有些细节我们不知道,你也不能透露