读书笔记-kafka监控指标梳理_activecontrollercount

参考文档：Kafka监控:主要性能指标 - 全能程序猿 - 博客园

Broker 性能指标

UnderReplicatedPartitions： 分区存在失效副本的的个数；在一个运行健康的集群中，处于同步状态的副本数（ISR）应该与总副本数（简称AR：Assigned Replicas）完全相等，如果分区的副本远远落后于leader，那这个follower将被ISR池删除，由于kafka的高可用性必须通过副本来满足，所以在有必要重点关注这个指标，让他长期处于0的状态。

ActiveControllerCount：表示当前broker是否是集群的控制器。这个指标只有两个可选值，要么为0，要么为1。如果为1，则表示当前broker就是集群的控制器。任何时刻一个集群中有且仅有一个控制器，如果集群中所有broker的ActiveControllerCount指标之和不为1，则说明发生了异常情况，需要及时地告警以通知相关人员排查故障。Controller的职责是维护Partition leader的列表，和协调leader的变更（当遇到某个Partition leader不可用时）。如果有必要更换controller，一个新的controller将会呗zookeeper从broker池中随机的选取出来。通常来说这个值（ActiveControllerCount)不可能大于1，当时当遇到这个值等于0且持续了一段时间（<1 秒）的时候必须发出明确的报警；

OfflinePartitionCount（只有controller有）：这个指标报告了没有活跃leader的Partition数，由于所有的读写操作都只在partition leader上进行，因此非0的这个值需要被报警出来，从而防止服务中断。任何没有活跃leader的partition都会彻底的不可用，且改parititon上的消费者和生产者都将被阻塞，直到leader变成可用。

