指标的原理是什么？

分类：编程技术时间：2024-02-20 15:49 浏览：0 评论：0

本文主要讲解“Metrics的原理是什么”，感兴趣的朋友不妨看一下。文章介绍的方法简单、快捷、实用。现在就让小编教你“Metrics的原理是什么”！

什么是Metrics？

Flink 提供的 Metrics 可以收集 Flink 内部的一些指标，让开发者可以通过这些指标更好地了解作业或者集群的状态。由于集群运行后很难得知集群内部的实际状态，是运行慢还是快，是否异常等，开发者无法实时查看所有Task日志。例如，如果工作量很大或者工作量很多，应该如何处理？这时候Metrics就可以帮助开发者了解当前作业的状态。

Metric Types

Metrics的类型如下：

首先，常见的是用过的，例如Counter，写做过mapreduce工作的开发者应该对Counter非常熟悉。其实意思是一样的，都是累加计数器，也就是将多条数据、多兆数据进行累加的过程。

第二，Gauge，Gauge是最简单的Metrics，它体现了一个值。例如，如果想查看当前使用了多少Java堆内存，可以每次实时暴露一个Gauge。 Gauge的当前值是堆使用量。

第三、Meter，Meter是指统计吞吐量以及单位时间内发生的“事件”的数量。它相当于求一个比率，即事件数量除以所用时间。

四、直方图，直方图比较复杂，不常用。直方图用于统计一些数据的分布情况，如Quantile、Mean、StdDev、Max、Min等。

Metric Group

Metric在Flink内部有多层结构，o以集团方式组织。它不是扁平化的结构，Metric Group + Metric Name 是 Metrics 的唯一标识。

Metric Group的级别包括TaskManagerMetricGroup和TaskManagerJobMetricGroup。每个Job都具体到某个任务组，任务分为TaskIOMetricGroup和OperatorMetricGroup。 Operator下面还有IO统计和一些Metrics。整个层次结构大致如下图所示。指标不会影响系统。它们在不同的组中，Flink 支持自己添加组，并且可以有自己的级别。

•TaskManagerMetricGroup        •TaskManagerJobMetricGroup              •TaskMetricGroup           •TaskIOMetricGroup                                                                                                                                                                           ·任务管理器                   。 {用户定义的指标} •OperatorIOMetricGroup •JobManagerMetricGroup •JobManagerJobMetricGroup

JobManagerMetricGroup 比较简单。相当于Master，等级相对较少。

Metrics的定义比较简单，就是可以自己收集统计指标信息。 Metrics信息可以在外部系统中看到，并且可以被聚合和计算。

如何使用指标？

系统指标

< /h3>

System Metrics，整个集群的状态，direct的使用情况，以及mapped的使用情况； Threads可以看到有多少个线程；还有非常实用的Garbage Collection。

网络在需要解决一些性能问题时被广泛使用网络非常实用。 Flink不仅仅是网络传输，更是有向无环图结构。可以看到它的上游和下游都是一个简单的生产者-消费者模型。 Flink相当于通过网络的标准A limit-length队列模型在生产者和消费者之间传递。如果要评估定位性能，中间队列会快速缩小问题范围，快速找到问题瓶颈。

