Categories of Monitoring

每天结束时，大多数监控都是关于同样的事情：事件。 事件可以 几乎任何东西，包括:

• 收到一个http请求

• 发送一个http 400回应

• 进入一个函数

• 到达if语句的else

• 离开函数

• 一个用户登入

• 向硬盘写入数据

• 从网卡获取数据

• 向内核请求更多的内存

所有事件也都有属性。 HTTP请求将具有来源IP地址目的地址，请求的URL，设置的cookie以及发起请求的人，HTTP响应将包含响应所花费的时间以及HTTP具体的状态代码和响应报文的长度。 涉及函数的事件拥有它们上面的函数的调用堆栈，以及触发这部分的任何东西堆栈，例如HTTP请求。 了解所有事件的所有上下文对于调试和理解系统在技术和业务方面的执行情况是非常有用的，但是这些数据对于处理和存储来说是不切实际的。 因此，我将看到大致有四种方法可以将数据量减少到可行的方式，即分析，跟踪，日志记录和指标。

Profiling

分析采用的方法是，当您不能拥有所有事件的所有上下文时，你可以在有限的时间内获取一些背景。 Tcpdump是分析工具的一个示例。 它允许您基于指定的过滤器来捕获网络流量。 它是一个必不可少的调试工具，但你无法真正在某些场景使用它，例如你磁盘空间已耗尽。 调试运行的程序是另一个示例。 能给我们提供大量有用的信息，但收集所有信息的性能影响，例如每个函数调用的时序，意味着将在生产中持续运行它，所以通常是不切实际的。 在Linux内核中，增强的Berkeley数据包过滤器（eBPF）允许从文件系统操作到网络奇怪的内核事件的详细分析。 这些提供了以前通常无法获得的洞察力水平，我建议阅读Brendan Gregg关于这一主题的着作。 分析主要用于调试。 如果长期使用，则必须减少数据量，以适应其他类别的监控。

Tracing

trace不会查看所有事件，而是查看仅需要trace的一些事件，例如百分之一的事件通过一些感兴趣的功能。 跟踪会注意到 函数在感兴趣的点的堆栈trace中，通常也是这些函数执行的时间。 通过这种方式，您可以了解程序花费时间的位置以及哪些代码路径最有助于延迟。 一些trace系统不是在感兴趣的点处执行堆栈跟踪的快照，而是跟踪并记录在感兴趣的功能之下的每个函数调用的定时。 例如，可能会对一百个用户HTTP请求中的一个进行采样，对于这些请求，您可以看到与后端（如数据库和缓存）进行通信所花费的时间。 这使您可以根据缓存命中与缓存未命中等因素来了解时序的差异。 分布式trace更进一步。 它通过将唯一ID附加到远程过程调用（RPC）中从一个进程传递到另一个进程的请求，以及此请求是否应该被trace的请求，使跟trace进程工作。 来自不同进程和机器的trace可以根据请求ID重新拼接在一起。 这是调试分布式微型计算机的重要工具 服务架构。 这个领域的技术包括OpenZipkin和Jaeger。 对于trace，采样可以使数据量和工具性能影响保持在合理范围内

Logging

日志记录能查看一组有限的事件，并记录每个事件的一些上下文。 例如，它可能会查看所有传入的HTTP请求或所有传出的数据库调用。 为了避免消耗太多资源，根据经验，每个日志条目限制在大约一百个字段。 除此之外，带宽和存储空间往往成为一个问题。 例如，对于每秒处理一千个请求的服务器，具有一百个字段的日志条目（每个字节占用十个字节）计算为每秒兆字节。 这是100 Mbit网卡中非常重要的比例，每天只有84 GB的存储空间用于记录。 日志记录的一大好处是（通常）没有事件采样，因此即使字段数量有限制，确定慢速请求如何影响与一个特定API端点通信的特定用户也是切实可行的。 就像监控对不同的人意味着不同的东西一样，Logging也意味着不同的东西取决于你问的人，这可能会引起混乱。 不同类型的日志记录具有不同的用途，持久性和保留要求。 在我看来，有四个一般和有些重叠的类别：

• 交易日志: 这些是关键业务记录，您必须不惜一切代价保持安全，可能永远。 任何涉及金钱或用于关键面向用户的功能的东西都属于这一类。

• 请求日志: 如果您正在跟踪每个HTTP请求或每个数据库调用，那么这是一个请求日志。 可以对它们进行处理，以实现面向用户的功能，或仅用于内部优化。 你通常不想失去它们，但如果其中一些失踪，它不是世界末日。

• 应用日志: 并非所有日志都与请求有关; 一些是关于过程本身。 启动消息，后台维护任务和其他进程级日志行是典型的。 这些日志通常由人直接读取，因此您应该尽量避免在正常操作中每分钟超过几分钟。

• 调试日志: 调试日志往往非常详细，因此存储起来非常耗存储。 它们通常仅用于非常狭窄的调试情况，并且由于其数据量而倾向于分析。 可靠性和保留要求往往较低，调试日志甚至可能无法生成它们生成的机器。

以相同的方式处理不同类型的日志可能会在最糟糕的世界中结束，在这些世界中，您拥有调试日志的数据量以及事务日志的极高可靠性要求。 因此，随着系统的增长，您应该计划拆分调试日志，以便可以单独处理它们

Metrics

度量标准在很大程度上忽略了上下文，而是跟踪不同类型事件随时间的聚合。 为了保持资源使用的合理性，需要限制跟踪的不同数量的数量：个您要记住的合理上限是每个进程一万。 您可能具有的度量标准的示例包括您收到HTTP请求的次数，处理请求所花费的时间以及当前正在进行的请求数。 通过排除有关上下文的任何信息，所需的数据量和处理保持合理。 但这并不是说，上下文总是被忽略。 对于HTTP请求，您可以决定为每个URL路径设置一个度量标准。 但是必须牢记万条指标，因为每条不同的路径现在都算作一个指标。 使用诸如用户的电子邮件地址之类的上下文是不明智的，因为它们具有无界的基数。 您可以使用指标来跟踪应用程序中每个子系统处理的延迟和数据量，从而更容易确定导致速度减慢的确切原因。 日志无法记录那么多字段，但是一旦你知道应该责怪哪个子系统，日志可以帮助你找出涉及哪些确切的用户请求。 这是日志和指标之间的权衡变得最明显的地方。 度量标准允许您收集有关整个过程中事件的信息，但通常不超过一个或两个带有有界基数的上下文字段。 日志允许您收集有关所有类型事件的信息，但只能跟踪具有无界基数的上百个上下文字段。 这种基数的概念及其对指标的限制对于理解很重要，我将在后面的章节中再回过头来看。 作为基于指标的监控系统，Prometheus旨在跟踪整体系统运行状况，行为和性能，而不是单个事件。 换句话说，普罗米修斯关心最后一分钟有15个请求需要4秒钟处理，导致40个数据库调用，17个缓存命中和2个客户购买。 各个调用的成本和代码路径将是分析或记录的关注点。 现在您已经了解了普罗米修斯在整个监控空间中的位置，让我们来看看普罗米修斯的各个组件。