日志分析的“以度量指标为先”的方法

导航至

我们刚刚完成了一项年度调查,调查对象包括我们的社区成员以及 InfluxDB 企业版和 InfluxDB Cloud 的客户。对于那些参与了调查的人,感谢您抽出时间提交您的回复。希望您喜欢您的新袜子!

在调查结果中,我们看到 27% 的您已经在使用 InfluxDB 来收集和分析日志以及数值指标和事件。我们认为您会发现我们对 Telegraf 和 Chronograf 的最新增强功能非常有趣,对于那些还没有的话……继续阅读!

当您利用度量指标作为检测异常的早期预警系统时,您可能需要深入挖掘其他可用的上下文数据,这些数据有助于引导您解决您监控和管理的事物中出现的问题;包括应用程序、系统、传感器、数据库等。这很可能意味着您拥有大量的非指标数据,通常被称为“数字垃圾”,以日志文件的形式存在。

从超过 50 多种日志管理工具中——其中存在一些非常优秀的技术——有许多选择用于收集和搜索这些“垃圾”,以期望发现一些重要或有价值的东西。如果您花时间与您的系统和日志文件打交道,您将积累关于各种消息含义的知识,了解为什么这些事件被触发,以及根据您处理过的问题产生的模式,心理上关联重要信息行。但为什么呢?

InfluxData坚信以“指标优先”的方法来进行监控和管理。这意味着指标是你的指南。收集指标为您提供基线遥测数据,这些数据可以告诉您关于系统、应用程序和传感器各个组件的健康状况。这些指标还可以指出您何时开始偏离常规,哪些系统组件受到影响,并为指标的图形表示提供有价值的元数据。访问日志数据是次要的、重要的上下文来源,有助于您进一步分类和解决问题。在某个时候,错误计数或偏离常规的数量是不够的:您需要看到实际的日志细节才能诊断问题。但是,作为一个操作大量应用程序、传感器或系统的人,您不应该只通过日志“猜测”问题和查找位置,也不需要打开另一个独立的工具来获取这些详细信息。

Telegraf 1.7 中的 Syslog 解析功能介绍

为了帮助解决我们的客户和社区成员面临的此类挑战,我们发布了Telegraf 1.7。具体来说,在Telegraf 1.7版本中,我们增加了一个高性能syslog插件,允许使用Telegraf支持的任何输出源进行日志收集和存储。对于那些已经使用syslog作为收集日志手段的人,我们鼓励您尝试一下。

现在,日志文件包含事件集合,这些事件通常是带时间戳的——猜猜看什么技术可以很好地收集、分析和处理时序数据?

如果您说的是InfluxDB……恭喜您!但是,根据调查结果,许多社区成员和客户还没有将InfluxDB作为积累日志事件的场所。自1.0版本发布以来,Telegraf logparser插件已经存在,它支持解析grok风格的日志模式。这可以是一种强大的方法来解决分布式日志文件并将它们与InfluxDB一起收集,但由于许多人使用syslog协议收集日志,因此添加这种额外的机制来利用该协议并简化通过Telegraf收集日志数据是有意义的。此外,我们努力使这一功能真正快速高效

在Chronograf中查看日志

我们不会就此止步!随着Chronograf 1.5的推出,我们提供了以表格格式可视化非指标数据的能力。对于那些使用Telegraf、InfluxDB和Chronograf组合的人来说,这意味着应该很容易在仪表板中快速可视化日志数据。使用Chronograf中可用的指标、元数据和时间范围,您可以快速定位要查看的日志数据量——基于对常规的特定偏差。如果您想查看与显示的特定仪表板时间相关的某些日志事件,您可以修改提取日志数据的查询,包括从指标共享的元数据以及仪表板时间,并自动过滤相关日志。无需猜测搜索条件!但是,对于那些仍希望更详细地探索日志的人,Chronograf即将推出的版本包括日志可视化组件。您现在就可以开始探索了——通过Chronograf的夜间构建,该构建可在下载页面上找到。

对于那些需要帮助找到它的人,请查看左侧导航面板中的“日志”图标。它实际上很难错过!

我们的下一步计划

日志查看器目前绑定到由新Telegraf syslog插件创建的syslog度量。然而,随着我们对日志查看器的持续开发,我们计划添加更多的配置选项,包括更改各种列的位置、顺序和可见性——就像表格控件一样。我们还计划提供添加更多标签可视化的能力,如果您已经扩展了Telegraf插件以提供额外的上下文数据来帮助您分析日志事件本身捕获的事件。我们还希望使在仪表板和日志查看器之间跳转变得简单,并可能为仪表板制作可嵌入的日志查看器图形类型——节省额外的时间和精力。

在您开始探索Telegraf和Chronograf的所有新功能之前,重要的是要指出一些我们计划不解决的问题和反模式。首先,InfluxDB并不打算成为日志存档。如果您需要为合规性或存档目的存储更长时间的日志,有50多个日志管理工具中存在更经济的解决方案。最好将您的日志数据保留策略与您计划执行实时操作诊断和深入挖掘的主要窗口相一致。当然,您可以从日志数据本身提取和推导出度量(由各种元数据标签:主机、严重性等计数的数量)——并有效地减少该信息,同时消除消息本身。这将为此度量第一方法创建一个历史基线,并在您的计数开始超过这些历史规范时发出早期警报。

如果您正在寻找更高级的分析用例——例如SIEM风格的用户和实体行为分析或基于事件数据的基于事件的安全编排和自动响应——这不是我们从“开箱即用”的用户界面角度计划解决的问题。通常,这些用例需要更长时间的日志存档以及在整个数据集上运行的更复杂的机器学习算法。

随着我们继续简化并使整体体验更加轻松,可能还会添加更多的分析功能。例如,如果您的日志事件包括相关ID,我们可以计算事件之间的时间并在直方图上绘制它们。这里还有更多的事情要做,但我们刚刚开始强调您可以使用度量第一方法查看、探索和分析支持日志事件的能力。我们试图提高您系统的整体可观察性、应用程序和传感器,同时使问题解决更快。让我们在社区网站上听听您的想法。