Upgrade to Pro — share decks privately, control downloads, hide ads and more …

burrow_monitoring

 burrow_monitoring

2018/03/16
Apache Kafka Meetup Japan #4 @Yahoo! JAPAN
https://kafka-apache-jp.connpass.com/event/77889/
発表資料

kanga333

March 16, 2018
Tweet

More Decks by kanga333

Other Decks in Programming

Transcript

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

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

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

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

    COMPASS BLADE UNIVERSE
  5. MicroAd におけるKafka 利用 ログ集約基盤 fluentd 中継サー バの構成からKafka を利用する構成に刷新中 ログを集約する際のハブ/ キュー

    として利用 流量はそれなりだがレイテンシに対する要求は厳しくない
  6. クラスタ 150,000 record/sec 3 TB/day 1X brokers version 0.10.2 オンプレのサー

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

  8. Burrow 概要 https://github.com/linkedin/Burrow linkdin 製 consumer のlag をベー スに遅れを検知 lag

    が単調増加している場合アラー ト http サー バとして動作 JSON 形式でconsumer の状態が確認できる 0.8 系の方法にも対応 mail/http で通知できる 複数Burrow を起動した際の通知の排他制御が可能
  9. Kafka の Topic/Partition/Offset/ConsumerGroup 用語おさらい TopicA のパー ティション1 の最新offset は5 Coumer

    group のconsumerB が見ているoffset は4 consumerB のlag は1
  10. 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 より引用
  11. 評価ルー ル 主なルー ルを紹介 1. window 内に一つでもlag0 のタイミングがある ‑> OK

    2. window 内でconsumer offset が変化せずlag が固定または増加 ‑> STALLED consumer が機能していない 3. consumer offset が増加してもlag がwindow 内で単調増加した場合 ‑> WARRNING consumer の取り込みが遅れている
  12. 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 になる可能性
  13. 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 が遅延していると みなされる
  14. 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
  15. 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 が止まっているとみなされる
  16. 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 " } }
  17. 通知 HTTP かMAIL で通知をすることが可能 通知の文面をgo のtemplate 形式で書ける チャットツー ルへの通知はHTTP 通知のテンプレー

    トで実現 Slack 通知用テンプレー トは公式がサンプルとして提供
  18. 通知の排他制御 冗長化のため2 ノー ドburrow を立ち上げたい が、 同じ通知が複数のサー バから来るのは避けたい zookeeper を使って排他制御してくれる

  19. 起動 シングルバイナリを実行 設定ディレクトリを指定 設定は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
  20. その他 offset の推移をグラフで見たい prometheus burrow_exporter を使う topic のoffset consumer のoffset/lag

    etc... アラー トもprometheus に寄せれば良いのでは? という気が...
  21. 参考 Burrow github wiki https://github.com/linkedin/Burrow/wiki/ Linkdin Blog https://engineering.linkedin.com/apache‑kafka/burrow‑ kafka‑consumer‑monitoring‑reinvented