# 入門 監視

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

アンチパターン（一見良い方法だが実装すると痛い目を見る）

1. ツール依存
2. 役割としての監視
3. チェックボックス監視
4. 監視を支えにする
5. 手動設定

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

デザパタというよりは方針？

1. 組み合わせ可能な監視
- データストレージのチョイスみたいなのは近年気にすることはない気がする
- https://opentelemetry.io/ も抑えとくといいかも
- 監視プラットフォームは疎結合なものを選ぶと良い
- 非構造化ログの方が良いこともある。「人間が読む"だけ"なら」
- 構造化ログにアプリサーバでタイムスタンプをつけるか？
- システムの性質によりそうで、海外などラグが大きい場所であればいれたほうが追いやすそうな場合がありそう
2. ユーザ視点での監視
- 初手としては正しいけど、ユーザに影響与えてからでは遅いので普通コンポーネントの監視も重要
3. 作るのではなく買う
- 高いけど、OSSや独自でやるともっとお金かかるのは同意。SaaSを入れるときは、どういう目的でいれるかしっかりしておくと効果が高そう
4. 継続的改善

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

1. どうしたらアラートをよくできるか
2. オンコール
3. インシデント管理
4. 振り返り

>インフラの構成はどうなっているかの部分は設計と重複する箇所がでる可能性が高い。実態と設計と手順の乖離をなくす良い方法はなんだろう？

@akeboshi IaC とかでインフラの構成の表現はやりやすくなってるが？
@niwa-t どういうところを見に行かないといけないか書いててあってほしいのは感じるけど、IaC の変更と手順書が同期させられているというのはどう保証すればいいだろうかということ
@akiakaba セットで変更されるのをレビューとかで確認するくらいしか思い当たらない。機械的には…？
@akeboshi 久しぶりに触ってみたら構成変わってるぞというのは実際最近あった
@akiakaba 乖離自体は完全に防げないかもしれないけど、Single Source of Truth が決まってれば、乖離してるから、合わせなきゃね、で解決可能
@niwa-t インフラ構成は手順書の一部にするというよりは参照にする

>変化量のアラート作るの難しそう

@akiakaba Datadog、NewRelic だとアノマリーとかあるよね
@akeboshi [newrelic](https://docs.newrelic.com/docs/alerts-applied-intelligence/applied-intelligence/anomaly-detection/),[DataDog](https://docs.datadoghq.com/monitors/types/anomaly/),[AWS DevOps Guru](https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/devops-guru-for-rds.html),[cloudwatch](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
@akiakaba 変化量は Alert を飛ばすのではなく、 warning レベルで残しておくのが良さそう

>3. インシデント管理

手順（役割ぎめを含む）が事前に設計されてるべき

> 4. 振り返り

透明性が原則だけど、発注者とベンダーみたいに利益相反している場合は政治が入ってくるので建設的でなくなっていきそう

## 4章 統計入門

1. システム運用における統計を学ぶ前に
2. 計算が救いの手を差し伸べる
3. 統計は魔法ではない
4. mean と average
5. 中央値
6. 周期性
7. 分位数
8. 標準偏差
9. まとめ

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

1. ビジネス KPI
2. 2つの事例
3. ビジネス KPI を技術指標に結びつける
4. 自分のアプリケーションにそんなメトリクスはないという時は
5. 会社のビジネス KPI を見つける
6. まとめ

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

1. 遅いアプリケーションのコスト
2. フロントエンド監視の2つのアプローチ
3. DOM
4. ロギング
5. シンセティック監視
6. まとめ

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

1. メトリクスでアプリケーションを計測する
2. ビルドとリリースのパイプラインの監視
3. health エンドポイントパターン
4. アプリケーションロギング
5. サーバレスまたは FaaS
6. マイクロサービスアーキテクチャを監視する
7. まとめ

## 8章 サーバ監視

1. OS の標準的なメトリクス
2. SSL 証明書
3. SNMP
4. Web サーバ
5. データベースサーバ
6. ロードバランサ
7. メッセージキュー
8. キャッシュ
9. DNS
10. NTP
11. それ以外の企業インフラにおける監視
12. スケジュールジョブの監視
13. ロギング
14. まとめ

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

1. SNMP の辛さ
2. 構成管理
3. 音声と映像
4. ルーティング
5. スパニングツリープロトコル(STP)
6. シャーシ
7. フロー監視
8. キャパシティプランニング
9. まとめ

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

1. 監視とコンプライアンス
2. ユーザ、コマンド、ファイルシステムの監査
3. ホスト型侵入検知システム (HIDS)
4. rkhunter
5. ネットワーク検知システム (NIDS)
6. まとめ

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

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

---

[@akiakaba memo](https://hackmd.io/sEJPT54VTcWLYY65NzvoYw)
[@akeboshi memo](https://hackmd.io/BPjVlMCsRvWhLp4eDgZ77Q)
[@intptr_t memo](https://hackmd.io/04K1ErZwRpedLorc0nyiFQ)

---

## まとめ

- 組み合わせして監視
- データ収集、データストレージ、可視化 は分かれるのはわかる。分析レポート、アラートは可視化と同じところにあるのがいいのでは？
- 可視化+αのツール + 他のツールでもやれるようにできると良いね！であれば同意