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

Transcript

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

2. Pivotal Japan - Solutions Architect Kazuto Kusama @jacopen

3. None
4. None

5. Cloud Native Deep Dive • 従来ながらの講義形式は取らない • あらかじめ決められたテーマについて、全員参加で ディスカッションを行う •

   ディスカッションを通じて、実戦で使える知識と経験を深め ていく • 参加登録時にはアンケート回答が必須。 アンケート未回答者は参加不可。

6. テーマ #1 Manifest管理 #2 Service Mesh #3 Release Engineering #JKD

   総集編 #4 Monitoring

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

8. - Monitoring - Logging - Alerting

9. Monitoring

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

11. ツール • Datadog • Mackerel • Wavefront • Stackdriver •

    CloudWatch • Prometheus • Elasticsearch • Zabbix • Sysdig SaaS IaaS Provided Self Hosted

12. 監視する対象 • Baremetal • VM • Container • Security •

    Networking • Backend • Frontend • Business KPI ･･･他にもいろいろ • Pod • Node • Cluster

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

    ダウンサンプリング方法

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

15. みんなの課題 • Prometheusのメモリ使用量多い • モニタリングのモニタリング • そもそもPrometheus難しい ◦ relabel_configs ◦

    PromQL ▪ Prometheusおじさんの発生！

16. みんなの課題 • Dashboardの作り方 ◦ JSONのレビュー大変 ▪ GrafanaならDashboard Shopあるが･･･ ◦ できる限りコード管理したい

    ▪ Grafanaでexportするたびに形が変わっててキツい • Jsonnetで生成⇒Grafanaに反映 を試そう • (Prometheusの場合) Prometheus Operator良い ◦ 最初からいい感じに作り込まれている ◦ 必要ならば自分で拡張することも出来る

17. みんなの課題 • そもそもDashboardいつ見る？ ◦ 常に見る？ ◦ デプロイ時に見る ◦ 週次でみる ◦

    朝会時に見る ◦ 常に廊下に表示させる

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

19. Logging

20. よくある構成 対象 対象 対象 Collector Collector Collector Aggregator Log Platform

    ログ収集 集約 パース タギング フィルタリング 保存 インデックス化 検索 可視化

21. ツール • Fluentd • Fluentbit • LogStash • Splunk •

    Elasticsearch • CloudWatch Logging • Stackdriver • S3 • GCS • DWH Collector Log Platform

22. Logging =

23. Logging = 課金

24. みんなの課題 • ロギングはカネがかかる！！ ◦ SaaS高い ▪ ログ量に比例してガンガン金がかかる ◦ Self Hostedにしてもかなりの運用・インフラコストかかる

    ▪ 最終的には監視対象と同じくらいのインフラリソースがログ基 盤だけで必要になることも ◦ 結局は金

25. みんなの課題 • Aggregatorの運用辛すぎ ◦ とにかくここが死ぬ ◦ ログの保存量を制御することは出来るが、 ログの流量を制御するのは難しい ▪ アプリ側が大量のログ吐くとすぐ死ぬ

    ▪ Collector側で工夫する？⇒収集すべきものとしないものの判 断難しい ◦ パースやフィルタリングなどをやりやすい場所 ▪ でも処理に比例して負荷が増す • 死

26. みんなの課題 • ログの形式バラバラ問題 ◦ ミドルウェアによって吐く形式が違う ◦ チーム間でもログ形式は往々にして異なる ▪ チーム間で形式統一を試みた⇒無理だった ◦

    パースせずに生データで保存 ▪ 正規表現地獄 ◦ ログ基盤側でなんとかする ▪ 負荷で激重になる

27. みんなの課題 • ログとメトリクスの横断検索が難しい問題 ◦ 何か問題が発生したとき、特定の時刻・特定のコンポーネントにおい て、ログとメトリクスを突き合わせて見たい ▪ ログ基盤とメトリクスが分断していると、 横断して調べるのが辛い ▪

    SaaSや商用ソフトウェアだと、この機能を 備えているものもある

28. Alerting

29. みんなの課題 • 閾値の根拠は？ • 通知先 ◦ Slack ◦ Chatwork ◦

    Pagerduty ◦ メール • オンコール担当は誰か ◦ アプリのログはアプリ開発者に ◦ 基盤のログは基盤運用チームに

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

31. みんなの課題 • オンコール先任者・部門を作るか？ ◦ 対象アプリや基盤の知識が無い人がオンコール対応しても、 結局そのままエスカレーションされる ⇒ コミュニケーションロス • オンコールローテーション

    ◦ オンコール対応後の休暇など、制度の確立も必要 ◦ 少人数のチームだとどうする？

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

    アドホックに対応 • アラートルールのコード化はどうやるか

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

34. 共通課題

35. それぞれ共通する課題 • コード化・自動化 ◦ Toilは極限まで減らす意識を持つこと ◦ 監視ルールは育てていくもの • 対応する人・組織・ロール ◦

    できる限り自動化が前提 ◦ 単にコールを受けるだけのロールは悪手になりやすい • OSSか商用製品かManaged Serviceか ◦ ケースバイケース ◦ 無理に自前主義に走るのは考え物

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

37. CloudNative Days

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

39. おわり