Rancher Meetup #18で発表した資料です。 Monitoring、Logging、Alertingについてディスカッションした結果をまとめて共有しました。
A Feedback fromCloud Native Deep DiveMonitoringについてあれこれ語ろう
View Slide
Pivotal Japan - Solutions ArchitectKazuto Kusama@jacopen
Cloud Native Deep Dive• 従来ながらの講義形式は取らない• あらかじめ決められたテーマについて、全員参加でディスカッションを行う• ディスカッションを通じて、実戦で使える知識と経験を深めていく• 参加登録時にはアンケート回答が必須。アンケート未回答者は参加不可。
テーマ#1 Manifest管理#2 Service Mesh#3 Release Engineering#JKD 総集編#4 Monitoring
今回は、#4の内容を共有します
- Monitoring- Logging- Alerting
Monitoring
- Blackbox Monitoring- Whitebox Monitoring分けて考えるべき
ツール● Datadog● Mackerel● Wavefront● Stackdriver● CloudWatch● Prometheus● Elasticsearch● Zabbix● SysdigSaaS IaaSProvidedSelfHosted
監視する対象● Baremetal● VM● Container● Security● Networking● Backend● Frontend● Business KPI･･･他にもいろいろ● Pod● Node● Cluster
みんなの課題• どんなメトリクスを監視すればいいのか○ Kubernetesだけでも膨大な種類のメトリクスが• Kubernetesのクラスタ管理者とアプリ開発者への通知切り分け• ロングタームのメトリクス管理方法・ダウンサンプリング方法
みんなの課題• 外れ値出たときどうするか？○ ここのハンドリング重要○ DatadogやElasticsearchには検出する機能があるが･･･
みんなの課題• Prometheusのメモリ使用量多い• モニタリングのモニタリング• そもそもPrometheus難しい○ relabel_configs○ PromQL■ Prometheusおじさんの発生！
みんなの課題• Dashboardの作り方○ JSONのレビュー大変■ GrafanaならDashboard Shopあるが･･･○ できる限りコード管理したい■ Grafanaでexportするたびに形が変わっててキツい● Jsonnetで生成⇒Grafanaに反映 を試そう• (Prometheusの場合) Prometheus Operator良い○ 最初からいい感じに作り込まれている○ 必要ならば自分で拡張することも出来る
みんなの課題• そもそもDashboardいつ見る？○ 常に見る？○ デプロイ時に見る○ 週次でみる○ 朝会時に見る○ 常に廊下に表示させる
みんなの課題• Monitoring 101は読んでおくべき○ https://www.datadoghq.com/blog/tag/monitoring-101/
Logging
よくある構成対象対象対象CollectorCollectorCollectorAggregatorLogPlatformログ収集集約パースタギングフィルタリング保存インデックス化検索可視化
ツール● Fluentd● Fluentbit● LogStash● Splunk● Elasticsearch● CloudWatch Logging● Stackdriver● S3● GCS● DWHCollector LogPlatform
Logging =
Logging = 課金
みんなの課題• ロギングはカネがかかる！！○ SaaS高い■ ログ量に比例してガンガン金がかかる○ Self Hostedにしてもかなりの運用・インフラコストかかる■ 最終的には監視対象と同じくらいのインフラリソースがログ基盤だけで必要になることも○ 結局は金
みんなの課題• Aggregatorの運用辛すぎ○ とにかくここが死ぬ○ ログの保存量を制御することは出来るが、ログの流量を制御するのは難しい■ アプリ側が大量のログ吐くとすぐ死ぬ■ Collector側で工夫する？⇒収集すべきものとしないものの判断難しい○ パースやフィルタリングなどをやりやすい場所■ でも処理に比例して負荷が増す● 死
みんなの課題• ログの形式バラバラ問題○ ミドルウェアによって吐く形式が違う○ チーム間でもログ形式は往々にして異なる■ チーム間で形式統一を試みた⇒無理だった○ パースせずに生データで保存■ 正規表現地獄○ ログ基盤側でなんとかする■ 負荷で激重になる
みんなの課題• ログとメトリクスの横断検索が難しい問題○ 何か問題が発生したとき、特定の時刻・特定のコンポーネントにおいて、ログとメトリクスを突き合わせて見たい■ ログ基盤とメトリクスが分断していると、横断して調べるのが辛い■ SaaSや商用ソフトウェアだと、この機能を備えているものもある
Alerting
みんなの課題• 閾値の根拠は？• 通知先○ Slack○ Chatwork○ Pagerduty○ メール• オンコール担当は誰か○ アプリのログはアプリ開発者に○ 基盤のログは基盤運用チームに
みんなの課題• 突発的なアラート対応による生産性低下○ Scrum開発しているのに、アラート対応によってスプリント計画がめちゃくちゃに○ 不安定な生活リズムによる生産性の低下○ ベロシティバラバラ
みんなの課題• オンコール先任者・部門を作るか？○ 対象アプリや基盤の知識が無い人がオンコール対応しても、結局そのままエスカレーションされる⇒ コミュニケーションロス• オンコールローテーション○ オンコール対応後の休暇など、制度の確立も必要○ 少人数のチームだとどうする？
みんなの課題• 誤検知・過剰なアラーティングへの対応○ アラートのレベル分け大事• 閾値やアラートレベルの見直しはいつやるか○ 定期的に見直す○ アドホックに対応• アラートルールのコード化はどうやるか
みんなの課題• 通知すべきメトリクスのベストプラクティスはあるか？○ ない！○ そもそも組織によって結構異なる○ アラーティングは、運用しながら育てる意識を持つこと
共通課題
それぞれ共通する課題• コード化・自動化○ Toilは極限まで減らす意識を持つこと○ 監視ルールは育てていくもの• 対応する人・組織・ロール○ できる限り自動化が前提○ 単にコールを受けるだけのロールは悪手になりやすい• OSSか商用製品かManaged Serviceか○ ケースバイケース○ 無理に自前主義に走るのは考え物
Cloud NativeDeep Divehttps://www.meetup.com/ja-JP/Cloud-Native-Deep-Dive/まずはJoin!
CloudNative Days
技術書典６https://techbookfest.org/event/tbf06/circle/56220002チェックリストに追加してね！
おわり
jacopen
hokaccha
smasato
lemiorhan
kojira
mtx2s
peisuke
utam0k
fedepaol
leveragestech
kei_s
aki_iinuma
radkmb
kevinliebholz
schacon
tmm1
quramy
rocio
tammyeverts
vanstee
hursman
reverentgeek
addyosmani
orderedlist