## 3章

- 3.1 どうしたらアラートをよくできるか
- 手順を作るは重要
- 無視しないことが重要で、機械的に意思決定できる方法の1つ
- インフラの構成はどうなっているかの部分は設計と重複する箇所がでる可能性が高い。実態と設計と手順の乖離をなくす良い方法はなんだろう？
- 変化量は重要、ただし直感的ではないので設定の勘所が難しい印象
- => 機械学習で検出する仕組みがある(アノマリー)
- 3.2 オンコール
- オンコールをおける時点である程度の規模の組織。ベンチャーとかは大変そう
- 例として具体的な数字として、週に2,3回のインシデントなら4人、バックアップ+4人の合計8人など値が見えてイメージができた
- 3.3 インシデント管理
- 3.4 振り返り
- 誰か(人・チーム・組織)を非難しない文化は重要
- 非難があると、隠したり、軽視するようになる
- 個人の場合はチームの問題など1段上のグループに抽象化できるが、誰が組織になったとき抽象化できなくなる
- 組織ぐらいまで抽象化できればOKか？
- ベンダーいじめが起きる構造を避けられなさそう
- => 透明性が原則ではありものの、利害関係が一致しているなかでの振り返りにしないと発散してしまう

## 4章 統計入門

### 4.1 システム運用における統計を学ぶ前に
### 4.2 計算が救いの手を差し伸べる

- フラッピングの検出便利そうな反面、検知が遅れる原因になる
- ~~これが出来るようになったのは~~ 抑制が不要になったのは、ストレージが安価になり時系列のデータベースに起こったことをすべて記録できるようになって意識が変わってきたというのもありそう

### 4.8 標準偏差

- 母数が正規分布に従うケースは現実の世界(システム)ではどのぐらいあるのだろう
- 「標準偏差を使うのを諦めるほうが幸せになれるかもしれません」とあるので無いのかも

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

### 5.1 ビジネスKPI
### 5.2 2つの事例
### 5.3 ビジネスKPIを技術指標に結びつける

ビジネスの立場からある指標を見たいときに、技術指標と紐づけることで見てくるものがあることが書いてある。

直接観測(取る)ことができないとき、代替としてこの指標が使えるのではという、ある意味妥協とも言える気がする。

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

5.3までの代替でメトリクスを見る方法を説明していたが、それでも取れないときは、あらかじめ設計・実装に盛り込んだほうが良いということが書かれてる。

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

- フロントエンドの監視ゴールは、素早くロードされること

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

- 業務向けや開発者向けなど特定・特化のウェブアプリケーションの場合、より後回しなイメージ
- AWSマネジメントコンソールのログインとか...

### 6.2 フロントエンド監視の2つのアプローチ
### 6.3 DOM
### 6.3.1 フロントエンドパフォーマンスのメトリクス
### 6.3.2 素晴らしい！でもどうやったらいいの？

- ほとんど コンテンツのロード時間とJavaScriptとの戦い
- Navigation Timeing APIを使って監視
- より詳細に視覚的観点でメトリクスを取る場合 Speed Index などがある

### 6.4 ロギング

- `console` にが限界があるので、ライブラリの導入やSaaSプロダクトを使うと選択肢が広がる

### 6.5 シンセティック監視

- 能動的にかつ定期的にパフォーマンスを最適化しないと時間とともに悪化する
- 大体のシステムはそう
- リファクタリングや引き算をする重要度を判断をするためにも、監視できる状態にしておくことが望ましそう

### 6.6 まとめ

- CIシステムから計測し続け、ロード時間が許容内に収まるようにする
- チームが CI、自動でテストすることに抵抗感がないことが前提
- CIは労力が必要

## 7章

### 7.1 メトリクスでアプリケーション監視

- StatsD はアプリケーションにライブラリとして読み込み、指標となる値を設定・加算していく使い方をする

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

