FAQs Kafka消息隊(duì)列 UKafka

ernest.wang 發(fā)布于2022-07-12 17:36 / 2974人閱讀

摘要：大量的和分區(qū)會(huì)嚴(yán)重影響集群性能。介紹可參考收到離線分區(qū)總數(shù)異常告警一般是某個(gè)節(jié)點(diǎn)宕機(jī)或者服務(wù)異常導(dǎo)致。若服務(wù)卡住，可在評(píng)估后在控制臺(tái)重啟該節(jié)點(diǎn)服務(wù)。若想了解當(dāng)前請求延時(shí)情況，建議關(guān)注平均請求延時(shí)監(jiān)控項(xiàng)。

FAQs

本篇目錄

一個(gè)UKafka集群可以創(chuàng)建多少個(gè)Topic？如何增加Topic的副本數(shù)量(ReplicationFactor)？收到離線分區(qū)總數(shù)>=10.0個(gè)告警，離線分區(qū)總數(shù)是什么，怎么處理，怎樣避免影響服務(wù)？怎樣消費(fèi)超過單條1MB的消息？外網(wǎng)怎么訪問UKafka集群？集群單個(gè)節(jié)點(diǎn)配置不夠，需要怎么升級(jí)？怎么查看UKafka集群的監(jiān)控?cái)?shù)據(jù)？發(fā)現(xiàn)zookeeper最大延時(shí)很高，是否有問題？獲取消費(fèi)者詳情錯(cuò)誤創(chuàng)建 Topic 時(shí)，我應(yīng)該怎么設(shè)置分區(qū) Partitions 數(shù)量與副本 replication-factor 數(shù)量？

副本數(shù)量一般建議為 3。Partitions 數(shù)量可根據(jù)集群所有節(jié)點(diǎn)磁盤塊總數(shù)(如普通實(shí)例每個(gè)節(jié)點(diǎn)只掛載一塊磁盤，而均衡I/O型根據(jù)配置不同掛載2-8塊磁盤不等)和客戶端需要的并發(fā)量設(shè)置，一般建議不要設(shè)置過大，影響集群性能。

一個(gè)UKafka集群可以創(chuàng)建多少個(gè)Topic？

集群可以支持任意數(shù)量的Topic，建議使用較大規(guī)模Topic代替大量較小規(guī)模的Topic，例如：需要將消息按天區(qū)分，應(yīng)該在每條消息上加上時(shí)間戳，而不是每天自動(dòng)創(chuàng)建一個(gè)新的Topic。大量的Topic和分區(qū)會(huì)嚴(yán)重影響集群性能。

如何增加Topic的副本數(shù)量(ReplicationFactor)？

參考官方文檔

在增加topic的副本時(shí)，由于會(huì)復(fù)制數(shù)據(jù)，建議節(jié)點(diǎn)數(shù)據(jù)盤保留有足夠的空間。

節(jié)點(diǎn)kafka-logs目錄下consumer_offset相關(guān)目錄占用大量磁盤空間不釋放，怎么處理？

__consumer_offset 是 Kafka 用來存放客戶端消費(fèi)的 offset 信息的 Topic，默認(rèn)采用壓縮策略。

修改 log.cleaner.enable 參數(shù)為 ture，然后按順序重啟每個(gè)節(jié)點(diǎn)kafka服務(wù)。

收到離線分區(qū)總數(shù)>=10.0個(gè)告警，離線分區(qū)總數(shù)是什么，怎么處理，怎樣避免影響服務(wù)？

分區(qū)是Kafka中Topic的一個(gè)物理概念上的消息分塊，以實(shí)現(xiàn)服務(wù)的分布式與高可用。（Kafka介紹可參考intro）

收到離線分區(qū)總數(shù)異常告警一般是某個(gè)節(jié)點(diǎn)宕機(jī)或者服務(wù)異常導(dǎo)致。可通過UKafka console“節(jié)點(diǎn)管理”頁面，依次查看每個(gè)節(jié)點(diǎn)“關(guān)聯(lián)的Topic”信息，若為空，說明此節(jié)點(diǎn)異常，進(jìn)而

可在“節(jié)點(diǎn)管理”中查看server.log，觀察是否有異常日志。若kafka服務(wù)卡住，可在評(píng)估后在控制臺(tái)重啟該節(jié)點(diǎn)kafka服務(wù)。

