---
# System prepended metadata

title: 入門監視 @akeboshi
tags: [入門監視]

---

入門監視　@akeboshi
---

## 2章

- TSDB: 普段 elastic search なり opensearch, newrelic 等あまり考えてなかった。近年 DB にどう保存するかあまり考える機会無いのでは
- 可視性: Prometeus, Grafana が出てきたときに、なんで分けてるんだろうな？と思ったけど、View は分けたほうがいいというのは確かにそう。opensearch は amazon のサービス提供をベースに考えられてそうなので、elasticsearch と kibela が一緒になったような感じなんだろうな
- SLA: 99% と 99.9%はかなり違うような？ :thinking_face: 
    - 99%: 3.5日, 99.9%: 9時間
- Alert: 監視の目的を理解しないまま仕組みを導入
    - これをされると、既存の監視から変えるのしんどいのでアレ
- ユーザ視点での監視: それはそう
- 安いから: とはいえ、最近の監視高すぎんか～、$9000 だとAPM対していれられんぞ (Datadog だと 20 台程度でそのくらいでは。桁が一桁たりない), ただ自前のほうがお金かかるので、SaaS でいいぞ！というのは同意

## 3章

狼少年にならないようにアラートを送ろう

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

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

そのアラートをトリガーでやりたいアクションを想定して送り先を決めようという話、メールであっても良いとは思う。
ただ、後から見れるように基本的にはチャットに送っておくと良さそう

### 3.1.2 手順書を書こう

どういうアクションを起こしたいのかの話

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

アラートの出し方はしきい値だけでなく変化量も見たほうが良いことがあるよ

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

アラートは暫定対応の場合があるので、根本対応しようよという話

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

作業時に無駄なアラートを飛ばすのはやめよう。ハイ…

### 3.1.6 まずは自動復旧をためそう

ハイ…
最近はクラウド化してるのでよりやりやすくなってるよね…

## 3.2 オンコール

### 3.2.1 誤報を修正する

ハイ…

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

3.1 と大分被ってない？

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

ハイ

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

役割決めてやる。

- インシデントコマンダー
- 書紀
- コミュニケーション調整役
- SME

よくあるやつ

## 3.4 振り返り

ポストモーテムちゃんとやろうね
みんなで共有する場を作ったほうがいいよね


## 4章

- mean, median 平均と中央値の話。取りたいデータによって使い分けようね

- `今のデータポイントと前の周期のデータポイントを比較できるツールも存在しています。` これどんなのあるの？

- 標準偏差使ったこと無いな。どういうときに有用なんだろうか

- 上限下限のあるなしでどう変わるの？

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

- ビジネスKPI はやる機会がなかったので、色々あるなという雑な印象
    -　Metabase 経由で自由にとっていってもらってる。監視といえば監視だけど毛色が違うね

## 6章

- 遅いアプリケーションのコストが、フロントエンドだけの話とはちょっと…むしろバックエンドのほうがボトルネックになるケースのほうが多いのでは
    - 多分これはその通りで、とはいえ、フロントエンドのロード時間をちゃんと監視しようねって話だな (それはそう)


### DOM

- js のロード。async しないとブロッキングされるんだっけ？
    - される。なお、 defer なども同じように使われる
- cnn のjsロード8秒は遅すぎ。大分昔の話してるのでは

### メトリクス

