Burrow によるKafka 流量モニタリング @kanga333 (Kagawa Shoichi)

自己紹介 @kanga333 ( 香川翔一) MicroAd,Inc. インフラチー ム デー タ基盤やコンテナ基盤の設計～ 運用

アジェンダ MicroAd におけるKafka の利用について Burrow について

MicroAd の紹介 事業内容 アドプラットフォー ム デー タプラットフォー ム SSP/DSP/DMP を提供 COMPASS BLADE UNIVERSE

MicroAd におけるKafka 利用 ログ集約基盤 fluentd 中継サー バの構成からKafka を利用する構成に刷新中 ログを集約する際のハブ/ キュー として利用 流量はそれなりだがレイテンシに対する要求は厳しくない

クラスタ 150,000 record/sec 3 TB/day 1X brokers version 0.10.2 オンプレのサー バにCloudera Manager でデプロイ

流量監視の必要性 ログは成長する カラムが追加される 件数が増える 取り込み対象がふえる 書き込み先の負荷も変化する 障害によるノー ド増減 重い処理の実行 問題なく取り込めていたログもいつの間にか遅延するように

Burrow 概要 https://github.com/linkedin/Burrow linkdin 製 consumer のlag をベー スに遅れを検知 lag が単調増加している場合アラー ト http サー バとして動作 JSON 形式でconsumer の状態が確認できる 0.8 系の方法にも対応 mail/http で通知できる 複数Burrow を起動した際の通知の排他制御が可能

Kafka の Topic/Partition/Offset/ConsumerGroup 用語おさらい TopicA のパー ティション1 の最新offset は5 Coumer group のconsumerB が見ているoffset は4 consumerB のlag は1

Burrow のEvaluation Window 時系列でconsumer のoffset/lag/timestamp を格納したもの デフォルトのEvaluation Window は10 個（ 以下の例は5） Burrow はこのEvaluation Window 全体に対して遅延を評価する W1 W2 W3 W4 W5 Offset 10 20 30 40 50 Lag 0 0 1 2 3 Timestamp T T+10 T+20 T+30 T+40 ※burrow wiki より引用

評価ルー ル 主なルー ルを紹介 1. window 内に一つでもlag0 のタイミングがある ‑> OK 2. window 内でconsumer offset が変化せずlag が固定または増加 ‑> STALLED consumer が機能していない 3. consumer offset が増加してもlag がwindow 内で単調増加した場合 ‑> WARRNING consumer の取り込みが遅れている

OK の例 W1 W2 W3 W4 W5 Offset 10 20 30 40 50 Lag 0 0 1 2 3 Timestamp T T+10 T+20 T+30 T+40 lag が0 のタイミングがあるのでOK ただし、W3～W5 のタイミングで単調増加の傾向がある ‑> W6,W7 と進んでいくとWARNNING になる可能性

WARNNING の例 W3 W4 W5 W6 W7 Offset 30 40 50 60 70 Lag 1 2 3 4 5 Timestamp T+20 T+30 T+40 T+50 T+60 offset が進んでいてもlag が単調増加しておりconsume が遅延していると みなされる

OK の例 その2 W1 W2 W3 W4 W5 Offset 10 20 30 40 50 Lag 1 3 2 1 4 Timestamp T T+10 T+20 T+30 T+40 W1 とW5 を比較するとlag は増加しているがW3,W4 など 一部のポイントではlag が減少したた ‑> consume は追いついているとみなされOK

STALLED の例 W1 W2 W3 W4 W5 Offset 10 10 10 10 10 Lag 1 2 3 3 4 Timestamp T T+10 T+20 T+30 T+40 window 全体でconsumer offset に変更が無い lag は増えているのでtopic へは書き込みが続いている ‑> consume が止まっているとみなされる

JSON offset の状況などはAPI で確認できる / v 3 / k a f k a / k a f k a - c l u s t e r A / t o p i c / t o p i c A { " e r r o r " : f a l s e , " m e s s a g e " : " t o p i c o f f s e t s r e t u r n e d " , " o f f s e t s " : [ 1 1 5 8 4 3 3 9 2 7 7 , 1 2 2 3 9 0 4 8 4 5 8 , 1 2 3 0 4 3 8 5 9 8 0 ] , " r e q u e s t " : { " u r l " : " / v 3 / k a f k a / k a f k a - c l u s t e r A / t o p i c / t o p i c A " , " h o s t " : " 8 a 2 e b 4 d e 7 8 c 9 " } }

通知 HTTP かMAIL で通知をすることが可能 通知の文面をgo のtemplate 形式で書ける チャットツー ルへの通知はHTTP 通知のテンプレー トで実現 Slack 通知用テンプレー トは公式がサンプルとして提供

通知の排他制御 冗長化のため2 ノー ドburrow を立ち上げたい が、 同じ通知が複数のサー バから来るのは避けたい zookeeper を使って排他制御してくれる

起動 シングルバイナリを実行 設定ディレクトリを指定 設定はtoml/yaml/json で書ける $ b u r r o w - - c o n f i g - d i r / e t c / b u r r o w

その他 offset の推移をグラフで見たい prometheus burrow_exporter を使う topic のoffset consumer のoffset/lag etc... アラー トもprometheus に寄せれば良いのでは？ という気が...

参考 Burrow github wiki https://github.com/linkedin/Burrow/wiki/ Linkdin Blog https://engineering.linkedin.com/apache‑kafka/burrow‑ kafka‑consumer‑monitoring‑reinvented