开发者关于不丢失所需指标的指南
作者：Gianluca Arbezzano254 / 产品, 开发者
2018 年 12 月 04 日
导航至
收集和存储指标是开发者在生产周期中必须执行的众多并行任务之一。由于您永远不知道何时可能发生不利事件，因此您可以随时拥有所需的指标来调试问题。
但是，您不能永远存储所有指标。这甚至适用于专门构建的时间序列数据库，例如 InfluxDB 提供的数据库，它旨在用于高基数数据。时间序列数据库在可扩展性方面可能看起来“神奇”，但它们不具备无限扩展的能力，在某个时候，即使是 InfluxDB 的工具也会达到极限。
时间序列数据库的局限性是您应该将存储管理为一组不同尺寸的管道的原因。当您不知道指标或跟踪是否有用，或者由于收集了太多指标而导致存储成本过高时，您可以始终将它们存储一小段时间。如果它们变得有用，或者在聚合它们以减少系统压力后，您也可以稍后移动它们。
如果您正在使用 InfluxDB，您可以为所有指标设置最小的保留策略（例如，仅两到三天）。然后，您可以将指标移动到另一个 InfluxDB 实例（具有更长的保留策略）Kapacitor，即 TICK Stack 的原生数据处理引擎。
这是一个难题，但我对将日志、跟踪和指标放在同一个地方感到不舒服。最终结果是轻松聚合来自系统所有不同视点的数据。因为归根结底，指标和日志只是系统现实的不同表示形式——将它们放在一起将像一个强大的水晶球一样，能够以更高的粒度回答关于系统状态的问题。
如上所述，存储大量数据的独特方法是通过保留策略和数据聚合。一种解决方案是 Kapacitor，它可以处理来自 InfluxDB 的流数据和批处理数据——它允许您插入自己的自定义逻辑或用户定义的函数，以处理具有动态阈值的警报、匹配指标以查找模式并计算统计异常。它还基于这些警报执行特定操作，例如动态负载重新平衡。
将 Kapacitor 与 InfluxDB 结合使用非常简单，并且允许您按原样存储数据或将其作为聚合发送。无论哪种情况，这都是您开始查看指标数据以确定需要保留哪些内容的直接方法——所有这些都无需猜测。
此外，在收集系统和应用程序数据时，今天的开发者还会谈论日志、事件和跟踪。
访问指标就像能够睡个好觉——而事件就像一记耳光。您首先以漂亮图表的形式设计指标，以了解系统的正常运行。当某些东西偏离正常运行时，您会受到一记耳光，在事件发生时将您唤醒。
在夜间每一次意外的耳光之后，随之而来的是困惑。您环顾四周以获取关于正在发生的事情、谁打断了您的美梦以及原因的信息，但指标和事件并不能说明全部情况。这就是仅靠监控不足的地方。
此时，重要的是提醒自己，监控可以帮助您知道何时出现问题，但不能回答以下问题
- 发生了什么事？
- 我该如何修复它，以便我可以再次入睡？
在这个关头，如果问题出在您的应用程序中，您将开始研究日志以查看发生了什么。如果您处于小型低流量环境中，您可能会找到您正在寻找的东西，然后就完成了。
但是，如果您的系统很复杂，它可能是分布式的或严重依赖第三方服务，在这些服务中日志量很大，并且您无法通过简单地观看它们来识别哪里坏了——在这种情况下，您需要缩小中断范围。为此，您可以查看您的跟踪。虽然识别跟踪可能具有挑战性，但您可以采取两个操作
- 首先，在您的日志中公开
trace_id（每个跟踪/请求的标识符）以连接它们。它将帮助您过滤特定请求的日志。 - 其次，教导您的支持团队和客户
trace_id的重要性。他们应该知道这是找出正在发生的事情的关键。如果您的客户是技术人员，那么当您为他们提供例如 HTTP HEADER 时，这会更容易。如果您的客户是非技术人员，那么让您的 UI 发回适当的标识符是一个好策略。
我遇到的实际问题促使我写了这篇博客。我写的一切都是从分布式应用程序故障排除中学到的教训：即指标、事件、日志和跟踪并非相互排斥。它们是使调试、监控和可观测性成为可能的工具。我迫不及待地想要拥有一个单一的解决方案来将它们全部组合在一起，以便让我的开发者生活比现在更棒。