- (自分は)最近はクラウドで CI/CD をすることが殆どなので勝手についてくるので意識してなかった。確かにあるべき

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

- モノリシックで大きいのか、小さいのか、マイクルサービスかで見たいパターンが変わる
- DBのコネクションのヘルスチェックをしているサンプルが提示されていた。DBがサービスとしてくっついている場合(分離されていない場合)アプリケーションのヘルスチェックエンドポイントからチェックすることがある
- 認証情報をアプリケーションのものを流用できるという点では良さそう
- 反面ビジネスロジックに関係ないコードが混在するので、監視するポイントが増えると、付加価値を生まない重労働になりそう
- ヘルスチェックが死活監視になっているのが一番軽いパターン
- マイクロサービスの「アプリケーションの正常性」という表現を本ではされている

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

- ログ
- 可能なら何でもかんでも取る
- ディスク飽和には注意が必要
- ログの書き込み時間にも影響を与えないようにする
- ただし少ないと、トラブルシューティングできなくなるので、取れるにしたことはない

## 8章 サーバー監視

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

- 標準的なメトリクス: CPU、メモリ、ロードアベレージ、ネットワークディスク
- 診断やトラブルシューティングとしてコンテキストでは有用
- 著者のおすすめは全システムで自動記録にしつつアラートは設定しない
- アプリケーションが起動しているかなどの事項としては弱い

### 8.1.1 CPU

特筆なし

### 8.2.2 メモリ

- **OOMKiller** の呼び出しは監視すると良い
- メモリの使用量が増えたときにプロセスを停止する役割
- 発生時にアラートを送る仕組みにしておく
- プロセス停止は予測しづらく、どこかで問題が起きているはず

### 8.1.3 ネットワーク

インとアウトのオクテット数、エラー数、ドロップ数を収集しておく

### 8.1.4 ディスク

Linux系の `iostat` コマンド ( `-x` なし)は tps(transfer per seconds, または IOPS(I/O per seconds)) が得られる。

IOPSが急激に低下していたら、ディスクパフォーマンスの問題が発生していることがわかる。

( 曰く、NFSディスク100%になって障害につながったことがあるので、容量も監視すべし)

### 8.1.5 ロードアベレージ

- CPUに処理してもらうのを待っているプロセス数の指標
- 1コアあたりロードが 1.0 なら完全に許容の範囲
- 値が高いからと行って実際に問題があるとは言えない
- 著者の体験では 15分平均ロードが500を超えていてもシステムが使えていた

### 8.2 SSL証明書

有効期限切れの監視をするべし

### 8.3 SNMP

- SNMPをサーバー監視に使うのは辞めるべき。
- 拡張が大変
- セキュアではないプロトコル。SNMPv3でも不十分
- ポーリングが必要で、スケール管理が難しくなる

### 8.4 Webサーバ

- **秒間リクエスト数** が重要指標になる
- HTTPステータスコードの監視

## 8.5 データベースサーバ

- 基本的な監視対象は **コネクション数**、**IOPS**
- MySQLではコネクション数 = スレッド数

## 8.6 ロードバランサー

- フロントエンド と バックエンド の2つ分を取る
- ヘルスチェックを通じてサーバーの状態を監視

## 8.7 メッセージキュー

- キューの長さ と 消費率 が主な監視対象

## 8.8 キャッシュ

- キャッシュから追い出されたアイテム数 と ヒット・ミス率 が監視対象

## 8.9 DNS

自前で運用する機会が少ないのであまり気にしなくて良いかも。
ゾーン転送、秒間クエリ数が主な監視対象。

## 8.10 NTP

特筆なし

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

最大の欠点はSNMPを未だに使わないといけないこと。
RFC 1067で提案されたプロトコル。
トラップの内容はsyslog にも記録されるされるため、トラップは無効にしてしまうことが多い。

**9.1.2 SNMPの仕組み**

- エージェント: 情報を取得したいデバイス
- マネージャ: 情報を受取るデバイス

