Metrics 和监控（二）| 学习笔记

开发者学堂课程【Apache Flink 入门到实战 - Flink 开源社区出品 ：Metrics 和监控（二）】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/632/detail/10046

Metrics 和监控（二）

五、如何获取 Metrics

1、Web UI

2、RESTful API(对程序比较友好，写自动化脚本，运维；通过 RESTful API 解析格式，这样对程序友好 )

详见：htps://dapache.orz/orojedsftimnk fink doc-release 18/montorne/ret aplhtonl

以上是逻辑：

（1）Web UI和RESTful API

通过中心化的一个节点，定期去拉从各个组件实现。细节：拉，不一定实时更新。一个定期更新的逻辑。

小问题：不同步。因为某种情况没拉过来是不会更新的。因此会延迟。试着等一下就会更新。 

（2）红色的线有一个中心化的节点去聚合。

（3）蓝色的线是每一个单独的点。去直接汇报。如果要聚合需要在第三方。优点：内存大。用原始数据做处理。 

3、Metric Reporter（功能强大）

Flink 内置了很多 Reporter，对外部系统的技术选型可以参考，详见：

https://ci.apache.org/projects/flink/flink-docs-release-

1.8/monitoring/metrics.htm|#reporter

Metric Reporter Configuration Example

metrics.reporters: your monitorimx

metrics.reporter.jmx.class（必须）:org.apache.flink.metrics.jmx.JMXReporter

metrics.reporter.jmx.port:1025-10000

metrics.reporter.your_monitor.class（必须）: com.your company.YourMonitorClass

metrics.reporter（自定义）.your monitor.interval: 10 SECONDS

metrics.reporter.your_monitor.config.a: your_a_value

metrics.reporter.your_monitor.config（自定义）.b: your_b_value

（常见的系统：Graphite 、InfluxDB、Prometheus、SIf4j 调试好用）

 

六、实战：利用 Metrics 监控

1、自动化运维

(1) 收集 Metrics 作为决策依据

利用 Metric Reporter 收集 Metrics 到

存储/分析系统（例如 TSDB)

或者直接通过 RESTful API

(2)定制监控规则

关注关键指标，Failover,

Checkpoint, 业务 Delay（可能没有，需自己添加）

3）通知工具

自动报警：

钉钉报警，邮件报警，短信报警，电话报警

(4)大盘、报表、指标

通过大盘时刻了解作业总体信息

通过报表分析优化

下图所示大盘：可以关注业务延迟，队列的状况等

2、性能分析

（1）发现问题

异常指标

（2）剖析问题

缩小范围，验证假设，找

到瓶颈页

（3）分析原因

业务逻辑，JVM，操作系统，

State, 数据分布，高级功能

（4）借助 profiling工具

 

七、实战

“我的任务慢，怎么办”

1、为什么提问没人回答？

（一般没有老师会回答，闻着伤心，听者流泪，提问黑洞，话题终结者）

系统框架问题，需要进行很多轮的剖析。对于系统运作不熟悉，可以求助 Metrics

例如：发现一个 failover 的问题，都应该是0，但是有一个突起

延迟，自己统计的数据和当前数据不一致。也有问题。

TPS 的突降也是有问题的

常用的解决方法：

（1）缩小范围，定位瓶颈

例如：后面都是空的，但是前面满了。那么说明是一号节点的问题，这是就可以主要检查一号节点。100%是指最大值

发现324就是最高的，这时就可以缩小范围。

（2）多维度分析

①　业务维度（多）

并发度是否合理

数据波峰波谷（是不是平均的，波峰波谷）

数据倾斜（统计出来发现有些很满，有些没有，较难解决，是否打散数据）

②　Garbage Collection（常见，内存没有配够，越来越慢，看GC）

GC log

③　Checkpoint Alignment（对齐，发现前三者没有问题，可以将其对齐）

④　State Backend 性能（如果数据量很大的需要小心）

Rockdb（随着数据量的增大，性能会下降，但又不会断崖似的下跌，下降的很慢。可能积攒了几天数据之后才会延迟，比较难查。）

⑤　系统性能

CPU

内存，Swap

Disk IO， 吞吐量，容量

Network IO， 带宽

（越往下，概率越小。先缩小范围，利用 metrics） 

2、为什么

黑盒，缺少信息，无法了解系统状态

3、怎么办

求助 metrics

回答问题：

1、report 是专门的现成吗？

是的，每个 report 都是自己单独的。

2、Flink 内部的现成

有很多。