入門監視 ―モダンなモニタリングのためのデザインパターン

https://images-fe.ssl-images-amazon.com/images/I/41Jlj3e0CDL._SY291_BO1,204,203,200_QL40_ML2_.jpg https://www.amazon.co.jp/%E5%85%A5%E9%96%80-%E7%9B%A3%E8%A6%96-%E2%80%95%E3%83%A2%E3%83%80%E3%83%B3%E3%81%AA%E3%83%A2%E3%83%8B%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3-Mike-Julian/dp/4873118646/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=%E7%9B%A3%E8%A6%96%E5%85%A5%E9%96%80&qid=1637226141&sr=8-1

(著) MikeJulian (翻訳) 松浦隼人

ISBN:4873118646

あなたのシステムはきちんと動いていると言えますか？

本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。

前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。

監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。

日本語版では、松木雅幸（@songmu）氏による監視SaaSの導入や活用方法を付録として収録しています。

はじめに

監視は進化している

クラウド

マイクロサービス

第Ⅰ部　監視の原則

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

「いつもやっているから」で済まさない

知識不足、FUD をそのままにしない

1.1　アンチパターン1：ツール依存

銀の弾丸はない

1.1.1　監視とは複雑な問題をひとくくりにしたもの

監視対象は様々

1 つのツールでは解決できない

観測者効果を気にしない

1.1.2　カーゴ・カルトなツールを避ける

ツールや手順は成功によって作られたもの

真似しても大きな効果はない

ツールは注意深く選ぶ

1.1.3　自分でツールを作らなければならない時もある

小さく特化したツールを作る

1.1.4　「一目で分かる」は迷信

監視は複雑な問題である

1 つのダッシュボードに詰め込むのは非効率

1.2　アンチパターン2：役割としての監視

チームがある程度のレベルを理解する

サービスのパフォーマンスのために重要

1.3　アンチパターン3：チェックボックス監視

指定項目を監視しても、ダウンした理由がわからない

誤検知が多い

メトリクス取得感覚が 5m 以上

メトリクス履歴がない

1.3.1　「動いている」とはどういう意味か。「動いている」かどうかを監視しよう

Health Check

1.3.2　アラートに関しては、OSのメトリクスはあまり意味がない

レスポンスタイムやパフォーマンスが許容範囲なら問題ない

1.3.3　メトリクスをもっと高頻度で取得しよう

最低でも 60s

1.4　アンチパターン4：監視を支えにする

問題の通知に長けている

1.5　アンチパターン5：手動設定

監視設定は全て自動化する

1.6　まとめ

ツール依存しても、監視の仕組みは良くならない

監視は全員がやるべき

役割ではない

監視だけでは修復できない

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

2.1　デザインパターン1：組み合わせ可能な監視

ツールを組み合わせる

柔軟性

問題点が少ない

2.1.1　監視サービスのコンポーネント

データ収集

Pull 型

スケールしにくい

Push 型

冗長性、高可用性

メトリクス

カウンタ

ゲージ

ログ

データストレージ

圧縮

保存期間

可視化

自分の環境で最適に動く仕組みを作ることが監視の目的

円グラフは使わない

分析とレポート

SLA

ダウンタイムは必ず発生する

アラート

監視は質問を投げるためにある

2.2　デザインパターン2：ユーザ視点での監視

エンドユーザーにどのような影響があるのかを自問自答する

2.3　デザインパターン3：作るのではなく買う

まずは SaaS ソリューションを使う

2.3.1　安いから

人件費が高くつく

SaaS は高いと言われているが、十分比較すること

2.3.2　あなたは（おそらく）監視ツールを設計する専門家ではないから

専門分野は SaaS に任せる

2.3.3　SaaSを使うとプロダクトにフォーカスできるから

2.3.4　実際のところSaaSの方がよいから

2.4　デザインパターン4：継続的改善

世界レベルの仕組みは長い年月をかけて作られる

2.5　まとめ

組み合わせ可能な監視

ユーザー目線の監視

買うことを選ぶ

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

監視はチェックし続ける行為

3.1　どうしたらアラートをよくできるか

叩き起こすアラート

FYI のアラート

3.1.1　アラートにメールを使うのをやめよう

アラートの種類

アクションが必要なアラート

SMS, PagerDuty

注意が必要なアラート

チャット

履歴や診断のためのアラート

ログ

3.1.2　手順書を書こう

手順書（runbook）

アラートが来た時に迅速に対応できるようにするためのもの

記載内容

サービスの What, How

責任者

依存性

インフラ構成

メトリクスやログの種類

アラート設定内容と理由

3.1.3　固定の閾値を決めることだけが方法ではない

増加率も重要な指標の一つ

根本原因を解明する手助けとなる

3.1.4　アラートを削除し、チューニングしよう

アラート疲れを引き起こす

ノイズを減らす

3.1.5　メンテナンス期間を使おう

避けられないアラートはメンテナンス期間を使う

3.1.6　まずは自動復旧を試そう

自動復旧で解決できないならアラートを送る

3.2　オンコール

オンコールを廃止するための仕組み

3.2.1　誤報を修正する

false alerm は必ず含まれる

