動機
- オブザーバビリティと監視の違いが良くわからないので理解したい
- 関わっているプロダクトの運用を監視の文脈でより良くするためのアイディアが欲しい
https://www.amazon.co.jp/dp/4873118646www.amazon.co.jp
1 章 監視のアンチパターン
アンチパターンの種類
- ツール依存
- 役割としての監視
- チェックボックス監視
- 監視を支えにする
- 手動監視
StatsD とはこの記事がわかりやすかった。 https://tsurezurejapan.hatenablog.com/entry/2022/05/13/221703
Prometheus についてはこの記事がわかりやすかった。 https://qiita.com/Chanmoro/items/ac0eb1bf93760566b338
うちのチームがこれに近い状況に陥っていると思う。システムがダウンした時の根本の原因がわからないし、アラートも誤検知 (というより放置してると解消されるから狼少年化している) が多く無視してしまっている。ノイズが多くて集中できないし、本当にやばい状況の時の予兆が埋もれてしまって後手に回る可能性があるね。
Elasticsearch を使っているのだけど、「動いているのか」の定義が出来ていない。CPU やメモリの使用率を一定期間内で比較して、高すぎていないかや下降傾向にあるかどうかを見ているだけ。「動いているか」の定義が出来ておらず、個々人での判断に委ねてしまっている。Master Node や Data Node を運用目線でどうチェックすればいいのかもあやふや。
ただ Cluster health API を叩いて様子を見る事は出来ているように思える。でも Cluster health API を呼び出した結果、問題があると判断した場合のシミュレーションは一切できていないなぁ。本当に大切なのはそこだと思うんだけど、考慮出来ていない。
MySQLが継続的に CPU を全部を使っていたとしても、レスポンスタイムが許容範囲に収まっていれば何も問題はありません。これこそが、CPU やメモリ使用率のような低レベルなメトリクスではなく、「動いているか」を基準にアラートを送ることが有益である理由です。
前に Elasticsearch に保存しているデータの集計の仕組みを新しく導入する際に負荷検証の結果をアーキに持って行ったけど、OS レベルではなくシステムレベルのメトリクスを取ろうと言われたな。あの話もこれがベースになっているのかも。確かに OS メトリクスだと低レベルすぎて何が起きているのかを把握するのが難しい。こういうどういう観点で何を見ていけばいいのかとかは伝えていかないといけないよな。文章にまとめるだけでは伝えにくいし、出来れば OJT チックにやりたい。
CPU やメモリってアプリケーションのデプロイ直後に見てたりするとコードの異変に気付けたりはするよね。その前段でリソースの消費量がどれほど増えるのかってのをあらかじめ目星つけておかないといけないとは思うけど。
2 章 監視のデザインパターン
監視のデザインパターン
- 組み合わせ可能な監視
- ユーザ視点での監視
- 作るのではなく買う
- 継続的改善
監視サービスの 5 つの要素
- データ収集
- メトリクス
- カウンタ
- ゲージ
- ログ
- メトリクス
- データストレージ
- 可視化
- 分析とレポート
- アラート
サービスレベルアグリーメントを決定し、レポートする場合が挙げられます。
SLAやSLOを定義している場合ではレポートは有効的に使えそう。そのために各処理について計測すべき事がずれないようにしないといけない。SLOと関係ない計測をしても意味がない。
OSレベルのメトリクスで、CPUの使用率が張り付いてもユーザ体験に影響がなければ問題ではないかもしれないって記述があったけど、SLOにも似た事が言えるかな？ユーザ体験に関わる部分で指標を決めていかないといけないのかもしれない。
監視は質問を投げかけるためにある
この言葉の意味があまり理解出来ていない。システムで何が起きているのかを理解するために質問を投げかけるって意味だとは思う。例えばシステムがダウンした時にダッシュボードを見てメトリクスの異常に気付き、何が起きたのかを考えていこうぜ的なことかな？それを果たせるように上記 5 つの要素を構築していこうって事？システム構築に閉じずそのシステムを使った運用フローまで考えてこうって事かなぁ。
アラートが監視の目的でないのはそれはそう。アラートって何かしらの異常に気付くために閾値を設定して、それを越した場合に発砲するもの。そこからシステムに対して何が起きたのか理解を深めていくことは絶対に必要。ただアラートの閾値って未知の問題に対応しずらくねってのがある。
3 章 アラート、オンコール、インシデント管理
監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である
監視の定義。
アラートを削除しチューニングしよう
確かにな～。現在進行形でアラートが狼少年化している。どういった類のアラートが狼少年化しているのか洗い出すところから始めよう。放置して解消しているのであれば閾値を見直せるかもしれないし、解消させるまでの手順を自動化できるかもしれない。そもそもアラートの原因となっている問題を解消できるかもしれない。
閾値もその時点での値しかとっていないので、短時間にディスク使用量が 10->90% に増えた、といった急激な変化に気付けない。
7 章 アプリケーション監視
health endpoint パターン
.NET Aspire とかうまく使えると良いなと思った。
https://www.publickey1.jp/blog/23/net_aspirenet_8.html
ログレベルにrfcがあったの知らんかった。
https://datatracker.ietf.org/doc/html/rfc5424
トラブルシューティングあるいは単なる仕組みの説明時に、合ったらとても便利な情報とは何でしょうか。
う～ん、それ意識してログメッセージを書いているんだけどなんだかしっくりこない。本番環境でデバックするには何を知りたいか、ということを自問しているんだけど、これを広めていけばよいだろうか？ログメッセージとは何のためにあるべきか、どう使っていきたいかってのがあいまいだなぁ。解決したい課題とログメッセージという解決策が上手く被っていない感触がある。
普段使ってる Azure Function はメモリやCPUのメトリックも取ってくれてるから割と楽だな。あとはログメッセージの方針が欲しい。
