我们目前有一个自定义日志系统。它是一个将日志推送到Microsoft SQL服务器的dll。这些日志通过网页查看，具有高级排序/过滤/分页/下载。我是从头开始构建系统的，我是Entity Framework的新手，在SQL中并不是超级强大。
一位同事坚持认为Windows事件日志是比SQL服务器更好的选择，因为它可以节省带宽，因此更快。此外，它是一个经过验证的真正解决方案。
我质疑使用Windows事件日志来处理我们广泛的日志记录的实用性。目前在SQL中我们有一个Log表，它可以容纳大约1.5亿个日志，从大约600个应用程序中的约100个不同的机器收到的日志大约为90gb。
使用Windows事件日志是否适用于此类负载？然后为管理服务器/用户创建一种方法，在没有中间SQL的情况下请求/排序/过滤/分页这些日志？或者我只是因为建立了当前的系统而蒙蔽了眼睛？
其他信息
Log是单个表Log（Id，AppId，Type，Lvl，Source，Msg，Time）
1.5亿个日志包含错误7天，其他所有错误包括3天
规范化Source和Msg会大大减少表的大小，因为有许多重复的消息。
关于当前系统的大多数抱怨是在请求日志时网页在某些应用程序上超时。超时仍为30秒，日志总数限制为10,000，此时您必须优化搜索。超时实际上仅发生在平均为800k +日志的应用程序上。其他应用返回的结果平均最长为10秒。
我正在对索引进行更改，并考虑对表进行规范化以提高效率，但这是一个持续的过程。如果Windows事件日志是一个更好的解决方案，但我宁愿花时间实现它。
答案 0 :(得分：3)
这是我个人的意见
分布式系统的Windows事件日志记录是一个坏主意。
您将日志集中到应用程序的想法非常棒。这将帮助您进行统计，您有备份机制，可以使用sql server进行集群等。
如果人们抱怨性能问题，也许是时候考虑优化您的解决方案了。指数可能？看看可以编入索引的内容。确保SQL Server在使用WHERE条件时可以使用您的搜索参数（SARGS）。
您可以将数据拆分成多个表格吗？也许应该调查你的数据规范化。
您还可以查看用户使用的预制过滤器并使其可用并对其进行处理（性能）
这只是一个开始。可能还有我们不知道的细节，您无法透露