监控日志数据的类体系结构

本文关键字：体系结构 数据 日志 监控 | 更新日期: 2023-09-27 18:18:11

我有一个工作的实时监控程序，但它的类架构太复杂了。这让我很困扰。让我先解释一下这个程序。

用户交互

这是一个具有用户交互的监控程序。这意味着，用户可以选择不同的维度，不同的指标，包括它们，排除它们或将它们分组，并且每次实时图表都会根据用户的决定变化。

数据库日志示例

Req Success OrderFunction 5 60ms WebServer2
Req Failed  OrderFunction 2 176ms WebServer5
Resp Success SuggestFunction 8 45ms WebServer2

转换

每一行都很重要，每一列都很重要。它必须像这样在客户端。因为用户可以选择查看成功的OrderFunctions或WebServer2上的所有函数或所有失败的请求等。我需要这些列之间的所有关系来做这些

另一件事是这些值来自数据库。我还查找了这些值，其中包含用户需要看到的文本。就像Req是Request一样，Resp是Response。

我知道你可以把这个问题看作是一个普遍的问题。但我在想办法。也许这种类架构在业界有名气。我只是来征求一些建议，引导我走上正确的道路。

Thanks to lot

监控日志数据的类体系结构

每3分钟记录15k条记录，听起来很像我过去在数据中心中看到的网络监控应用程序(snmp在这种环境中会变得非常嘈杂)。我们要做的是确定我们需要多少数据，多长时间，在什么粒度级别上，这些信息将用于确定使用哪种类型的卷取策略，以及我们愿意为问题投入多少存储空间。对于累积策略，通过合并列来组合随时间变化的行，可以确保对数据库的大小有一个有限的限制。

这些天可能有更新的工具，但我曾经使用RRD (http://oss.oetiker.ch/rrdtool/)和BerkeleyDB来处理这些类型的监控问题。您还可以利用一些软件重复数据删除，在这种方法中，如果发现一行与前一行相似，只需根据其列的内容的性质更新计数。我们过去这样做是为了防止事件风暴淹没NOC屏幕，导致技术人员错过关键事件。顺便说一下，我本来可以把这个作为评论，但是stackoverflow的名声阻止了我，我昨天才开始在这里回答问题。

所以为了更完整，以你的数据为例:

Req Success OrderFunction 5 60ms WebServer2
Req Failed  OrderFunction 2 176ms WebServer5
Resp Success SuggestFunction 8 45ms WebServer2

我假设Req/Resp是唯一的两个值-对应于请求和响应?如果是这种情况，将该列设置为二进制，1位—无论它是否是请求。第二列，成功/失败-听起来像一个1位或最坏的三进制，2位字段。函数(OrderFunction，建议函数等)可能是枚举的-或者如果你在这里做重复数据删除，你可能会把它作为一个位掩码。您也可以在连接表中使用外键。在枚举选项中，假设你有少于256个但多于128个，使用一个字节。如果你可以把它们卷起来在一个事件重复数据删除解决方案为了拯救行,尤其是当他们正在快速进入,和你有256选项,然后你需要许多比特位掩码,除非是,并不是每一个排列需要代表,在这种情况下,计算出的最大数量排列,这就是你的位掩码的比特数正确卷起的重复数据删除。下一列有5 2 8，我不确定它代表什么，是某种整数还是一个字节?毫秒可以表示，这取决于您的SQL方言和您期望需要表示的最大毫秒数，可以用int或unsigned short表示，也可以只用short表示(基本上大约是32.7秒)。如果您使用short或unsigned short，只需确保在应用程序逻辑中将超过max的值表示为max，而不是零。最后一列看起来像一个表示服务器的字符串，因此您可能会使用这一列来帮助指导重复数据删除或上滚。所以你可以把它作为外键

不管怎样，RRD曾经真的很好，但是我已经有近十几年没有使用它了——我收回这句话，我已经有十几年没有使用RRD了:)。我相信BerkeleyDB对于这类事情来说仍然是一个很好的数据库，所以看看这些工具和类似的工具，我相信一个好的解决方案会出来的。

希望有帮助!

相关文章：