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