•CPU•内存•线程•垃圾收集•网络•类加载器•集群•可用性•检查点•StateBackend•IO•详细信息请参见：[https://ci.apache.org/projects/flink/flink-docs-release-1.8/monitoring/metrics.html #system-metrics](https:// ci.apache.org/projects/flink/flink-docs-release-1.8/monitoring/metrics.html)

运维集群的人会更关心集群的相关信息，如果工作是太大，需要密切关注Checkpointing，这可能无法反映一些常规指标的潜在问题。例如，如果 Checkpointing 长时间不起作用并且数据流看起来没有延迟，则可能会发生这种情况。工作中一切正常的错觉。另外，如果经过一轮故障转移重启，因为Checkpointing已经很久没有工作了，可能会回滚到很长一段时间。如果之前的状态被改变，整个操作可能会彻底报废。

RocksDB是生产环境中常用的状态后端实现。如果数据量足够大，则需要更加关注RocksDB的Metrics，因为它的性能可能会随着数据量的增加而下降。

用户自定义 Metrics

除了系统 Metrics 之外，Flink 还支持自定义 Metrics，即 User-defined Metrics 。以上都是系统框架的内容。你也可以使用Metrics来暴露一些指标，供你自己的业务逻辑进行监控。

现在提到的User-defined Metrics都是datastream的API。表和SQL可能需要上下文帮助，但如果你编写UDF，它们实际上是相似的。

Datastream的API继承了RichFunction。只能通过继承通过 RichFunction 可以获得 Metrics 接口。那么RichFunction会带来一个getRuntimeContext().getMetricGroup().addGroup(…)方法，这个方法就是User-defined Metrics的入口。通过这种方式，可以自定义用户定义的Metric Group。如果要定义具体的Metrics，还需要使用getRuntimeContext().getMetricGroup().counter/gauge/meter/histogram(…)方法，该方法会有相应的构造函数，可以在自己的Metrics类型中定义。

继承RichFunction •注册用户自定义Metric Group：getRuntimeContext().getMetricGroup().addGroup(…) •注册用户自定义Metric：getRuntimeContext().getMetricGroup().counter/gauge/meter/ histogram(…)

用户定义的 Metrics 示例

下面一段简单的示例说明了如何使用 Metrics。例如，如果定义了一个 Counter 并传递了一个名称，则 Counter 的默认类型是 single counter（Flink 的内置实现）。你可以执行m对Counter进行inc()操作，直接在代码中获取。

Meter 也是如此。 Flink 有一个名为 Meterview 的内置实现。因为Meter是记录事件发生了多久，所以需要一个长窗口。一般使用Meter时，直接markEvent()，相当于添加一个事件，并不断计数。最后使用getrate()方法直接划分这段时间发生的事件并计算。

仪表比较简单。只需输入当前时间并使用 Lambda 表达式直接输入 System::currentTimeMillis 即可。这相当于每次调用时都实际调整当天的系统时间。计算。

直方图有点复杂。 Flink中的代码提供了两种实现方式。在此处选择一种实现。它仍然需要一个窗口大小，您可以在更新时给它一个值。

这些指标通常不是线程安全的。如果你想使用多线程，需要添加同步。欲了解更多详情，请参阅以下链接。

•计数器processedCount = getRuntimeContext().getMetricGroup().counter("processed_count"); processedCount.inc();•Meter processRate = getRuntimeContext().getMetricGroup().meter("rate", new MeterView(60)); processRate.markEvent();•getRuntimeContext().getMetricGroup().gauge("current_timestamp", System::currentTimeMillis);•直方图直方图 = getRuntimeContext().getMetricGroup().histogram("直方图", new DescriptiveStatisticsHistogram(1000) ）； histogram.update(1024);•[ https://ci.apache.org/projects/flink/flink-docs-release-1.8/monitoring/metrics.html#metric-types]

获取Metrics

获取Metrics的方式有3种。首先，你可以在WebUI上看到它；其次，可以通过RESTful API获取。 RESTful API对程序更加友好，比如编写自动化脚本或程序，自动化运维安斯。经测试，通过RESTful API解析返回的Json格式对程序更加友好；最后还可以通过Metric Reporter获取，监控主要使用Metric Reporter功能。

获取Metrics的方法在物理架构中是如何实现的？

了解背景和原理会让你对使用有更深入的了解。 WebUI和RESTful API是通过定期查询中心化节点来拉取各个组件中的Metrics来实现的。其中，fetch不一定是实时更新的，默认是10秒，所以WebUI和RESTful API中刷新的数据可能不是你想要实时获取的数据；另外，fetch可能会不同步，比如两个组件，一侧在加，另一侧则不动。可能由于某种原因超时了。这样就无法更新相关的值了。这是一个尽力而为的操作，所以有时指标我们看到可能会延迟。也许等待之后相关值就会改变。更新。

红色路径经过MetricFetcher，会有一个中心化的节点来聚合它们并显示它们。 MetricReporter 是不同的。每个单独的点都会直接报告。它没有中心化的节点来帮助聚合。如果要聚合，需要在第三方系统中进行，比如常见的TSDB系统。当然，它的优点是它不是中心化的结构。可以避免中心化节点带来的内存不足等问题。 MetricReporter直接将原始数据输出给Reporter，利用原始数据进行处理将会有更强大的功能。

Metric Reporter

Flink 有许多内置的 Reporter。可以参考外部系统的技术选型。比如JMX是java自带的技术，严格来说不属于第三种派对。还有InfluxDB、Prometheus、Slf4j（直接登录日志）等，在调试时非常有用。可以直接查看记录器。 Flink 本身有自己的日志系统，会记录到 Flink 框架包中。详情请参见：

•Flink内置了很多Reporter。可以参考外部系统的技术选型。有关详细信息，请参阅：[https://ci.apache.org/projects/flink/flink-docs-release -1.8/monitoring/metrics.html#reporter](https://ci.apache.org/projects/flink /flink-docs-release-1.8/monitoring/metrics.html)•指标报告器配置示例metrics.reporters：your_monitor，jmxmetrics.reporter.jmx.class：org.apache.flink.metrics.jmx.JMXReportermetrics.reporter。 jmx.port：1025-10000 指标.reporter.your_monitor.class：com.your_company.YourMonitorClass 指标.reporter.your_monitor .interval：10 秒 指标.reporter.your_monitor.config.a：your_a_value 指标.reporter.your_monitor.config.b : your_b_value

如何是否配置了 Metric Reporter？如上所示，首先Metrics Reporters的名称用逗号分隔，然后通过metrics.reporter.jmx.class的类名反射找到reporter。还需要获取metrics.reporter.jmx.port的配置，比如第三方系统通过网络发送。还有更多。但要知道发送到哪里，IP地址和端口信息是比较常见的。另外，metrics.reporter.your_monitor.class是必须的。你可以自己定义间隔，Flink可以解析它，你不需要自己读取它，你也可以编写自己的配置。

实用：通过Metrics进行监控

Metrics常用于自动化运维、性能分析。

自动化运维

自动化运维怎么做？

首先，收集一些关键指标作为决策的基础。使用Metric Reporter 将 Metrics 收集到存储/分析系统（例如 TSDB），或者直接通过 RESTful API 获取。

有了数据后，可以自定义监控规则，重点关注关键指标、Failover、Checkpoint、业务Delay信息。使用最广泛的自定义规则是可以用来报警，节省大量的手动工作，并且可以自定义多少次故障转移需要人工干预。

出现问题时，有钉钉报警、邮件报警、短信报警、电话报警等通知工具。

自动化运维的好处是可以通过仪表盘和报表的形式清晰地查看数据，通过仪表盘随时了解作业的整体信息，并通过报表分析进行优化。

性能分析

性能分析一般遵循以下流程：

从发现问题开始首先，如果 y有了Metrics系统，再加上监控和报警，可以快速定位问题。然后分析问题，宏观地看问题，会方便一些。通过具体的系统指标分析，我们可以缩小范围，验证假设，找到瓶颈，然后分析原因。从业务逻辑、JVM、操作系统、State、数据分布等多个维度进行分析；如果找不到问题的原因，就只能使用profiling工具了。

实战：“我的任务很慢，我该怎么办？”

“我的任务很慢，怎么办？”我应该做什么？堪称终极无解问题之一。

原因是这个问题是系统框架问题。例如，当你去看医生时，你告诉医生你感觉不舒服，然后让医生得出结论。通常医生需要通过一系列的操作来缩小范围并确定问题的考试。同样，任务慢的问题也需要多轮分析才能得到明确的答案。

除了对Flink机制不熟悉之外，大多数人的问题是整个系统像一个黑匣子一样运行，他们不知道系统是如何运行的。他们缺乏信息，无法了解系统状态。这时，一个有效的策略就是求助于Metrics来了解系统的内部情况。下面举一些具体例子来说明。

发现问题

比如下图中的failover指标，其中一行指标不为0，其他指标不为0都是0。这时候问题就发现了。

比如下图，Input指标正常情况下是4到500万，但是突然下降到0了，这里也有一个问题。

业务延迟问题如下图。例如，当比较处理后的数据时a 与当前时间，发现处理后的数据是一小时前的数据。通常，一秒前处理的数据也是有问题的。的。

缩小范围，定位瓶颈

当某个地方很慢但你不知道它在哪里时，如图中红色部分所示如下图，OUT_Q并发值已经达到100%，其他一切都比较正常，甚至非常优秀。此时，生产者-消费者模型就出现了问题。生产者IN_Q已满，消费者OUT_Q也已满。从图中可以看出，节点4已经很慢了。节点1产生的数据无法被节点4处理，节点4也无法处理。 5的性能正常，说明节点1和节点4之间的队列被阻塞，所以我们可以重点关注节点1和节点4，缩小问题范围。

500 InBps 每个有 256 个并行。不可能一一查看这么多点，所以有必要做一个l聚合期间索引号的标签。聚合按标签划分，看看哪一个具有 100% 的并发性。图中可以划分最高的两条线，即线324和线115，从而进一步缩小范围。

使用Metrics缩小范围的方式如下图所示，就是使用Checkpoint Alignment对齐，然后缩小范围，但这种方法很少使用。

多维度分析

为什么分析任务有时这么慢？

当确定某个Task处理特别慢时，就需要分析慢的因素。对导致分析任务缓慢的因素进行优先级排序，可以从上到下、从业务侧到底层系统进行排查。因为大部分问题都发生在业务维度，比如业务维度的影响可以从以下几个方面来看，并发量是否合理、数据波峰波谷、数据倾斜；其次，从Garbage Collection、Checkpoint Alignment、State Backend性能的角度进行分析；最后从系统性能角度进行分析，如CPU、内存、Swap、磁盘IO、吞吐量、容量、网络IO、带宽等。