# @akiakaba memo: 入門 監視

## 2章 監視のデザインパターン
### 2.1 組み合わせ可能な監視

まとめ
- 監視の要素は、データ収集、データストレージ、可視化、分析とレポート、アラート
- 専門的な小さいツールを組み合わせて疎結合に監視プラットフォームを作ろう

#### データ収集

プル型とプッシュ型
- プル: 監視サービスが監視対象にメトリクス送信の要求をポーリングする
- プッシュ: 監視対象が監視サービスにメトリクスを自発的に送る
プッシュのほうが基本的には使いやすいと考えがちだが筆者はユースケースによると言っている（具体例はまだ出てきてない）
- プル型は監視対象リストを管理しなくてはならない
- 複数のプル型監視サービスを使う場合に同期がとりづらい

@akiakaba 例えば外形監視はプル型といえると思うけど、ユーザ視点の監視には不可欠なように思う。どちらかを選ぶとかではなく、形式上プル型の監視もあるということだろうか。

##### メトリクス
- カウンタ
- ゲージ

##### ログ
- 構造化/非構造化ログ

#### データストレージ

- TSDB: Time Series DB
- RRD
- Whisper(Graphite)

データの間引きについて

メトリクスのストレージ料金はたいしたことないがログは高いことがある
簡単な解決策はない（圧縮とか）

#### 可視化
すべてのメトリクスが1枚のダッシュボードに表示されててもむだ
可視化は1大トピックなので詳しくは他の良い本を読むといい

#### 分析とレポート
SLAは代表的な取り組み
最近SLAって破っても返金しますよというだけのものになってることも多くて、信用できない数字になってるよねという愚痴
例えばuptime100%はありえないけど、存在する
それに依存してるシステムの可用性を計算するのに使えない数字になってしまっている

#### アラート
アラートが監視の目的ではない
アラートがメトリクス収集の目的ではない
監視は疑問を投げかけるためにある

@akiakaba いいアラートって実は難しいよ、ということを言ってるだけ。たぶん次の章で詳しくやる

### 2.2 ユーザ視点での監視

まとめ:
- 監視の初手はユーザが見てアプリケーションが動いているかどうか
- どのコンポーネントが動いていないかが分かること（それも重要で監視する必要があるが）より、サービスに何かが起こってるかどうかの監視が漏れてるほうがまずい

### 2.3 作るのではなく買う

まとめ:
- SaaSを使うより作ったほうがいいのは非常に稀
- 結局SaaSのほうが安い
- メンバーはおそらく監視ツールを設計する専門家ではない
- プロダクトにフォーカスできる
- 順序としても、
- SaaS で監視を運用する（最低5年）
- 本当に必要なら FOSS 等で独自の監視を構築
- 本当に SaaS で足りない場合・セキュリティとコンプライアンス上の理由
- 独自のニーズがあるような一握りの企業は独自の監視を作る

### 2.4 継続的改善

まとめ:
素晴らしい監視は何年もかけて作られるし、素晴らしい監視が1年後にはそうでなくなっている可能性もある。
その時のニーズに合わせ改善を続けること。

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

アラートの難しさ
- メトリクスそのままだと誤ったアラートが多くなる
- 対策として平準化があるが、それも重要なイベントを隠すことがある
- アラートは人間の注意力を削ぐ

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

「アラート」という語は複数の意味で使われている。

1. 緊急対応しないとまずい状態
- e.g. システムがダウンした
2. 注意を要するが、すぐのアクションは必要ない状態
- e.g. バックアップバッチが失敗した
3. 履歴・診断のためのもの

1.だけが事実上のアラート。

#### 適した通知手段
1. SNS/PagerDuty 等のページャ
2. チャットへのメッセージ、チケット作成等（メールも可だが他の手段のほうがいい）
3. ログに残す（通知はいらない）

メールはどれにもあまり向いていない。
どのようなアラートが発生したかのログも取っておくと、その集計により障害の傾向の分析ができるのでおすすめ。

