一、操作系統層面需關注的指標
ulimit -n命令將文件描述符限制調整為65535或更高，避免因連接數超過限制導致服務拒絕請求。vm.swappiness=1（低值），減少系統使用swap分區的概率，避免磁盤I/O成為性能瓶頸；vm.dirty_background_ratio≤10（后臺刷臟頁的閾值）、vm.dirty_ratio≤60~80（觸發強制刷臟頁的閾值），優化內存與磁盤的寫入同步，平衡性能與數據安全性；net.core.rmem_default（接收緩沖區默認大?。?、net.core.rmem_max（接收緩沖區最大值）、net.core.wmem_default（發送緩沖區默認大?。?、net.core.wmem_max（發送緩沖區最大值），提升網絡數據傳輸效率。-Xmx4G -Xms4G），減少磁盤交換；同時，Kafka依賴操作系統頁緩存，無需分配過多堆內存給JVM。二、Kafka Broker配置需關注的指標
broker.id：集群中每個Broker的唯一標識（正整數），若IP變更但broker.id不變，不影響消費者消息消費；listeners：Broker監聽的地址與端口（如PLAINTEXT://your.server.ip:9092），用于接收客戶端連接；advertised.listeners：向客戶端廣播的地址與端口（如PLAINTEXT://public.ip:9092），確?？蛻舳四苷_訪問Broker；log.dirs：日志存儲目錄（如/data/kafka-logs），建議使用多個不同磁盤的目錄（逗號分隔），提升磁盤并行寫入性能。num.partitions：主題的初始分區數，需根據消費者線程數（建議與分區數相等）或預期吞吐量設置（如每分區約10MB/s吞吐量），分區數越多并行處理能力越強，但會增加復制延遲；default.replication.factor：主題的默認副本因子（如3），確保數據冗余（至少3個副本），提高可靠性；min.insync.replicas：寫操作需確認的最小副本數（如2），平衡數據可靠性與寫入性能（若設為2，需至少2個副本確認才算成功）。num.network.threads：處理網絡請求的線程數（建議為CPU核心數的2/3），負責接收客戶端請求并轉發至對應線程；num.io.threads：處理磁盤I/O的線程數（建議為CPU核心數的1~2倍），負責消息寫入磁盤、讀取磁盤等操作；num.replica.fetchers：副本拉取線程數（建議為CPU核心數的1/3），負責從Leader副本拉取數據至Follower副本。batch.size：生產者批量發送消息的字節數（建議1MB），減少網絡請求次數，提高吞吐量；linger.ms：生產者發送前的等待時間（建議100ms以上），允許更多消息加入批次，平衡延遲與吞吐量；compression.type：消息壓縮類型（如lz4），減少網絡傳輸數據量（約30%~50%壓縮率），提高吞吐量；buffer.memory：生產者內存緩沖區大?。ńㄗh64MB以上），用于暫存未發送的消息，避免因緩沖區滿導致阻塞；fetch.min.bytes：消費者單次獲取的最小消息字節數（建議1MB），減少網絡請求次數；fetch.max.wait.ms：消費者獲取消息的最大等待時間（建議1000ms），平衡延遲與吞吐量。log.segment.bytes：日志段文件大?。ńㄗh1GB），當日志段達到該大小后會滾動生成新文件，便于日志清理與壓縮；log.retention.hours：日志保留時間（建議168小時，即7天），根據磁盤容量調整，避免磁盤空間耗盡；message.max.bytes：單條消息最大字節數（建議10MB），超過該大小的請求會被拒絕，需與生產者max.request.size參數匹配。三、集群與高可用配置需關注的指標
zookeeper.connect：ZooKeeper集群地址（如zk1:2181,zk2:2181,zk3:2181），Kafka依賴ZooKeeper實現集群管理（如Broker注冊、Topic元數據存儲、Leader選舉），需確保連接穩定；min.insync.replicas：需與副本因子配合設置（如副本因子為3時，min.insync.replicas設為2），確保寫操作的可靠性（只有ISR中的副本確認才算成功），避免因副本滯后導致數據丟失。
