$30 off During Our Annual Pro Sale. View Details »

Monitoringについてあれこれ語ろう - A Feedback from Cloud Native Deep Dive

Monitoringについてあれこれ語ろう - A Feedback from Cloud Native Deep Dive

Rancher Meetup #18で発表した資料です。
Monitoring、Logging、Alertingについてディスカッションした結果をまとめて共有しました。

Kazuto Kusama

March 19, 2019
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. A Feedback from
    Cloud Native Deep Dive
    Monitoringについてあれこれ語ろう

    View Slide

  2. Pivotal Japan - Solutions Architect
    Kazuto Kusama
    @jacopen

    View Slide

  3. View Slide

  4. View Slide

  5. Cloud Native Deep Dive
    • 従来ながらの講義形式は取らない
    • あらかじめ決められたテーマについて、全員参加で
    ディスカッションを行う
    • ディスカッションを通じて、実戦で使える知識と経験を深め
    ていく
    • 参加登録時にはアンケート回答が必須。
    アンケート未回答者は参加不可。

    View Slide

  6. テーマ
    #1 Manifest管理
    #2 Service Mesh
    #3 Release Engineering
    #JKD 総集編
    #4 Monitoring

    View Slide

  7. 今回は、#4の内容を
    共有します

    View Slide

  8. - Monitoring
    - Logging
    - Alerting

    View Slide

  9. Monitoring

    View Slide

  10. - Blackbox Monitoring
    - Whitebox Monitoring
    分けて考えるべき

    View Slide

  11. ツール
    ● Datadog
    ● Mackerel
    ● Wavefront
    ● Stackdriver
    ● CloudWatch
    ● Prometheus
    ● Elasticsearch
    ● Zabbix
    ● Sysdig
    SaaS IaaS
    Provided
    Self
    Hosted

    View Slide

  12. 監視する対象
    ● Baremetal
    ● VM
    ● Container
    ● Security
    ● Networking
    ● Backend
    ● Frontend
    ● Business KPI
    ・・・他にもいろいろ
    ● Pod
    ● Node
    ● Cluster

    View Slide

  13. みんなの課題
    • どんなメトリクスを監視すればいいのか
    ○ Kubernetesだけでも膨大な種類のメトリクスが
    • Kubernetesのクラスタ管理者とアプリ開発者への
    通知切り分け
    • ロングタームのメトリクス管理方法・
    ダウンサンプリング方法

    View Slide

  14. みんなの課題
    • 外れ値出たときどうするか?
    ○ ここのハンドリング重要
    ○ DatadogやElasticsearchには検出する機能があるが・・・

    View Slide

  15. みんなの課題
    • Prometheusのメモリ使用量多い
    • モニタリングのモニタリング
    • そもそもPrometheus難しい
    ○ relabel_configs
    ○ PromQL
    ■ Prometheusおじさんの発生!

    View Slide

  16. みんなの課題
    • Dashboardの作り方
    ○ JSONのレビュー大変
    ■ GrafanaならDashboard Shopあるが・・・
    ○ できる限りコード管理したい
    ■ Grafanaでexportするたびに形が変わっててキツい
    ● Jsonnetで生成⇒Grafanaに反映 を試そう
    • (Prometheusの場合) Prometheus Operator良い
    ○ 最初からいい感じに作り込まれている
    ○ 必要ならば自分で拡張することも出来る

    View Slide

  17. みんなの課題
    • そもそもDashboardいつ見る?
    ○ 常に見る?
    ○ デプロイ時に見る
    ○ 週次でみる
    ○ 朝会時に見る
    ○ 常に廊下に表示させる

    View Slide

  18. みんなの課題
    • Monitoring 101は読んでおくべき
    ○ https://www.datadoghq.com/blog/tag/monitoring-101/

    View Slide

  19. Logging

    View Slide

  20. よくある構成
    対象
    対象
    対象
    Collector
    Collector
    Collector
    Aggregator
    Log
    Platform
    ログ収集
    集約
    パース
    タギング
    フィルタリング
    保存
    インデックス化
    検索
    可視化

    View Slide

  21. ツール
    ● Fluentd
    ● Fluentbit
    ● LogStash
    ● Splunk
    ● Elasticsearch
    ● CloudWatch Logging
    ● Stackdriver
    ● S3
    ● GCS
    ● DWH
    Collector Log
    Platform

    View Slide

  22. Logging =

    View Slide

  23. Logging = 課金

    View Slide

  24. みんなの課題
    • ロギングはカネがかかる!!
    ○ SaaS高い
    ■ ログ量に比例してガンガン金がかかる
    ○ Self Hostedにしてもかなりの運用・インフラコストかかる
    ■ 最終的には監視対象と同じくらいのインフラリソースがログ基
    盤だけで必要になることも
    ○ 結局は金

    View Slide

  25. みんなの課題
    • Aggregatorの運用辛すぎ
    ○ とにかくここが死ぬ
    ○ ログの保存量を制御することは出来るが、
    ログの流量を制御するのは難しい
    ■ アプリ側が大量のログ吐くとすぐ死ぬ
    ■ Collector側で工夫する?⇒収集すべきものとしないものの判
    断難しい
    ○ パースやフィルタリングなどをやりやすい場所
    ■ でも処理に比例して負荷が増す
    ● 死

    View Slide

  26. みんなの課題
    • ログの形式バラバラ問題
    ○ ミドルウェアによって吐く形式が違う
    ○ チーム間でもログ形式は往々にして異なる
    ■ チーム間で形式統一を試みた⇒無理だった
    ○ パースせずに生データで保存
    ■ 正規表現地獄
    ○ ログ基盤側でなんとかする
    ■ 負荷で激重になる

    View Slide

  27. みんなの課題
    • ログとメトリクスの横断検索が難しい問題
    ○ 何か問題が発生したとき、特定の時刻・特定のコンポーネントにおい
    て、ログとメトリクスを突き合わせて見たい
    ■ ログ基盤とメトリクスが分断していると、
    横断して調べるのが辛い
    ■ SaaSや商用ソフトウェアだと、この機能を
    備えているものもある

    View Slide

  28. Alerting

    View Slide

  29. みんなの課題
    • 閾値の根拠は?
    • 通知先
    ○ Slack
    ○ Chatwork
    ○ Pagerduty
    ○ メール
    • オンコール担当は誰か
    ○ アプリのログはアプリ開発者に
    ○ 基盤のログは基盤運用チームに

    View Slide

  30. みんなの課題
    • 突発的なアラート対応による生産性低下
    ○ Scrum開発しているのに、アラート対応によってスプリント計画が
    めちゃくちゃに
    ○ 不安定な生活リズムによる生産性の低下
    ○ ベロシティバラバラ

    View Slide

  31. みんなの課題
    • オンコール先任者・部門を作るか?
    ○ 対象アプリや基盤の知識が無い人がオンコール対応しても、
    結局そのままエスカレーションされる
    ⇒ コミュニケーションロス
    • オンコールローテーション
    ○ オンコール対応後の休暇など、制度の確立も必要
    ○ 少人数のチームだとどうする?

    View Slide

  32. みんなの課題
    • 誤検知・過剰なアラーティングへの対応
    ○ アラートのレベル分け大事
    • 閾値やアラートレベルの見直しはいつやるか
    ○ 定期的に見直す
    ○ アドホックに対応
    • アラートルールのコード化はどうやるか

    View Slide

  33. みんなの課題
    • 通知すべきメトリクスのベストプラクティスはあるか?
    ○ ない!
    ○ そもそも組織によって結構異なる
    ○ アラーティングは、運用しながら育てる意識を持つこと

    View Slide

  34. 共通課題

    View Slide

  35. それぞれ共通する課題
    • コード化・自動化
    ○ Toilは極限まで減らす意識を持つこと
    ○ 監視ルールは育てていくもの
    • 対応する人・組織・ロール
    ○ できる限り自動化が前提
    ○ 単にコールを受けるだけのロールは悪手になりやすい
    • OSSか商用製品かManaged Serviceか
    ○ ケースバイケース
    ○ 無理に自前主義に走るのは考え物

    View Slide

  36. Cloud Native
    Deep Dive
    https://www.meetup.com/ja-JP/Cloud-Native-Deep-Dive/
    まずはJoin!

    View Slide

  37. CloudNative Days

    View Slide

  38. 技術書典6
    https://techbookfest.org/event/tbf06/circle/56220002
    チェックリストに
    追加してね!

    View Slide

  39. おわり

    View Slide