#### 手順書(runbook)

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

- これは何のサービスで、何をするものか
- 誰が責任者か
- どんな依存性を持っているか
- インフラの構成はどのようなものか
- どんなメトリクスやログを送っていて、それらはどういう意味なのか
- どんなアラートが設定されていて、その理由は何なのか

コピペで対応できるような手順書は、アラートを鳴らすのではなく自動復旧するようにすべき。人間の判断を要するときのみ手順書が必要（付録に例がある）。

@akiakaba アラート対応の手順書ってこういう項目が必要なのか

#### アラートのトリガーは固定のしきい値だけがベストではない

「X が Y を超えた」にはあまり意味がない場合がある。「X が一晩で Z 以上増加した」等他の基準も検討する。

@akiakaba 例に出されてるディスク容量逼迫とかは固定値でもあったほうがいいと思うけどね…

@akiakaba Datadog、NewRelic だとアノマリーとかあるよね。あんまりあれにアラート頼りたくないけど。2.か3.用途には便利かも。

#### アラートを減らす

アラート疲れによってチームのパフォーマンスが下がる。
- すべてのアラートは、誰かのアクションが必要なものだけになっているか
- 1ヶ月間のアラート履歴を振り返る。どんなアラートが出ていて、どんなアクションを取ったか
- 自動復旧を実装することで削除できるアラートはないか

#### メンテナンスモードを使おう

作業でアラートを発生させ、特にそれに反応するのが他人なら、仕事を邪魔している。
ただし、広範囲のアラートをメンテにすると、作業中に何かを壊したことにも気づかなくなる可能性がある。その場合はそのほうが影響が大きい。

#### 自動復旧させよう

はい。

### 3.2 オンコール

#### 誤報を修正する

誤報をなくすのは難しいが減らす努力はすべき。
戦略:オンコールの人が前日のアラートを改善できないか検討する。

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

アラートが正しくても、多ければチームは疲弊する。システムの回復力に投資して対応不要にする。
良い戦略が2つある。
1. オンコールの人が（対応中以外の時間で）これに取り組むことにする
2. 前週のオンコールの人が、改善の計画を次のスプリント計画に持ち込む
#### 上手にオンコールローテーションを組む
- 良い例: 1週間交代で、水曜（平日）の日中にシフトが交代するパターン
- 営業日の日中に交代することで、引き継ぎ（注意を要する進行中の事象）や議論ができる
- でかい会社ならFTS
- コミュニケーションコストは高くなるので引き継ぎ方法とかに注意は必要

#### オンコールに対する補償
オンコールは生活に対して良くない影響がある。補償金を出すのは公平。
- オンコールシフトごとに手当を払う
- オンコールシフトの直後に有給休暇を与える

### 3.3 インシデント管理

インシデント管理の手順が決まっているべき。

## 4章 統計入門

### 1. システム運用における統計を学ぶ前に
### 2. 計算が救いの手を差し伸べる
データ収集と、収集したデータの活用を分けて考える。
収集したデータはあとで分析にも使えるので、（使ったからといってその場で）捨てない。

### 3. 統計は魔法ではない
### 4. mean と average
- 平均(mean, average, arithmetic mean):
- 移動平均(moving average):
### 5. 中央値
### 6. 周期性(seasonality)
### 7. 分位数
パーセンタイルが代表的
パーセンタイルの値を更に計算に使うことはできない

### 8. 標準偏差

正規分布に従うデータにしか効果がない。監視で扱うデータのほとんどは正規分布に従わない。
なぜ計算に合わないか悩むより、標準偏差の適用を諦めたほうがいい。

### 9. まとめ
### キーワード
- フラッピング: しきい値の上下をいったりきたり
- collectd

## 5章 ビジネスを監視する

### 1. ビジネス KPI

