アルパカログ

プログラミングとエンジニアリングマネジメントがメインです。時々エモいのも書きます。

【読書メモ】入門監視 / 知っておこう!監視のアンチパターン

監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。

「入門監視」は、監視の世界を基礎からわかりやすく説明してくれます。

これまでオンコール担当すらしたことがないくらい、監視に関わりがなかった私が、初心者なりに「入門監視」で勉強になった部分をまとめました。

「え、そんなことも知らなかったの?」と多分に思われるかもしれませんが、それくらいこの本が丁寧に書かれていると解釈していただければ幸いです。

www.oreilly.co.jp


1章 監視のアンチパターン

  • 監視するだけでは壊れたものは直せない
  • ツールに依存しても監視の仕組みはよくならない
  • 監視ツールに銀の弾丸はない

監視ツールによくある間違い

成功したチームや会社は、ツールや手順によって成功したのだという間違った考え方によって、そういったチームや会社が使っているツールや手順を採用して、同じ方法で自分たちのチームを成功させようとしてしまうのです。

観察者効果は気にしない

観察者効果とは、監視する行為が監視対象を変化させてしまうこと。現代のシステムは負荷が増えても処理できるため観察者効果は気にしなくて良い。

リソース使用率が多いことが問題ではない

サービスによっては元々リソースをたくさん使うものもあるが問題ない。例えば、MySQLが継続的にCPU全部を使っていたとしても、レスポンスタイムが許容範囲に収まっていれば問題ないということ。

メトリクスの取得頻度

5分に1回しかメトリクスを取得しないのは、実質的に何も見ていないのと変わらない。最低でも60秒に1回メトリクスを取得する

2章 監視のデザインパターン

  • 監視サービスは5つの要素からなる。
    • データ収集
    • データストレージ
    • 可視化
    • 分析とレポート
    • アラート
  • ユーザーがアプリケーションとやりとりするところをまず監視しよう
  • 監視の仕組みは、可能な限り買うことを選ぼう

データ収集

データ収集の主な方法はプッシュとプルの2つ。 プッシュ型は冗長性に優れていて可用性の高い構成がとれる。

メトリクス
  • カウンタ(Counter)
    • 増加していくメトリクス
  • ゲージ(Gauge)
    • ある時点の値を表すメトリクス
ログ

ログには構造化ログと非構造化ログの2つのタイプがある。

非構造化ログは順序が意味を持つ場合がよくあり、ログの量が少なく、grepやtailより複雑なツールを使う必要もなく、人間が読むだけなら、非構造化ログのままでよい。

データストレージ

時系列データは、通常は時系列データベース(TSDB、Time Series Database)に保存される。

よく使われているTSDBには、RRD(Round Robin Database)やGraphiteのWhisperがある。

TSDBの多くでは、一定期間後にデータの「間引き」(rollup)や「有効期限切れ」(ageout)が発生し、古くなったデータが1つのデータポイントにまとめられる。

可視化

GrafanaSmashingのようなダッシュボード製品やフレームワークが代表的。

時系列データの最も一般的な可視化方法は、折れ線グラフ(line graph、strip chartともいう)である。過程やトレンドといった情報が含まれていないという理由から、円グラフは使うべきではない。

分析とレポート

可用性は、ツーナイン(99%)やフォーナイン(99.99%)のように9の数で表す。

アラート

監視はアラートするためのものではない。アラートは結果の1つの形でしかないということ。

まずどこを監視するか

ユーザがアプリケーションとやり取りをするところにまず監視を追加すべきである。

HTTPレスポンスコード(特にHTTP 5xx番台)リクエスト時間(レイテンシとも言う)の2つが効果的である。

3章 アラート、オンコール、インシデント管理

  • アラートには、対象サービスの手順書へのリンクを入れよう
  • 誰かにアラートを送る前に自動復旧を試そう
  • ソフトウェアエンジニアもオンコールのローテーションに入れよう

アラートに手順書へのリンクを入れる

アラートに対象サービスの手順書へのリンクを入れておくことで、誰かがアラートに応答したとき、何が起こっているか、アラートがどんな意味を持つのかなどを理解できる。

アラートを送る前に自動復旧を試す

うるさいアラートは監視システムを信用無くし、無視されてしまうようになる。そのアラートが本当に必要なのか、必要であればまず自動復旧できないかを検討する。

オンコール担当

オンコール担当の役割に、前日に送られたすべてのアラートの一覧を作り、各アラートはどのように改善できるか、あるいはアラートを削除してしまえないかどうかの検討を追加すると良い。

可能であればFollow-the-Sun(FTS)ローテーション(タイムゾーンごとのローテーション分割)も検討すると良い。

