监控系统的分类

大多数监控系统都是基于一件事：事件。事件几乎可以是任何事，包括：

接收一个HTTP请求

回复一个状态码为400的HTTP请求

进入一个函数

跳转到 if 语句中的 else部分

离开一个函数

用户登录

写数据到磁盘上

从网络中读数据

从内核中请求更多的内存

所有的事件都有上下文。一个HTTP请求包含它的源IP地址，目标IP地址，被请求的URL路径，被设置的cookies，以及发起请求的用户。一个HTTP请求响应会有，响应花费的时间，HTTP状态码和响应body的长度。涉及函数的事件具有函数的调用堆栈，以及触发调用栈的部分- 例如HTTP请求。

拥有所有事件的上下文对于调试和理解你的系统在技术和业务层面是如何运作的是很有帮助的，但是处理和存储如此大的数据量并不实际。因此，我认为大致有4种方法可以将这些数据的体积减少到可行的程度：profiling，tracing，logging和metrics。

Profiling

Profiling的方法是你不能拥有所有时间段的所有事件的所有上下文，但是你可以记录有限时间的一些上下文。

Tcpdump是profiling工具中的一个例子。它根据特定的过滤规则允许你去记录网络流量。它是一个很重要的debug工具，但是你不能一直开启它，因为这样会用完磁盘空间。

二进制文件的调试版本是另一个例子。它提供了大量有用的信息，但是收集所有的信息（例如每个函数调用的时间）会影响性能，所有那意味着在生产环境中持续运行它是不实际。

在Linux内核中，增强型伯克利数据包过滤器（eBPF）允许对内核事件（从文件系统的操作到网络怪异事件）的详细分析。这些提供了以前通常无法达到的深度视角，我建议阅读Brendan Gregg关于该主题的文章 Brendan Gregg’s writings。

Profiling主要用于调试。如果长期使用它，则必须减少它的数据量以适应其他类别的监控。

Tracing

Tracing不是看所有的事件，而是采集一定比例的事件例如一些感兴趣的函数的百分之一的事件。Tracing会在感兴趣功能的追踪中记下函数，通常也会记下这些函数话费了多少时间。从这些你可以知道你的程序在哪里花的时间比较多，哪些代码路径延迟最多。

有的追踪系统不是在感兴趣的功能上记录下堆栈的快照。而是会跟踪和记录感兴趣的功能的底层的每个函数调用花费的时间。例如，可以抽取百分之一的用户HTTP请求，对于这些请求，您可以看到与后端系统（例如数据库和缓存）进行对话所花费的时间。这可以了解到一些因素例如缓存命中与缓存未命中对时间花费的影响。

分布式追踪系统更进一步。它通过给远程过程调用（RPC）中需要追踪的请求附加一个唯一ID使追踪工作可以跨进程。不同进程和机器间的追踪可以通过请求ID连接在一起。这在分布式微服务架构的调试中是一个至关重要的工具。这个领域的技术又OpenZipkin和Jaeger。

对于追踪来说，是抽样的方法保证了数据量和设备性能保持在一个合理的范围之内。

Logging

日志是查看一组有限的事件，并且记录下每一个时间的一些上下文。例如它可能会查看所有进入的HTTP请求或者所有传出的数据库调用。为了避免消耗太多资源，经验上来说，每条日志限制在大约100条记录。超越那个限制的话，带宽和存储空间会成为一个问题。

例如，对于每秒处理一千个请求的服务，一条日志带有一百个字段（每个字段需要十个字节），那么每秒钟需要1M。那么仅仅是记录日志，就需要每天100Mbit网卡，84GB的存储空间。

日志记录的一大优点是（通常）不会对事件进行采样，因此即使字段数量有限制，跟踪影响到特定用户和与其通信的特定API后端的慢请求也是可行的。

正如监控对不同的人意味着不同的事情一样，日志也意味着不同的事情。当你与脑海中有另一种日志类型的人交谈时，会引起混淆。不同类型的日志具有不同的用途，可靠性和保留要求。我将日志划分成四种通用但是某种程度又重叠的类别：

事务日志

这些是你的关键业务记录，您必须不惜一切代价始终保持它的安全。任何涉及金钱或用于关键用户的东西往往都属于这一类。

请求日志

如果您正在跟踪每个HTTP请求或每次数据库调用，那就是一个请求日志。可能会对它们进行处理以实现面向用户的功能，或者仅仅用于内部优化。你通常不想失去它们，但是即使有一些丢失了，也不会是世界末日。

应用程序日志

并不是所有的日志都是关于请求的，有些是关于进程本身的。启动信息，后台守护任务和其他进程级别的日志是典型的应用程序日志。这些日志通常由人类直接读取，因此您应该尽量避免在正常操作中每分钟more than a few

调试日志

调试日志通常非常详细，因此创建和存储代价很高。它们通常只用于非常狭窄的调试情况，并趋向于Profling。可靠性和保留要求往往很低，这些信息可能甚至不会离开产生它们的机器。

用同样的方法处理不同类型的日志可能会导致导致糟糕的情况发生。例如将数据量很大的调试日志和对可靠性有极端要求的事务日志相结合。因此，随着系统的增长，您应该计划将它们分开，以便可以分开处理它们。

ELK技术栈和Graylog是日志系统的代表。

Metrics

度量标准很大程度上忽略了上下文，而是跟踪不同类型事件随时间的聚合。为了保持资源使用的正常，被跟踪的不同数字的数量需要受到限制，每个进程有一万个是您需要牢记的合理上限。

您可能拥有的指标类型的示例包括您收到HTTP请求的次数，处理请求的时间以及当前正在处理的请求数。通过排除关于上下文的任何信息，所需的数据量和处理保持合理。

这并不是说虽然这种情况总是被忽略。对于HTTP请求，您可以决定为每个URL路径制定一个度量标准。必须记住万条指标，因为每条不同的路径现在都被视为一个指标。使用诸如用户的电子邮件地址之类的上下文将是不明智的，因为它们具有无限的基数

您可以使用度量来跟踪由应用程序中每个子系统处理的延迟和数据量，从而更容易确定究竟是什么导致了减速。日志无法记录如此多的字段，但是一旦您知道哪个子系统应该归咎于日志，可以帮助您找出涉及哪些确切的用户请求。

这是日志和度量之间的权衡最明显的地方。度量标准允许您从整个流程中收集有关事件的信息，但通常不超过一个或两个有界基数的上下文域。日志允许您收集有关所有类型事件的信息，但只能跟踪无限基数的上百个字段。这种基数的概念及其对指标的限制很重要，我将在后面的章节中回过头来看。

作为基于指标的监控系统，Prometheus设计用于跟踪整体系统健康状况，行为和性能，而不是单个事件。换句话说，Prometheus关心在最后一分钟有十五个请求需要四秒钟处理，导致四十个数据库调用，十七个缓存命中和两个客户购买。个别调用的成本和代码路径将是分析或日志记录的关注点。

翻译自 Prometheus:Up&Running                                                                                                       https://www.safaribooksonline.com/library/view/prometheus-up/9781492034131