使用Promethues实现应用监控的一些实践本文介绍如何使用Prometheus对应用进行监控。在后续工作中，随着监控的深入，我们结合自己的经验和官方文档总结了一些Metrics的做法。希望这些做法可以给大家提供一个参考。确定监控对象在设计Metrics之前，首先需要定义需要监控的对象。需要测量的对象要根据具体的问题背景、需求和被监控的系统本身来确定。从需求出发，Google根据大量分布式监控的经验，总结出四大监控黄金指标。这四项指标对一般的监测和测量对象具有很好的参考意义。这四个指标是：延迟：服务请求的时间。流量：监控当前系统流量，衡量服务的容量需求。Errors：监控当前系统发生的所有错误请求，衡量当前系统发生错误的速率。饱和度：衡量当前服务的饱和度。主要强调最能影响服务状态的受限资源。例如，如果系统主要受内存影响，则主要关注系统的内存状态。以上四个指标实际上是为了满足四个监控需求：反映用户体验和衡量系统的核心性能。如：在线系统的延迟，作业计算系统的作业完成时间等。反映了系统的吞吐量。如：请求数量、发送和接收的网络数据包大小等。有助于发现和定位故障和问题。如：错误计数、调用失败率等。反映系统的饱和度和负载。如：系统占用的内存，作业队列的长度等。除了上述常规要求外，根据具体的问题场景，为了排除和发现之前已经出现或可能出现的问题，相应的可以确定测量对象。例如，系统需要经常调用的库的接口可能会耗时较长或偶尔会失败。可以制定指标来衡量该接口的延迟和故障次数。从需要监控的系统出发，为了满足相应的需求，不同的系统需要观测的测量对象也不同。在官方文档的最佳实践中，将需要监控的应用分为三类：在线服务系统（Online-servingsystems）：需要对请求做出即时响应，请求发起者会等待响应。比如网络服务器。离线处理：请求的发起者不等待响应，请求的工作通常需要很长时间。比如批处理计算框架Spark等。批处理作业：这种类型的应用程序通常是一次性的，不会一直运行，操作完成就结束。例如用于数据分析的MapReduce作业。对于每一种应用，通常测量的对象是不一样的。其总结如下：在线服务系统：主要包括请求数、错误数、请求延迟。离线计算系统：最后一次处理作业的时间、当前正在处理的作业数、已发送的项目数、作业队列的长度等批处理作业：最后一次成功执行的时刻、执行时间每个主要阶段的时间、总耗时、处理的记录数等。除了系统本身，有时还需要监控子系统：使用的库（Libraries）：调用次数、成功次数、错误次数,和呼叫延迟。Logging：统计每条日志的写入次数，这样就可以找到每条日志的频率和时间。失败：错误计数。线程池：排队的请求数、正在使用的线程数、线程总数、耗时、正在处理的任务数等缓存：请求数、命中数、总延迟等选择原则Vector与选择Vec：数据类型相似，但资源类型、采集位置等不同。Vec中的数据单元是统一的。示例：不同资源对象的请求延迟和不同区域服务器的请求延迟是不同的。http请求错误的计数...另外官方文档中建议，对于一个资源对象的不同操作，比如Read/Write，Send/Receive，应该使用不同的Metrics来记录，而不是放在一个指标。原因是两者在监测时一般不会合计，而是分开观察。但是，对于请求度量，通常使用Label来区分不同的动作。确定Label常用的Label选项有：resourceregiontype...确定Label的一个重要原则是同一维度的Label的数据可以取平均求和，即单位要统一。比如风扇的风速和电压不能放在一个Label中。另外，不推荐以下做法：my_metric{label=a}1my_metric{label=b}6my_metric{label=total}7即在Label中同时统计score和total数据。推荐使用PromQL在服务器端聚合sum的结果。或者使用另一个Metric来衡量总数据。NamingMetricsandLabel好的命名从名字就可以看出来，所以命名也是好的设计的一部分。Metric的命名：prometheus_notifications_totalprocess_cpu_seconds_totalipamd_request_latency需要符合pattern：a-zA-Z：应该包含一个单词作为前缀，表示Metric所属的域。例如：它应该包含一个单位作为后缀，表示这个度量的单位。例如：http_request_duration_secondsnode_memory_usage_byteshttp_requests_total（无单位累加计数）在逻辑上与测量变量具有相同的含义。尽量使用基本单位，如秒、字节。而不是毫秒，兆字节。标签命名：根据选择的维度命名，如：地区：深圳/广州/北京所有者：user1/user2/user3stage：extract/transform/loadBuckets选择合适的buckets可以使直方图的百分位计算更加准确。理想情况下，buckets会让数据呈阶梯状分布，即每个bucket区间的数据数量大致相同。桶的设计可以遵循以下经验：你需要知道数据的大概分布。如果您事先不知道，可以使用默认的桶({.005,.01,.025,.05,.1,.25,.5,1,2.5,5,10})或2多个桶（{1,2,4,8...}）观察数据分布，然后调整桶。数据分布越密集的地方，桶间隔可以设置的越窄，数据分布稀疏的地方，可以设置的宽一些。对于大多数时延数据，一般都具有长尾的特点，更适合使用指数桶（ExponentialBuckets）。桶的初始上限一般覆盖大约10%的数据。如果不注意头部数据，可以把初始上界调大一些。如果想更准确的计算一个具体的百分位数，比如90%，可以在90%的数据处对分发桶进行加密，也就是减小桶间隔。比如我在监控我们的一些任务的耗时时，我会选择根据实际情况预估大概的bucket值，然后在上线后观察数据和监控后调整bucket。这样，经过几次调整桶，应该调整到一个比较合适的值。Grafana使用技巧来查看所有维度。如果想知道是否可以按其他维度分组，快速查看还有哪些维度可用，可以使用如下技巧：只保留查询表达式中的索引名，不做任何计算，Legend格式也留空。这将显示原始指标数据。如下图，刻度联动在Settings面板中，有GraphTooltip设置项，默认为Default。接下来将图形显示工具调整为Sharedcrosshair和SharedTooltip，看看效果。可以看到刻度可以联动显示，方便排错时确认两个指标的相关性。将图形显示工具调整为SharedTooltip：