**エージェント**

オブジェクトID(OID)で構成されるツリー上の表記データを提供する。

OIDは整数列 (`.1.3.6.1.2.1.1.1.0` など)でされる。
整数列を変換してテキスト表記 (`sysDescr.0`)することもできる。

Management Information Base(MIB)を用いることで、OIDの変換を行う。
中身はOIDとテキスト表kのマッピングだが、表記は複雑なので99%の人は気にする必要は無い。
- 例
- FUJITSU Systemwalkerの[SNMPv2形式の拡張MIBファイルの基本的な文法](https://software.fujitsu.com/jp/manual/manualfiles/M090045/J2X12071/05Z200/J2071-00-07-10-00.html)
- 日立 [JP1 Version 13/SNMP System Observer](https://itpfdoc.hitachi.co.jp/manuals/3021/30213L3400/INDEX.HTM)

**9.1.3セキュリティについて**

SNMPv3よりまえは、コミュニティ名を平文で送る。
v3では暗号化可能であるがネットワーク機器の負荷が増えたりサポートしていないものがある。
そのため、インフラ側にセキュリティの仕組みを組み込みセキュアではないプロトコルでやり取りするのが1つの答え。

### 主な監視対象

どのOIDを監視すべきか =>

**インタフェイス**

- 帯域幅
- スループット
- レイテンシ
- エラー
- ジッタ

### フロー監視

メモ:
フローが持っている情報は機密性が高い。
外部からアクセス可能なネットワークでは、フロー監視を行わないほうが良い。

## 10章セキュリティ

- インフラやアプリケーションがセキュリティを念頭に入れて作られていないことが多い
- 自分もそれほど念頭に入れない。予算の都合で WAF を念の為にくっつけて置くぐらい
- リスク分析 -> 何が必要か -> 何を導入すべきか など体系的には考えてない

- 自宅をホワイトホワイトハウスレベルにセキュアにすると不便な例は面白い
- 身の丈にあったセキュリティを考えないと、迂回されたり、無視されたり、生産性が低下したりしそう

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

HIPPAなり、PCI-DSSなりこの手のセキュリティ基準はモジュール性が無く、
人間のための n要件だったり、n個の項目などのまとまりになってり、
偉い人たちが安心感を与えるためのコンサルのためのチェックリストみたいなものの印象で、ただただ辛い。

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

`auditd` は システムで発生するイベントやアクションを通知できるコンポーネントのインタフェイス
すべての `sudo` の実行、コマンドの実行、誰が実行したかなど

制限としてログがサーバーのローカルに置かれたままになるので、改ざんされないようにする工夫が必要。
中央サーバーに自動的に送られるようにするなど

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

ホスト上で不正な行為をするのを検出するための仕組み。

### 10.4 rkhunter

`rkhunter` はルートキットの検出に広く使用されている。
シェルからだけではなく、cronjob から実行されることを想定したCLIフラグが用意されている

### 10.5 ネットワーク侵入検知システム (NIDS)

ネットワーク自体に対する脅威を検出するのに便利な仕組み。
[ネットワークタップ](https://en.wikipedia.org/wiki/Network_tap) をネットワーク内に配置して生のトラフィックを確認することで動作する。
Amazon で見ていると 170,979円〜 からありそう。

(感想)昨今のパケットの中身がほとんど暗号化されているような状況に対応しているのだろうか。

ファイアウォールはブロックすることが目的だが、NIDS は検出・通知することが目的。
いくらブロックしていても侵入は避けられないという点に焦点が当てられている。

コラムのSPANポートかハードウェアタップかについて、
この本の筆者はハードウェアタップをおすすめしている。
ハードウェアタップは多いトラフィックを扱うよう設計されているが、SPANは1ポートのトラフィックをいっぱいにしてしまうため。

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

仮想の企業/サービス `Tater.ly` を題材にした指標の出し方・具体的な答え合わせの内容