### 2. 2つの事例
- Yelp / Reddit
- いずれもユーザ/顧客のエンゲージメントを測定している

### 3. ビジネス KPI を技術指標に結びつける

ログインの失敗を追う例。
[？] ログインを追って成功と失敗を観測するのより良い（障害に強い）と主張されているが、何を言ってるのか理解できなかった。
=> ログインを負っているバックエンドサービスのログで追うのではなく、そのサービスを呼び出す側で追うのを検討するという話か？

### 4. 自分のアプリケーションにそんなメトリクスはないという時は
今送信していないなら送信するように修正する。

### 5. 会社のビジネス KPI を見つける

プロダクトマネージャと話す。プロダクトマネージャは顧客がなにを必要としているか知っている人。エンジニア以外と話すことでエンジニアリングの枠にとらわれることを防げる。
定番の質問
- 会社に入りたての人がアプリケーションが動いているかどうかを確認する方法はなんですか？
- アプリケーションのKPIはなんですか？

## 6章 フロントエンド監視

### 1. 遅いアプリケーションのコスト

ページのパフォーマンスとビジネス指標（PV、CV等）を関連付ける例が提示されている。
関係がある場合にもパフォーマンスに投資しないのは誤った判断という主張。

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

- リアルユーザ監視(real user monitoring: RUM)
- 監視データとして実際のユーザトラフィックを使うもの
- フロントエンド監視ではこちらが中心になる
- シンセティック監視(synthetic monitoring)
- 監視データを得るため、いろいろなテスト環境下で偽のリクエストを生成して計測

### 3. DOM

JS をたくさんダウンロードさせるページは遅い。

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

- Navigation Timing API
- Speed Index

### 4. ロギング

一般的なロギングインフラは普及していない。専門の SaaS を使う。
https://duckduckgo.com/?t=ffab&q=exception+tracking+saas

### 5. シンセティック監視

実際のユーザのデータを使うのではなく、例えば curl でサイトが動いてるか確認するようなこと。
- WebpageTest 等

### 6. まとめ

- RUM でページのロード時間を監視する
- JS の例外を監視する
- ロード時間を CI で監視し続け、許容時間内に収める

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

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

- APM
- StatsD: https://github.com/statsd/statsd

### 2. ビルドとリリースのパイプラインの監視

- https://www.etsy.com/codeascraft/measure-anything-measure-everything

### 3. health エンドポイントパターン

/health。push では得られないメリットがある。ロードバランサ・サービスディスカバリによるヘルスチェック。

セキュリティ: ユーザにアクセスされたくない。IPで弾く

### 4. アプリケーションロギング

- メトリクスorログ: 単にログは高い
- 何をログに出すべきか:
- 何かがおかしいときに起きる質問はなにか考える: トラブルシュートや説明に必要な情報
- アプリケーションの振る舞いを考える: 理解していないシステムのログを設計するのは無理
- ログレベルはおかしくなってから変更しても遅いため、↑を解決しない
- アプリケーションはログをネットワークではなくディスクに書き込み、外部にデータを送るサービスは別にする

### 5. サーバレスまたは FaaS
### 6. マイクロサービスアーキテクチャを監視する

分散トレーシング。リクエストごとにリクエストIDをつける。
分散トレーシングの運用コストは高いので、メトリクスとログで効果的にアプリケーションを計測するほうが良い結果を得られる。
分散トレーシングのツールは継続的に改善されてきていて、コストは下がっていくかも。

### 7. まとめ

## 8章 サーバ監視

### 1. OS の標準的なメトリクス

アラートには向かないが、トラブルシュートの際には役に立つ。

- CPU: /proc/stat に由来 -> top コマンド
- メモリ: /proc/meminfo に由来 -> free コマンド
- システムログの killed process も監視しておくと良い
- ネットワーク: /proc/net/dev に由来 -> ifconfig や ip コマンド
- ディスク: /proc/diskstats に由来
- ロードアベレージ: /proc/loadavg に由来 -> uptime コマンド
- 高いこと自体は問題ではないがなにかに気づける可能性がある
- https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