100% 正確なアラートを実現するのは難しい

前日のアラート一覧を作り、見直しながら改善する

3.2.2　無用の場当たり的対応を減らす

非対応中の時間は、回復や安定に対してオンコール担当が取り組む

オンコール対応した情報をもとに改善の計画を組む

3.2.3　上手にオンコールローテーションを組む

ローテーションを組む

補償を出す

3.3　インシデント管理

組織の上下関係と同じがいいとは限らない

3.4　振り返り

内部の問題を解決する

振り返りを非難しない

3.5　まとめ

アラートはメールで送らない

手順書を書く

すべてのアラートはシンプルな閾値で決まらない

常にアラートを見直す

メンテナンスウィンドウを使う

自動復旧を試みる

4章　統計入門

4.1　システム運用における統計を学ぶ前に

フラッピング検出

よくないアラートを隠すだけのもの

4.2　計算が救いの手を差し伸べる

メトリクスを捨てないこと

統計が問題の発見に役立つ

4.3　統計は魔法ではない

統計の分野で大きな作業が必要

4.4　meanとaverage

mean

一般的には average

専門的には arthimetic mean

移動平均

平滑なグラフになる

4.5　中央値

データセットの真ん中の値

4.6　周期性

seasonality

データポイントがパターンを繰り返す

4.7　分位数

quantile

percentile

課金やレイテンシーのレポートに使われる

ある程度のデータを捨てる

平均できない

4.8　標準偏差

standard deviation

平均からの距離

4.9　まとめ

平均値は多くのデータセットに適用できる

中央値もデータセットによっては便利

周期性はトラフィックログから見つけられる

パーセンタイルでデータの大部分を理解する

標準偏差は適用できないことが多い

データセットを考慮する点

データポイントの偏り

外れ値の発生

上限と下限

第Ⅱ部　監視戦略

5章　ビジネスを監視する

ビジネス KPI を調べながら、エンジニアの専門知識を使う

5.1　ビジネスKPI

16 More Startup Metrics | Andreessen Horowitz

5.2　2つの事例

メトリクスを測定することでビジネスの質問に答える

5.2.1　Yelp

5.2.2　Reddit

5.3　ビジネスKPIを技術指標に結び付ける

ユーザーを個別に分析する必要はない

失敗率とレイテンシー

5.4　自分のアプリケーションにそんなメトリクスはないという時は

デザインで決まっている

アプリケーションがなければ作る

5.5　会社のビジネスKPIを見つける

人と話すこと

プロダクトマネージャー

顧客に必要なものを理解している

高いレベルで問題を理解している

ソフトウェアエンジニア

問題点を発見できる

5.6　まとめ

ビジネス KPI は重要なメトリクス

メトリクスを特定して追跡する

技術指標に結びつける

6章　フロントエンド監視

素早くロードされること

6.1　遅いアプリケーションのコスト

ページロードは 4s 以下を目指す

6.2　フロントエンド監視の2つのアプローチ

リアルユーザー監視（RUM）

Google Analytics

シンセティック監視

6.3　DOM

スクリプトが多いとパフォーマンスが悪化する

6.3.1　フロントエンドパフォーマンスのメトリクス

Navigation Timing API

Speed Index

6.3.2　素晴らしい！　でもどうやったらいいの？

SaaS がおすすめ

Google Analytics

6.4　ロギング

SaaS

6.5　シンセティック監視

WebPageTest

6.6　まとめ

実ユーザーのロード時間を監視する

JS の例外を監視する

CI でロード時間が許容範囲に収まるまで監視する

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

アプリケーションがブラックボックスになりがち

7.1　メトリクスでアプリケーションを計測する

APM

7.1.1　内部ではどのように動いているのか

StatsD

7.2　ビルドとリリースのパイプラインの監視

deployment のメタ情報が役に立つ

7.3　healthエンドポイントパターン

アプリケーションの中で閉じる

HTTP ステータスコードを使用する

200

503

7.4　アプリケーションロギング

JSON 形式

アプリケーションの振る舞いを教えてくれる

7.4.1　メトリクスにすべきか、ログにすべきか

ユースケースに合わせる

7.4.2　何のログを取るべきか

アプリケーションの振る舞いを考える

トラブルシューティングのためのログ

7.4.3　ディスクに書くべきか、ネットワーク越しに送るべきか

ネットワーク

トラっフィックがボトルネックになり得る

7.5　サーバレスまたはFunction-as-a-Service

StatsD で監視する

7.6　マイクロサービスアーキテクチャを監視する

分散トレーシング

リクエストを Tracing する

7.7　まとめ

メトリクスとログの監視

パフォーマンスを把握

トラブルシューティングに役立てる

8章　サーバ監視

8.1　OSの標準的なメトリクス

標準的なメトリクス

依存しすぎない

弱いシグナルの監視から始めることになる

記録のみでアラートは不要

どのように使うかを考える

8.1.1　CPU

/proc/stat

top コマンド

8.1.2　メモリ

/proc/meminfo

free コマンド

buffers: 最近アクセスされたファイルシステムメタデータ

cached: 最近アクセスされたファイルコンテンツ