- w3c で定義されてる API があるんですね. だから大体のブラウザのディベロッパーツールは大体同じ形してるんやね
- Speed Index(http://bit.ly/1ttMTJ5)
    - waf に弾かれて草
- https://github.com/catchpoint/WebPageTest
    - ho-n
### まとめ

> ページのロード時間を CI システムから計測し続け、ロード時間が許容時間 内に収まるようにしましょう。

実際のロード時間って ci じゃそこまで信頼性ないので、本番を監視し続けるのが正しいと思うんだけどどうなんや

## 7章

> アプリケーションやその背後 にあるビジネスロジックに関する何のコンテキストも把握していません。 特定のクエリ実行にかかった時間を表す小ぎれいな滝グラフを見ていて も、クリティカルワークフローパスでのレイテンシ、あるいはアプリケー ションが何を行うかというコンテキストを知っている必要性については何 も教えてくれないのです。

ハイ。ちゃんとドメイン知識持ってないとやれないよねって話

- statsd
    - ログイン時間の話があるが、これは apm で特定のエンドポイントのロード時間見れば？

- デプロイ (https://www.etsy.com/codeascraft/measure-anything-measure-everything/)
    - これは監視というよりログをとる話では？ 

- メトリクスにすべきか、ログにすべきか
    - ?? メトリクスは json に入れて監視ツールに投げるのがもう一般的では
    - ログはまた違う json にいれるし？？

- 分散トレーシング
    - 割と一般的になってきていて、現在は割と簡易にできるようになってきているのでは

## 8章

/proc 以下を基本的にみる

### CPU

top
htop とかいれるの好き

### メモリ

free

/proc/meminfo に MemAvailable

### network

ip

### disk

iostat -x

### load average

uptime

### SNMP

SNMP 知らない
使うべきじゃないと書いてあるので覚えなくていいか？

Telegraf, Diamond, collectd

### Web server

- req/sec
- status code

### DB

- qps
- slowquery
- iops

cpu/memory も見る必要あるときはある。


https://www.oreilly.co.jp/books/9784873119403/

### LB

- /health

### MQ

- キューの長さ
- 消費率

### キャッシュ

- evicted items
- hit/miss ratio
- cache hit ratio

### DNS

DNS 運用することないしたくもない

- ゾーン転送
- 秒間クエリ数

### NTP

- ntpstat

ここ監視したこと無いな…ずれると困るけど…

### DHCP

ip が十分な数残ってるかは監視したいね

- /var/lib/dhcp.leases

### SMTP

時前でメールサービスなんて運用したいわけ無いだろ！！！！

### スケジュールジョブ

- cron 使いたくないんだけど、近年は何を使うとよい？
    - aws なら eventbridge?
    - なんかいいOSSない？

### ログの収集

- どういうログを集めたいかの性質による
- syslog 現代だとあんまり使われて無く、各種 agent なりなんなり使ってる気がする? 使ってる？

### ログの保存

- 全文検索に入れて、クエリで検索する Athena などでもよい

### ログの分析

- splunk　高いんよ
- SaaS 使おうね

## 9章

### 9.1

SNMP 学ばなくてよいと行ったのに、SNMPの説明じゃん！

SNMP RFC: https://datatracker.ietf.org/doc/html/rfc1067　プロトコルのことらしい

SNMP のクライアント・エージェントはデフォで入ってるのか

MIB で保存されているファイルで、SMI と呼ばれる ASN.1 (型を定義したフォーマットみたいなもの)で OID の数字の羅列が文字列になる

SNMP はセキュアではない。セキュアな管理ネットワーク上で使うのを前提としている。
デバイスが高負荷のときは優先度が下がってしまう。

このプロトコル使うのかなり厳しいのでは…？

MTU...ネトゲのpingあげるためによくわからずいじったことあるな

iperf2
bwctl
smokeping (レイテンシ監視)

#### 9.1.6

全然わからん

● トランクポートへの変更
● ポートの err-disabled への変化
● リンクアグリゲーションされたインタフェイスのバンドル化またはアンバンドル化

### 9.3 音声と映像

全然わからん

- レイテンシ、ジッタ、パケットロス
- cisco が snmp を使ったいい感じなのを用意してくれてるってくらいしか理解できてない

### 9.4 ルーティング

全然わからん

用語
- OSPF
- BGP
- TCAM テーブル
- VRRP
- HSRP

### 9.5 スパニングツリープロトコル

ルートってそんなに変わるものなのか

- ルートブリッジ
- プロトコルのコンバージェンス

### 9.6 シャーシ

CPU, メモリ, それに繋がっているデバイスも監視する

### 9.7 フロー監視

ベンダが提供している監視ツール？

- sFlow
- IPFIX
- NetFlow
- J-Flow

ふーん。なんもわからん

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

逆算・予測

- ゴールに必要なキャパシティを計算する
- 一定期間のデータから今後を予測する

## 10

The Practice of Network Security Monitoring

「脅威とリスクを見積もり、不正アクセス時に決断を下すこと」要はバランスおじさん

### 10.1

- HIPAA, SOX, サーベス・オクスリー法, PCI-DSS, SOC2 などコンプライアンスの規制は色々ある

要件に従って監視を実装していくとコンプライアンスを守れる。簡単なことから難しいことがある

### 10.2

auditd (/var/log/audit/audit.log)
- sudo のログ
- ファイルアクセスのログ
- 認証ログ

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

- rootkit
    - root をダッシュしたり本来許可されてない領域・ホストへのアクセスをするツール

プロセスの振る舞い、ログ分析、ファイルハッシュで検知していく (難しそう)

### 10.4 rkhunter

実際の HIDS ツールかな
ここまで気にしてサーバ管理をしたことがない

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

なるほど全然わからん。
各経路全てに配置して、ログを取っていくようなツールだろうか
クラウドだとどうなるんだろう

## 11

ビジネスKPI や メトリクス, ログなど多くの事柄を見る必要があるように言ってるが、これはなかなか辛そう。

ものによっては、月次週次でのチェック・alertのみチェックなどやり方を分けていく必要がありそう