モニタリング
知見まとめ
これまでの学びをまとめてみる
キーワードと前提
以下のものを前提とする
監視対象
Web バックエンドサーバ
特に Ruby on Rails
Kubernetes 上で動く
DB
AWS Aurora PostgreSQL など
監視のためのツール
DataDog
New Relic
Prometheus
なぜ監視が必要か？
安定してユーザにサービスを提供するため
障害を未然に回避するため
(アラートと組み合わせて)障害を素早く検知するため
自分のアプリケーションの使われ方の特性を把握するため
さらなる最適化を施すため
リソースとコードの両方
オーナーシップをより強く持つため
監視をすべき箇所と観点
監視を入れる箇所は基本的に次の4つに分けられる
Resource
何をどのくらい使っているか？
In
何がどのくらい入ってくるのか？要求されたのか？
Out
何がどのくらい出ていくのか？要求するのか？
Time
どのくらいの時間がかかったのか？
この4つの箇所でそれぞれの量を観測する
観点は次の2つがある
ユーザー観点
システム観点
これらは #メトリクス の RED (ユーザの立場) と USE (システムの立場) に影響を受けて分類してみた
これらを組み合わせると次の表になる (WIP)
table: メトリクスの分類
Resource In Out Time
ユーザー観点 1 2 3 4
システム観点 5 6 7 8
これらの第1要素から第8要素までを満たすようにメトリクスを追加して監視すればだいたい問題ないはず
経験上、ユーザ視点のものはさほど多くならず SLI として採用できる
開発者視点のメトリクスが大半を占めると思われる
この表として整理してみて気付いたが、第1要素は殆ど存在しない気がする
例えばユーザがお気に入りできる数、などのドメインに強く結び付いたメトリクスになるだろうか？
そういったデータに触るのはデータ分析チームが主で Dashboard でみたようなものではない気がする
そういう意味でこの分け方は不適切なのかもしれない
更にリトライした回数、アプリケーション内でエラーになった回数、などがどこに属するか不明
レイヤーを分けてやるといい？
application - Time
server - Resource, In, Out, Time
runtime - Resource
Pods/Nodes - Resource
この辺はもう少し考えたほうがいい
具体例
添えてある番号は上記の要素番号
5: Pods/Nodes
CPU使用量
Memory使用量
Network使用量
Pods の数
起動している数
再起動した数
起動しているべき数
5: アプリケーションランタイム (e.g., Ruby VM, ErlangVM, Go runtime)
Memory使用量
GC 回数
スレッド/軽量プロセス/coroutine数
サーバ実装 (e.g., unicorn)
2: 受け付けたリクエスト数
3: 返したエラーの数
4: latency
5: プロセス数
6: 処理待ちのリクエスト数
アプリケーション
8: 計算に掛かった時間
?: 処理失敗した回数
エラーを返すなら3か？
外部サービス
DB (e.g., Aurora PostgreSQL)
DB connection
5: pool のサイズ
5: active な数
5: CPU使用量
8: クエリの実行時間
PubSub (e.g., Cloud Pub/Sub)
6: publishされたメッセージ数
7: subscribeされたメッセージ数
5: 保持しているメッセージ数
8: メッセージの保持されている長さ
Tips
上限値のあるものは合わせて表示する
latency は percentile も表示する (e.g., p99, p90, p50)
時間の計測はだいたいこれ
latency は top list でエンドポイントごとに見ると見やすい
1週間前のグラフも同時に描画するとたまに便利
CPU/Memory 使用量、latency など
リリース後に増加したかとかがたまにわかる
傾向の違うもの/値の差が大きいものが混ざらないように注意すること
値の差が大きいと均されてしまい、正確ではなくなる
具体的には unicorn の master process と worker process は使われ方が違うのでメトリクスは分けること
Lines, Bars, Areas, HeadMap などを適宜使い分ける
実数値なら Lines
e.g., CPU/Memory使用量
整数値なら Bars
e.g., 起動している pods の数
実数値でかつ2, 3種類を重ねたいときは Areas
e.g., Network使用量
整数値でかつ2, 3種類を重ねたいときは Bars
e.g., エンドポイントごとの HTTP レスポンス数
同じ値が複数箇所から送信され、値の範囲もあるときは Head map
e.g., Pods が大量にある時の Memory usage
もしくは percentile もいくつか表示した lines
DataDog も New Relic も単位時間あたりの集計を表示していたりするので見るときは注意する
雰囲気で使っているのであまりわかってないが、最大値を知りたいときは十分にズームして見ること
ズームが足りてないと均された小さい値を使ってしまうことになる