OOMKiller

killed process で grep する

8.1.3　ネットワーク

/proc/net/dev

インターフェース

in/out

オクテット数

エラー数

ドロップ数

8.1.4　ディスク

/proc/diskstats

iostat

8.1.5　ロードアベレージ

/proc/loadavg

代理指標

8.2　SSL証明書

通知メールに気づく仕組みを作る

管理システム宛に変更など

外部のサイト監視ツールでチェックする

Pingdom

StatusCake

cron でスクリプトを実行など自動化する

8.3　SNMP

使わないこと

セキュアではない

スケールが難しい

機能追加にエージェントを拡張する必要がある

ポーリングする集中型の仕組みが必要

代替手段がいくらでもある

collectd

Telegraf

Diamond

8.4　Webサーバ

秒間リクエスト数（request per second: req/sec）

ステータスコードの監視

rfc7231

8.5　データベースサーバ

コネクション数

MySQL はスレッドと表現される

秒間クエリ数（query per second: qps）

8.6　ロードバランサ

/health エンドポイント

キューの監視

キューの長さ

消費率

8.8　キャッシュ

キャッシュから追い出されたアイテム数

キャッシュ容量が足りているか監視する

ヒット・ミス比率

8.9　DNS

自前で運用している場合は監視する

ゾーン転送

秒間クエリ数

8.10　NTP

自前で運用している場合は監視する

ntpstat

8.11　それ以外の企業インフラにおける監視

8.11.1　DHCP

リース

8.11.2　SMTP

送信待ち

8.12　スケジュールジョブの監視

6 Best Cron Job Monitoring to Schedule Your Tasks Efficiently

Cron Job Monitoring - Healthchecks.io

8.13　ロギング

8.13.1　収集

TCP

8.13.2　保存

syslog におkらない

8.13.3　分析

Splunk

8.14　まとめ

OS メトリクスはアラートに適さない

効果的な使い方をする

サーバー観点からのロギング

9章　ネットワーク監視

ネットワークを正しく監視する

9.1　SNMPのつらさ

SNMP を使わなければならない

9.1.1　SNMPとは

ネットワークデバイス監視の標準プロトコル

9.1.2　SNMPの仕組み

UDP

table: ポートの役割

161 ポーリング

162 トラップ

9.1.3　セキュリティについて

9.1.4　SNMPの使い方

9.1.5　インタフェイスのメトリクス

table: メトリクス

bandwidth 帯域幅

throughput スループット

latency レイテンシー

errors エラー

9.1.6　インタフェイスとログ

9.1.7　SNMPに関するまとめ

9.2　構成管理

9.3　音声と映像

table: メトリクス

レイテンシ

ジッタ

パケットロス

9.4　ルーティング

ダイナミックルーティングプロトコルの監視

9.5　スパニングツリープロトコル（STP）

9.6　シャーシ

9.6.1　CPUとメモリ

9.6.2　ハードウェア

9.7　フロー監視

sFlow

IPFIX

NetFlow

J-Flow

9.8　キャパシティプランニング

9.8.1　逆算する

9.8.2　予測する

9.9　まとめ

10章　セキュリティ監視

10.1　監視とコンプライアンス

10.2　ユーザ、コマンド、ファイルシステムの監査

10.2.1　auditdのセットアップ

10.2.2　auditdとリモートログ

10.3　ホスト型侵入検知システム（HIDS）

10.4　rkhunter

10.5　ネットワーク侵入検知システム（NIDS）

10.6　まとめ

11章　監視アセスメントの実行

11.1　ビジネスKPI

11.2　フロントエンド監視

11.3　アプリケーションとサーバの監視

11.4　セキュリティ監視

11.5　アラート

11.6　まとめ

付録A　手順書の例：Demo.App

A.1　Demo App

A.2　メタデータ

A.3　エスカレーション手順

A.4　外部依存

A.5　内部依存

A.6　技術スタック

A.7　メトリクスとログ

A.8　アラート

付録B　可用性表

付録C　実践.監視SaaS

C.1　筆者と監視SaaS

C.2　監視SaaSの利点

C.3　監視SaaSは信用できるのか

C.3.1　監視SaaSビジネスそのものに対する信頼性

C.3.2　事業の継続性について

C.3.3　サービス品質について

C.3.4　悪意はないか

C.4　監視SaaSの選定時に考えること

C.4.1　課題を見つける

C.4.2　機能要件を精査する

C.4.3　組み合わせて使う

C.4.4　運用をサービスに合わせる

C.4.5　ハッカビリティを備えているか

C.4.6　外部の力を活用できるか

C.5　監視SaaSを導入する

C.5.1　監視エージェントのインストール

C.5.2　監視エージェントが収集するメトリクス

C.5.3　シンセティック監視のすすめ

C.6　監視SaaSを活用する

C.6.1　テスト駆動開発と監視

C.6.2　自分で監視を作る

C.6.3　監視を育てる

C.6.4　自動復旧のためのアイデア

C.7　監視SaaSのこれから

C.7.1　監視パラダイムの変遷

C.7.2　機械学習と異常検知

C.8　まとめ

訳者あとがき

索引

#book