这篇文章介绍了如何利用Apache Flink的内置指标系统以及如何使用Prometheus来高效地监控流式应用程序。
本文主要介绍将flink任务运行的metric发送到Prometheus，通过grafana报表工具展示。
本文作者：BYD信息中心-数据中心管理部-董睿 这里打一个小广告，手动狗头 比亚迪西安研发中心（与深圳协同办公），base西安。招聘大数据平台运维方向工程师，实时计算方向工程师，感兴趣的小伙伴请投递简历至dong.rui@byd.com 1.文档编写目的 Prometheus 是一款基于时序数据库的开源监控告警系统，Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。Grafana是一款采用 Go语言编写的开源应用，是一个跨平台的开源
通过上期的分享，我们对 Metrics 类库有了较深入的认识，并对指标监控的几个度量类型了如指掌。
一个监控系统对于每一个服务和应用基本上都是必不可少的。在 Flink 源码中监控相关功能主要在 flink-metrics 模块中，用于对 Flink 应用进行性能度量。Flink 监控模块使用的是当前比较流行的 metrics-core 库，来自 Coda Hale 的 dropwizard/metrics [1]。dropwizard/metrics 不仅仅在 Flink 项目中使用到，Kafka、Spark 等项目也是用的这个库。Metrics 包含监控的指标（Metric）以及指标如何导出（Reporter）。Metric 为多层树形结构，Metric Group + Metric Name 构成了指标的唯一标识。Reporter 支持上报到 JMX、Influxdb、Prometheus 等时序数据库。Flink 监控模块具体的使用配置可以在 flink-core 模块的 org.apache.flink.configuration.MetricOptions 中找到。
实时作业要保证7 x 24运行，除了要在业务逻辑和编码上下功夫之外，好的监控系统也是必不可少的。Flink支持多种汇报监控指标（metrics）的reporter，如JMX、SLF4J、InfluxDB、Prometheus等。
作者：吴云涛，腾讯 CSIG 高级工程师 一个监控系统对于每一个服务和应用基本上都是必不可少的。在 Flink 源码中监控相关功能主要在 flink-metrics 模块中，用于对 Flink 应用进行性能度量。Flink 监控模块使用的是当前比较流行的 metrics-core 库，来自 Coda Hale 的 dropwizard/metrics [1]。dropwizard/metrics 不仅仅在 Flink 项目中使用到，Kafka、Spark 等项目也是用的这个库。Metrics 包含监控的指标
在进入本文之前，我先问大家一个问题，你们公司或者业务系统上是如何对生产集群上的数据同步任务、实时计算任务或者是调度任务本身的执行情况和日志进行监控的呢？可能你会回答是自研或者ELK系统或者Zabbix系统。
---- 作者：吴云涛，腾讯 CSIG 高级工程师 本文描述了如何使用腾讯云大数据组件来完成实时监控系统的设计和实现，通过实时采集并分析云服务器（CVM）及其 App 应用的 CPU和内存等资源消耗数据，以短信、电话、微信消息等方式实时反馈监控告警信息，高效地保障系统稳健运行。运用云化的 Kafka、Flink、ES 等组件，大大减少了开发运维人员的投入。 一、解决方案描述 （一）概述 本方案结合腾讯云 CKafka、流计算 Oceanus (Flink)、 Elasticsearch、Promethe
本文描述了如何使用腾讯云大数据组件来完成实时监控系统的设计和实现，通过实时采集并分析云服务器（CVM）及其 App 应用的 CPU和内存等资源消耗数据，以短信、电话、微信消息等方式实时反馈监控告警信息，高效地保障系统稳健运行。运用云化的 Kafka、Flink、ES 等组件，大大减少了开发运维人员的投入。
Flink 的 metrics 是 Flink 公开的一个度量系统，metrics 也可以暴露给外部系统，通过在 Flink 配置文件 conf/flink-conf.yaml 配置即可，Flink原生已经支持了很多reporter，如 JMX、InfluxDB、Prometheus 等等。
这期的分享是监控实战，其实不想写这篇的，因为网上相关的文章也挺多的，但是出于光说不练都是假把式，而且也想告诉你：当帅气的普罗米修斯（Prometheus）遇到高颜值的格拉法纳（Grafana）究竟会擦出什么样的火花？所以忍不住还是想分享啊。
https://www.apache.org/dyn/closer.lua/flink/flink-1.11.3/flink-1.11.3-bin-scala_2.12.tgz
对于需要7 * 24小时不间断运行的流式计算程序来说，能实时监控程序运行状况、出现异常告警能立即响应并快速定位问题是必须具备的能力。
虽然笔者之前写过基于Prometheus PushGateway搭建Flink监控的过程，但是在我们的生产环境中，使用的是InfluxDB。InfluxDB是一个由Go语言写成的、由InfluxData部分开源的时序数据库，能够非常好地处理监控指标的存储和查询，配合Grafana即可简单地实现Flink作业metrics的收集与展示。本文简述配置过程及一些小问题。
好久没更新Flink系列了，之前果然在Flink SQL 上淹死了，那部分暂时咕一段时间，等日后学有所成再补上，由于最近对普罗米修斯感兴趣，今天借机来说说监控吧，本文以推模式为例进行阐述的。对于监控有兴趣的同学，也可以移步到《Prometheus入门》去看看。
前阵子笔者涉及了些许监控相关的开发工作，在开发过程中也碰到过些许问题，便翻读了Flink相关部分的代码，在读代码的过程中发现了一些好的设计，因此也是写成文章整理上来。
以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes 生态的 k8s 原生 scheduler 以及周边资源调度器，比如 Volcano 和 Yunikorn 等。这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同，以及对于应用到生产环境我们还需要做些什么。
背景：使用的 VictoriaMetrics(简称 VM) 作为监控的解决方案，需要将 django 服务、logstash 和 flink 引擎接入进来，VM 可以实时的获取它们的指标存储并进行监控告警，以上的服务都是部署在 k8s 中的。
下面，我们简要介绍 Flink 集群的构建块、它们的用途和可用的实现。 如果你只是想在本地启动 Flink，我们建议设置一个 Standalone Cluster。
首先请安装好prometheus、pushgateway以及grafana，如果还没安装请参考：
最近 AutoTrader 在调试一个有些复杂的问题，这一过程得到了 Istio 团队的很多帮助。这个问题现在已经基本得到了解决，这一过程中采取的一些措施可能对其他用户有所启发，因此有了本文。
流计算 Oceanus 是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点的企业级实时大数据分析平台。流计算 Oceanus 以实现企业数据价值最大化为目标，加速企业实时化数字化的建设进程。
流计算 Oceanus 简介 流计算 Oceanus 是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点的企业级实时大数据分析平台。流计算 Oceanus 以实现企业数据价值最大化为目标，加速企业实时化数字化的建设进程。 本文首先介绍了几种最常见、最基础的错误，用户在使用的时候可以尽量规避的问题。接下来介绍了流计算 Oceanus 平台的监控系统，可以帮助用户实时了解作业各个层级的明细及运行状态。然后借助于日志系统帮助诊
流计算作业通常运行时间长，数据吞吐量大，且对时延较为敏感。但实际运行中，Flink 作业可能因为各种原因出现吞吐量抖动、延迟高、快照失败等突发情况，甚至发生崩溃和重启，影响输出数据的质量，甚至会导致线上业务中断，造成报表断崖、监控断点、数据错乱等严重后果。
第11章 推送指标和Pushgateway 在某些情况下，没有可以从中抓取指标的目标。造成这种情况的原因有很多 安全性或连接性问题，使你无法访问目标资源。这是一种非常常见的情况，比如服务或应用程序仅允许特定端口或路径访问 目标资源的生命周期太短，例如容器的启动、执行和停止。在这种情况下，Prometheus作业将会发现目标已完成执行并且不再可以被抓取 目标资源没有可以抓取的端点，例如批处理作业。批处理作业不太可能具有可被抓取的HTTP服务，即使假设作业运行的时间足够长 在这些情况下，我们需要将时间序列传递或
Flagger 团队很荣幸为你带来 Kubernetes Gateway API 支持，作为1.19.0 版本[1]的一部分。阅读本文，了解为什么这是 Flagger 的一个重大发展，以及如何利用它。
APM系统即Application Performance Management应用性能管理，目的是对企业的关键业务系统进行实时性能监控和故障管理，主要有以下三个维度：日志聚合Logs、业务指标Metrics、链路跟踪Traces。
最近将Flink集群从1.6升级到1.8，主要是为了使用1.8的两个特性：一个是universal kafka ，另外一个是rocksdb ttl, 然后注意到1.8 提供了Influxdb 的reporter, 在最开始1.6使用的rest api方式主动请求对应的metric, 使用这种方式目前有两个弊端：
随着互联网技术的广泛使用，信息的实时性对业务的开展越来越重要，特别是业务的异常信息，没滞后一点带来的就是直接的经济损失。所以实时信息处理能力，越来越成为企业的重要竞争力之一。Flink作为业内公认的性能最好的实时计算引擎，以席卷之势被各大公司用来进处理实时数据。然而Flink任务开发成本高，运维工作量大，面对瞬息万变得业务需求，工程师往往是应接不暇。如果能有一套实时计算平台，让工程师或者业务分析人员通过简单的SQL或者拖拽式操作就可以创建Flink任务，无疑可以快速提升业务的迭代能力。
虽然 Flagger 可以单独执行加权路由和 A/B 测试，但通过 Istio，它可以将两者结合起来，从而形成具有会话关联性的 Canary 版本。这种部署策略将金丝雀发布与 A/B 测试相结合，当我们尝试逐步向用户推出新功能时，金丝雀发布是很有帮助的，但由于其路由的特性（基于权重），即使用户之前已经被路由到新版本，他们仍然还有路由到应用程序的旧版本上，这种情况可能不符合我们的预期。
Prometheus 是当下火热的监控解决方案，尤其是容器微服务架构，Kubernetes 的首选监控方案。关于为什么要用 Prometheus，我这里就不多讲，相关的文章太多了，大家也可以看看官方的说法。本文就讲讲如何自动化的搭建一套基于 Kubernetes 集群的 Prometheus 监控系统。
Kubernetes 原生的 Deployment 利用 Rolling Update 滚动更新的策略在应用升级时提供基本的安全保证（例如就绪探针）。然而默认的滚动更新策略存在着一些明显的缺点，例如：
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。
ack 数据源是否需要kafka得到确认。all表示需要收到所有ISR节点的确认信息，1表示只需要收到kafka leader的确认信息，0表示不需要任何确认信息。该配置项需要对数据精准性和延迟吞吐量做出权衡。
Flink自1.11.0 版本开始，已经支持了hadoop 3.x，具体来讲就是将 HADOOP_CLASSPATH 配置成运行机器上的hadoop3 相关jar包即可。
Flink 提供的 Metrics 可以在 Flink 内部收集一些指标，通过这些指标让开发人员更好地理解作业或集群的状态。由于集群运行后很难发现内部的实际状况，跑得慢或快，是否异常等，开发人员无法实时查看所有的 Task 日志，比如作业很大或者有很多作业的情况下，该如何处理？此时 Metrics 可以很好的帮助开发人员了解作业的当前状况。 Metric Types
The following article is from 腾讯技术工程 Author 腾讯程序员 作者：龙逸尘，腾讯 CSIG 高级工程师 为什么要构建监控系统 在后移动互联网时代，良好的用户体验是增长的基础，稳定的使用体验就是用户体验的基础。大型的互联网公司，特别是面向 C 端客户的公司，对业务系统稳定性的要求越来越高，因此对线上问题发现和处理的速度要求通常是分钟级的。比如滴滴等出行公司，打车服务停摆 10 分钟都会导致导致乘客、司机大规模投诉，不仅造成经济损失，而且严重平台商誉和用户口碑。 大型
为什么要构建监控系统 作者：龙逸尘，腾讯 CSIG 高级工程师 在后移动互联网时代，良好的用户体验是增长的基础，稳定的使用体验就是用户体验的基础。大型的互联网公司，特别是面向 C 端客户的公司，对业务系统稳定性的要求越来越高，因此对线上问题发现和处理的速度要求通常是分钟级的。比如滴滴等出行公司，打车服务停摆 10 分钟都会导致导致乘客、司机大规模投诉，不仅造成经济损失，而且严重平台商誉和用户口碑。 大型互联网公司的业务系统都是大规模的分布式系统，各种业务应用和基础组件（数据库、缓存、消息队列等）共同
在后移动互联网时代，良好的用户体验是增长的基础，而稳定的使用体验则是用户体验的基础。大型的互联网公司，尤其是面向 C 端客户的公司，对业务系统稳定性的要求越来越高，因此对线上问题发现和处理的速度要求通常是分钟级的。比如滴滴等出行公司，打车服务停摆 10 分钟都会导致导致乘客、司机大规模投诉，不仅造成经济损失，而且严重平台商誉和用户口碑。
BIGO 是一家面向海外的以短视频直播业务为主的公司, 目前公司的主要业务包括 BigoLive (全球直播服务)，Likee (短视频创作分享平台)，IMO (免费通信工具) 三部分，在全球范围内拥有 4 亿用户。伴随着业务的发展，对数据平台处理能力的要求也是越来越高，平台所面临的问题也是日益凸显，接下来将介绍 BIGO 大数据平台及其所面临的问题。BIGO 大数据平台的数据流转图如下所示：
Spring Boot是一款非常流行的Java框架，它可以快速开发基于Spring的应用程序。监控是应用程序运行的重要组成部分，它可以帮助我们了解应用程序的状态，识别性能瓶颈，并快速解决问题。Spring Boot提供了一些内置的监控工具，本文将介绍Spring Boot监控的详细文档，并给出一些示例。
Apache Flink 是流式计算处理领域的领跑者。它凭借易用、高吞吐、低延迟、丰富的算子和原生状态支持等优势，多方位领先同领域的开源竞品。
Prometheus 是由 SoundCloud 开源监控告警解决方案。2012年成为在社区开源，拥有非常活跃的开发人员和用户社区，Prometheus于2016年加入云原生计算基金会（CNCF），成为继k8s之后的第二个托管项目。
领取专属 10元无门槛券
手把手带您无忧上云
