“指标优先”的日志分析方法
作者:Tim Hall / 产品, 公司, 用例, 开发者
2018 年 6 月 14 日
导航至
我们刚刚完成了针对社区成员以及 InfluxDB Enterprise 和 InfluxDB Cloud 客户的年度调查。对于参与调查的各位,感谢您抽出时间提交回复。希望您喜欢您新的袜子!
在调查结果中,我们看到 27% 的用户已经在将 InfluxDB 用于收集和分析日志以及数值指标和事件。我们认为您会发现我们对 Telegraf 和 Chronograf 的最新增强功能非常有趣,而对于那些还没有使用的用户……请继续阅读!
当您利用指标作为检测异常的早期预警系统时,您可能会更深入地挖掘其他可用的上下文数据,这些数据可以帮助您指导您解决在您监控和管理的事物中出现的问题;跨应用程序、系统、传感器、数据库等。这很可能意味着您拥有大量的非指标数据,通常被称为“数字尾气”,以日志文件的形式存在。
从 50 多个日志管理工具(其中存在一些非常精细的技术)中,有很多选择可以收集和搜索尾气,希望能发现一些重要或有价值的东西。如果您花时间研究您的系统及其日志文件,您就会积累关于各种消息意味着什么、为什么触发这些事件的知识,并根据您在处理问题时看到的模式,在脑海中关联重要的信息行。但是为什么呢??
InfluxData 坚信“指标优先”的监控和管理方法。这意味着指标是您的指南。指标的收集为您提供基线遥测数据,告诉您关于系统、应用程序和传感器各个组件的健康状况。这些指标还指出您何时开始偏离常态,系统的哪些部分受到影响,并提供有价值的元数据来补充指标本身的图形表示。访问日志数据是次要的,但也是重要的上下文来源,可以帮助您进一步分类和解决问题。在某些时候,错误计数或偏离常态的程度是不够的:您需要查看实际的日志详细信息才能诊断问题。但是,作为操作大量应用程序、传感器或系统的人员,您不应该“猜测”何时何地仅使用日志查找问题,并且您不应该需要打开另一个单独的工具来获取该详细信息。
Telegraf 1.7 中引入 Syslog 解析
为了帮助我们的客户和社区成员应对此类挑战,我们发布了 Telegraf 1.7。特别是在 Telegraf 1.7 版本中,我们添加了一个 高性能 syslog 插件,允许使用 Telegraf 支持的任何输出源进行日志收集和存储。对于已经使用 syslog 作为收集日志手段的用户,我们鼓励您尝试一下。
现在,日志文件包含事件集合,这些事件通常带有时间戳——猜猜看,哪种技术非常适合收集、分析和处理时间序列数据?
如果您说是 InfluxDB…恭喜您!但是,根据调查结果,我们的许多社区成员和客户尚未将 InfluxDB 用作累积其日志事件的地方。Telegraf logparser 插件自 1.0 版本以来就已存在,它支持解析 grok 风格的日志模式的能力。这可能是解决分布式日志文件并使用 InfluxDB 收集它们的有效方法,但是许多人都在使用 syslog 协议收集日志,因此添加此附加机制以利用该协议并简化通过 Telegraf 收集日志数据是有意义的。此外,我们努力使它变得非常快速和高效。
在 Chronograf 中查看日志
我们的脚步并未止步于此!随着 Chronograf 1.5 的推出,我们交付了以表格格式可视化非指标数据的能力。对于那些使用 Telegraf、InfluxDB 和 Chronograf 组合的用户,这意味着在仪表板中快速可视化日志数据应该很容易。使用 Chronograf 中可用的指标、元数据和时间范围来精确定位您想要查看的日志数据量——基于与常态的特定偏差。如果您想查看与显示的特定仪表板时间相关的某些日志事件,您可以修改提取日志数据的查询,以包含来自您的指标的共享元数据以及仪表板时间,并自动将日志过滤到相关集合。无需猜测搜索条件!但是,对于那些仍然希望更详细地探索其日志的用户,即将发布的 Chronograf 版本包含日志可视化组件。您现在就可以开始探索它——通过 下载页面 上提供的 Chronograf 每夜构建版本。
对于那些需要帮助找到它的用户,请在左侧导航面板中查找“日志”图标。它实际上很难错过!
我们未来的方向
日志查看器当前绑定到由新的 Telegraf syslog 插件创建的 syslog 度量。但是,随着我们继续开发日志查看器,我们计划添加其他配置选项,包括更改各种列的位置、顺序和可见性的能力——就像表格控件一样。我们还计划提供添加其他标签可视化的能力,如果您扩展了 Telegraf 插件以提供额外的上下文数据,以帮助您分析日志事件本身中捕获的事件。我们还希望使在仪表板和日志查看器之间跳转变得容易,并可能为仪表板制作可嵌入的日志查看器图表类型——从而节省更多时间和精力。
在您开始探索 Telegraf 和 Chronograf 中的所有新功能之前,重要的是指出一些我们不打算解决的反模式和问题。首先,InfluxDB 并不打算成为日志存档。如果您需要更长期地存储日志以用于合规性或存档目的,那么在 50 多个日志管理工具中,有更具成本效益的解决方案。最好将日志数据的保留策略与您计划执行实时操作分类和向下钻取的主要窗口对齐。当然,您可以从日志数据本身提取和导出指标(按各种元数据标签计数:主机、严重性等)——并在有效向下采样该信息的同时消除消息本身。这将为“指标优先”方法创建历史基线,并允许在计数开始超过这些历史常态时发出早期警告。
如果您正在寻找更高级的分析用例——考虑 SIEM 风格的活动,例如用户和实体行为分析或基于事件数据的安全编排和自动化响应——这不是我们计划从“开箱即用”用户界面角度解决的问题。通常,这些用例需要更长时间的日志存档以及在整个数据集上运行的更复杂的机器学习算法。
随着我们继续简化和方便整体体验,可能会添加其他分析功能。例如,如果您的日志事件包含关联 ID,我们可以计算事件之间的时间并将它们绘制在直方图上。这里还有很多工作要做,但我们才刚刚开始推动您采用“指标优先”的方法来查看、探索和分析支持日志事件的能力。我们正在努力提高您的系统、应用程序和传感器的整体可观察性,同时加快问题解决速度。请在 社区网站 上告诉我们您的想法。