排查過程中，每個(gè)Topic的復(fù)制因子replication-factor盡量大于等于3，以避免單機(jī)故障帶來的業(yè)務(wù)不可用

怎樣消費(fèi)超過單條1MB的消息？

集群默認(rèn)配置 message.max.bytes 為 1MB，若需支持更大的消息，可通過集群參數(shù)配置管理修改 message.max.bytes，replica.fetch.max.bytes，consumer 端則需修改 fetch.message.max.bytes。

外網(wǎng)怎么訪問UKafka集群？

暫不提供外網(wǎng)訪問集群功能。

集群單個(gè)節(jié)點(diǎn)配置不夠，需要怎么升級(jí)？

默認(rèn)不支持單個(gè)節(jié)點(diǎn)縱向升級(jí)，如果需要擴(kuò)充資源，可以橫向添加節(jié)點(diǎn);如果遇到內(nèi)存或其它單個(gè)節(jié)點(diǎn)的資源瓶頸，可以聯(lián)系我們提供后臺(tái)升級(jí)。

怎么查看UKafka集群的監(jiān)控?cái)?shù)據(jù)？

集群監(jiān)控視圖頁面提供集群流入、流出數(shù)據(jù)量、消息個(gè)數(shù)監(jiān)控，Kafka生產(chǎn)者、消費(fèi)者監(jiān)控?cái)?shù)據(jù)，以及Zookeeper相關(guān)監(jiān)控?cái)?shù)據(jù)，并提供每個(gè)Broker上的CPU、MEM、磁盤、網(wǎng)卡，Kafka服務(wù)，以及Zookeeper監(jiān)控?cái)?shù)據(jù)；可通過Kafka Manager頁面查看每個(gè)Topic、Broker的實(shí)時(shí)流量。

發(fā)現(xiàn)zookeeper最大延時(shí)很高，是否有問題？

zookeeper最大延時(shí)（zk_max_latency）是表示集群創(chuàng)建以來出現(xiàn)過的請求延時(shí)最大值，無法代表當(dāng)前狀態(tài)。若想了解當(dāng)前zookeeper請求延時(shí)情況，建議關(guān)注平均請求延時(shí)監(jiān)控項(xiàng)。

獲取消費(fèi)者詳情錯(cuò)誤

目前控制臺(tái)消費(fèi)者信息是根據(jù)消費(fèi)者類型分別通過訪問 zookeeper 或者調(diào)用 kafka api 得到的，但是 kafka 客戶端 sdk 可以靈活的決定對(duì)消費(fèi)者信息的存儲(chǔ)方式，所以在使用沒有以標(biāo)準(zhǔn)方式存儲(chǔ)信息的 sdk 時(shí)，消費(fèi)者信息可能會(huì)獲取錯(cuò)誤。對(duì)于這些消費(fèi)者，我們目前沒有去多帶帶適配，已知會(huì)出現(xiàn)問題的 sdk 有：

pykafka https://github.com/Parsely/pykafka/issues/888 https://github.com/Parsely/pykafka/issues/567jstorm：不會(huì)按標(biāo)準(zhǔn)的方式存儲(chǔ)消費(fèi)者組信息，是由自己管理消費(fèi)實(shí)例與 topic partition 的對(duì)應(yīng)關(guān)系以及對(duì)應(yīng)的 offset，部分信息存儲(chǔ)在 zookeeper 的 /jstorm 路徑下flink 0.9 版本的 kafka 消費(fèi)信息由自己管理，不會(huì)在 kafka 這邊注冊生成 group 信息

在遇到獲取信息錯(cuò)誤時(shí)，可以先使用 kafka-consumer-groups.sh --bootstrap-server $(hostname):9092 --describe --group $group 命令確認(rèn)消費(fèi)者是否有信息缺失或者錯(cuò)誤。

重新分區(qū)

擴(kuò)容節(jié)點(diǎn)后，在原來機(jī)器上的 topic partition 不會(huì)自動(dòng)均衡到新的機(jī)器，需要使用分區(qū)重新分配工具來均衡

重分區(qū)功能官方描述

控制臺(tái)提供的功能是Automatically migrating data to new machines的部分