### 2. SSL 証明書

期限

### 3. SNMP

- サーバ監視にはいらない（他のツールのほうがいい）
- ネットワーク機器の監視には依然必要

### 4. Web サーバ

- rps
- HTTP ステータスコード
- （コネクション数）

### 5. データベースサーバ

- qps
- スロークエリ
- IOPS

### 6. ロードバランサ

フロントエンド側とバックエンド側両方を見る必要がある。

### 7. メッセージキュー

- キューの長さ
- 消費率

### 8. キャッシュ

- キャッシュから追い出されたアイテム数
- ヒット／ミス比率

自分はレイテンシも見てた

### 9. DNS

（自前で運用してなければ不要）
- ゾーン転送
- qps

### 10. NTP

- ntpstat
- どれくらいの頻度だと良いのか、謎
- サーバ側: 自前で運用してなければ不要

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

- DHCP
- SMTP

### 12. スケジュールジョブの監視

スケジュールされたタスクや cron が動いたかの監視。
- ```run-backup.sh 2>&1 backup.log || echo "Job failed" > backup.log```
- デッドマン装置(dead man's switch)

### 13. ロギング

- 収集
- syslog の扱い
- UDP vs TCP
- 「最後の言葉」はほとんどの環境で有益ではなく、漏れがない TCP のほうがいい
- 保存
- 分析
- HTTP レスポンス
- sudo の使用
- SSH ログイン
- cron ジョブの結果
- MySQL や PostgreSQL のスロークエリ

### 14. まとめ

標準的OSメトリクスは、アラートには向かないがトラブルシュートの役に立つ。

## 9章 ネットワーク監視

### 1. SNMP の辛さ

ネットワークパフォーマンス
- 帯域幅
- スループット
- レイテンシ
- エラー
- ジッタ

アップリンクとサーバに使われているインタフェイスを監視してアラートを送るべき。
アグリゲーションされたポートも監視すると良い。

### 2. 構成管理

デバイスに対する設定の変更を追跡すべき。

### 3. 音声と映像

- レイテンシ
- ジッタ
- パケットロス
- コーデック
- ネットワークにわたって同じはずだが、そうでない場合はパフォーマンス問題が起きる

### 4. ルーティング

（わかってない）

### 5. スパニングツリープロトコル(STP)

（わかってない）

### 6. シャーシ

（わかってない）
ネットワークデバイスにとっての、筐体（マシンのケースとかマザボとか）？

### 7. フロー監視

（わかってない）

### 8. キャパシティプランニング

逆算 or 予測

## 10章 セキュリティ監視

- 脅威とリスクのレベルを見積もる
- 100ドル守るために1000ドルかける意味はない
- 仕事のしやすさを損ないすぎない

### 1. 監視とコンプライアンス

監視で実装するのが妥当そう。

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

auditd
auditd のログの取り込みには rsyslog ではなく audisp-remote を使うと、rsyslog を無効化する攻撃に対して一歩踏み込んだ保護になる。

以下は監視したほうがいい。
- ssh ログインの成功
- sudo の成功と失敗

auditd の収集・分析 SaaS もある: CloudPassage, Threat Stack

### 3. ホスト型侵入検知システム (HIDS)

用語
- HIDS: ホスト上の異常を検知するシステム
- rootkit

### 4. rkhunter

ルートキット検知に使われているツール。

### 5. ネットワーク検知システム (NIDS)

HIDS がホスト上の以上を検知するのに対してネットワークの以上を検知する。ネットワークタップをネットワーク内に配置して生のトラフィックを確認することで動作する。

### 6. まとめ

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

### 1. ビジネス KPI
### 2. フロントエンド監視
### 3. アプリケーションとサーバの監視
### 4. セキュリティ監視
### 5. アラート
### 6. まとめ