シフト間隔をどのくらいにすべきか

通常のシフトでは1人3週間あけるのがおすすめ。

ソフトウェアエンジニアもオンコールのローテーションに入れる

ソフトウェアエンジニアリングにおける「丸投げ」を避けるため強く推奨する。

4章 統計入門

  • フラッピングの検出はよくないアラートを隠すだけ
  • モダンな監視スタックの重要な原則の1つは、監視サービスが送ったメトリクスを捨てないこと

移動平均(moving average)

集合のすべてを使って平均を算出するのではなく、最近取得したデータポイント群で平均を計算する。スパイクの多いグラフを平滑化する効果がある。

パーセンタイル

帯域幅に対する課金やレイテンシのレポートによく使われる。帯域幅に対する課金にパーセンタイルを用いるのは、トラフィックはバーストする場合があるのは分かっているので、95パーセンタイルに対して課金する方が公平だという考え方から。

パーセンタイル値には含まれていないデータがあるので、パーセンタイルは平均できない。

標準偏差の落とし穴

正規分布している(normally distributed)データセットに対してしか、期待するような結果は出ない。

6章 フロントエンド監視

  • フロントエンドのパフォーマンス監視のゴールは、動き続けることではなく、素早くロードされること

フロントエンド監視には、リアルユーザ監視(real user monitoring、RUM)とシンセティック監視(synthetic monitoring)の2つのアプローチがある。

Google AnalyticsはRUMの一種で、RUMとは監視のデータとして実際のユーザトラフィックを使うもののこと。

7章 アプリケーション監視

  • /healthエンドポイントパターンは良い

8章 サーバ監視

メモリ

システムにメモリを追加すべきかどうかを判断する時には、free コマンドを使い -/+buffers/cache: 行を確認する。

OOMKillerの呼び出しはシステムログを killed process で grep する。

ディスク

iostat-x コマンド

  • iowait
    • ディスクが処理を終えるのを待つためにCPUがアイドル状態だった時間を表す。
  • awaitと%util
    • ディスクのI/O待ち時間と使用率

iostat コマンド(xオプションなし)

  • tps(transfers per second、I/O per second(IOPS)とも言う)
    • データベースサーバなどディスクを使用するあらゆるサービスにおいて重要なメトリクス

データの転送能力を増強(例えばディスクを増やす)する必要があるかを判断したり、一般的なパフォーマンス問題を特定するのに使われる。

ロードアベレージ

ロードの数値はシステムパフォーマンスを表しているわけではない。

しかし、ロードアベレージは代理指標(proxy metric)として役立つ。つまり、異常に高いロードアベレージは、他に問題があるかもしれないということ。

SNMP

SNMPをサーバ監視に使うのはやめよう。collectdTelegrafDiamondといったプッシュベースのツールを使おう。

Webサーバ

秒間リクエスト数(request per second[req/sec])を監視する。

コネクションにはキープアライブ(keep alives)があるため、コネクション数=リクエスト数ではない。

データベースサーバ

コネクション数を監視する。MySQLではクライアントのコネクションをスレッドと表現している。

秒間クエリ数(queries per second、qps)やスロークエリ、IOPSも重要。データベースは大量の読み書きをすることから、普通はIOの速さで制約を受けるため。

メッセージキュー

メッセージキューはpub-subシステムと言われる。キューの長さ(queue length)と消費率(consumption rate)を監視する。

キューの長さは、キューの中で取り出されるのを待っているメッセージの数で、消費率は、キューから取り出され処理されたメッセージの比率。

キャッシュ

キャッシュから追い出されたアイテム数(evicted items)とヒット・ミス比率(hit/miss ratio、またはキャッシュヒット率[cache-hitratio])を監視する。

9章 ネットワーク監視

ネットワークパフォーマンスは、帯域幅(bandwidth)、スループット(throughput)、レイテンシ(latency)、エラー(errors)、ジッタ(jitter)といった要素に分けられる。

帯域幅

ある接続から一度に送れる理論上の最大情報量。ネットワークリンクのキャパシティ。

スループット

ネットワークリンクの実際のパフォーマンス。

プロトコルと送信のオーバーヘッドにより、スループットはリンクの帯域幅より小さくなる。

パケットのドロップ(drops)とオーバラン(overruns)は、ネットワークリンクの帯域がいっぱいになっている可能性を表している。

レイテンシ

パケットがネットワークリンクを通じてやり取りされるのにかかる時間。

ジッタ

あるメトリックの、通常の測定値からの狂いのことで、ネットワークの世界ではジッタはレイテンシに関して使われることが多い。