IsrShrinksPerSec/IsrExpandsPerSec：任意一个分区的处于同步状态的副本数（ISR）应该保持稳定，只有一种例外，就是当你扩展broker节点或者删除某个partition的时候。为了保证高可用性，健康的kafka集群必须要保证最小ISR数，以防在某个Partition挂掉时它的follower可以接管。一个副本从ISR池中移走有以下一些原因：follower的offset远远落后于leader，或者某个follower已经与leader失去联系了某一段时间，不管是什么原因，如果IsrShrinksPerSec(ISR缩水）增加了，但并没有随之而来的IsrExpandsPerSec(ISR扩展）的增加，就将引起重视并人工介入；

LeaderElectionRateAndTimeMs：当Partition leader挂了以后，新leader的选举就被触发。当Partition leader与zookeeper失去连接以后，它就被认为是“死了”，不像zookeeper zab，kakfa没有专门对leader选举采用majority-consensus算法。是kafka的broker集群所有的机器列表，是由每一个partition的ISR所包含的机器这个紫气，加起来的并集组成的。假设一共有三个partition，第一个partition的ISR包含broker1,2,3，第二个partition包含broker2,3,4，第三个partition包含broker3,4,5，那么这三个partition的ISR所在broker节点加起来的并集就是整个kafka集群的所有broker全集1、2、3、4、5.当副本可以被leader捕获到的时候，我们就认为它处于同步状态（in-sync）这意味着任何在ISR池中的节点，都有可能被选举为leader；

LeaderElectionRateAndTimeMs 报告了两点：leader选举的频率（每秒钟多少次）和集群中无leader状态的时长（以毫秒为单位）尽管不像UncleanLeaderElectionsPerSec这个指标那么严重，但你也需要时长关注它，就像上文提到的，leader选举是在与当前leader通信失败时才会触发的，所以这种情况可以理解为存在一个挂掉的broker。

UncleanLeaderElectionsPerSec：这个指标如果存在的话很糟糕，这说明kafka集群在寻找partition leader节点上出现了故障，通常，如果某个作为partition leader的broker挂了以后，一个新的leader会被从ISR集合中选举出来，不干净的leader选举（Unclean leader elections ）是一种特殊的情况，这种情况是副本池中没有存活的副本。基于每个topic必须拥有一个leader，而如果首领是从处于不同步状态的副本中选举出来的话，意味着那些与之前的leader没有被同步的消息，将会永久性丢失。事实上，不干净的leader选举将牺牲持久性（consistency）来保证可用性（availability）。所以，我们必须明确地得到这个指标的告警，从而告知数据的丢失。

TotalTimeMs: The TotalTimeMs metric family measures the total time taken to service a request (be it a produce, fetch-consumer, or fetch-follower request):

这个指标族（很多地方都涉及到它）衡量了各种服务请求的时间（包括produce，fetch-consumer，fetch-follower）

• produce:从producer发起请求发送数据

• fetch-consumer: 从consumer发起请求获取数据

• fetch-follower:follower节点向leader节点发起请求，同步数据

TotalTimeMs 这个指标是由4个其他指标的总和构成的：

• queue:处于请求队列中的等待时间

• local:leader节点处理的时间

• remote:等待follower节点响应的时间（只有当requests.required.acks=-1时）

• response:发送响应的时间

通常情况下，这个指标值是比较稳定的，只有很小的波动。当你看到不规则的数据波动，你必须检查每一个queue,local,remote和response的值，从而定位处造成延迟的原因到底处于哪个segment。

PurgatorySize: 请求炼狱（request purgatory）作为一个临时存放的区域，使得生产(produce)和消费(fetch)的请求在那里等待直到被需要的时候。每个类型的请求都有各自的参数配置，从而决定是否（将消息）添加到炼狱中：

• fetch：当fetch.wait.max.ms定义的时间已到，还没有足够的数据来填充（congsumer的fetch.min.bytes）请求的时候，获取消息的请求就会被扔到炼狱中。

• produce：当request.required.acks=-1，所有的生产请求都会被暂时放到炼狱中，直到partition leader收到follower的确认消息。

关注炼狱的大小有助于判断导致延迟的原因是什么，比如说，导致fetch时间的增加，很显然可以认为是由于炼狱中fetch的请求增加了。

BytesInPerSec/BytesOutPerSec: 通常，磁盘的吞吐量往往是决定kafka性能的瓶颈，但也不是说网络就不会成为瓶颈。根据你实际的使用场景，硬件和配置，网络将很快会成为消息传输过程中最慢的一个环节，尤其是当你的消息跨数据中心传输的时候。跟踪节点之间的网络吞吐量，可以帮助你找到潜在的瓶颈在哪里，而且可以帮助决策是否需要把端到端的消息做压缩处理。

---

主机层面的broker性能指标

Page cache read ratio: kafka在设计最初的时候，通过内核中的页缓存，来达到沟通可靠性（基于磁盘）和高效性（基于内存）之间的桥梁。page cache read ratio（可理解为页缓存读取率），和数据库中的cache-hit ratio(缓存命中率)比较相似，如果这个值比较大，则等价于更快的读取速度，从而有更好的性能。如果发现页缓存读取率<80%，则说明需要增加broker了。

Disk usage: 由于kafka将所有数据持久化到磁盘上，很有必要监控一下kafka的剩余磁盘空间。当磁盘占满时，kafka会失败，所以，随着时间的推移，跟踪磁盘的增长率是很有必要的。一旦你了解了磁盘的增长速率，你就可以在磁盘将要占满之前选择一个合适的时间通知管理员

CPU usage: 尽管kafka主要的瓶颈通常是内存，但并不妨碍观察一下cpu的使用率。虽然即便在使用gzip压缩的场景下，cpu都不太可能对性能产生影响，但是，如果发现cpu使用率突然增高，那肯定要引起重视了。

Network bytes sent/received: 如果你只是在监控kafka的网络in/out指标，那你只会了解到跟kafka相关的信息。如果要全面了解主机的网络使用情况，你必须监控主机层面的网络吞吐量，尤其是当你的kafka主机还承载了其他与网络有关的服务。高网络使用率是性能下降的一种表现，此时需要联系TCP重传和丢包错误，来决定性能的问题是否是网络相关的。