1.3 リソース受容の分析と予測
1.3.1 リソース監視ツール
OSSの有名どころを使って多数のサーバを効率よく監視する
collectd
いろいろなメトリクスを収集する
- CPU使用率
- システムの温度、ファンの速度
- プロセスの実行速度
- ネットワークトラフィックやレイテンシ
-
各種ミドルウェアの情報
- Apache Webサーバ、Nginx
- BIND
- MySQL, PostgreSQL, Oracle等
- スワップ
- ユーザーのログイン情報
制限
-
collectdそれ自体はグラフの生成はしない
- 生成用のファイルを書き出しはする
- contrib/以下のスクリプトやkcollectd等を使おう
-
監視機能は簡素
- Nagios等を使おう (プラグインあり)
Nagios
-
各種監視
-
ネットワーク監視
- HTTP, SMTP, POP3, FTP, SNMP等
-
サーバー監視
- CPU, load average, ディスク使用率等
- アプリケーション監視
-
- Webインタフェース
- 通知
- イベントハンドラ
- ログローテート
- ホストを階層構造で定義
MRTG
-
ネットワーク機器の負荷を監視する
- もともとrouter用
- PNG/HTMLで結果出力するのでWebサーバと連携して結果表示できる
Cacti
- MRTG代替
- 設定をWebブラウザベースで行える
- 過去のグラフを参照できる
Icinga2
https://icinga.com/docs/icinga-2/latest/doc/01-about/
ネットワークリソースの可用性監視
Nagiosフォーク
1.3.2 受容の分析と将来の予測
継続的にメトリクスを取得し、比較参照したりグラフ化したりして将来のキャパシティ限界予測する
CPU
システムのどの部分が・どのプロセスがCPUを多く消費しているかを分析する
メモリ
-
Linuxではuptimeが長くなるにつれ空きメモリが無くなるのは普通の挙動
- キャッシュに割り当てられるので
- スワップ状況とあわせてメモリ不足を判断する
ディスクI/O
- 特定のパーティションにアクセスが集中していれば高速なストレージに移す
- 容量の増加率にも気をつける
ネットワーク
将来のネットワーク機器や回線の増強に備えて計測しておく
1.3.3 リソースの問題解決
ボトルネックはどこか
カーネル
標準カーネルはいらないものが入っていたりH/W最適化されていなかったりする
- H/Wにあわせて再構築
- /proc/sys/以下カーネルパラメータを調整(次章)
サービス
起動スクリプト見直し
メモリとスワップ
vmstat, free等でsi/soが0でない場合、スワップ領域が使用されている
現在使用中のスワップサイズの確認
swapon -sFilename Type Size Used Priority
/swap/file file 7340032 0 -2同じ内容を /proc/swaps で確認できる
cat /proc/swapsFilename Type Size Used Priority
/swap/file file 7340032 0 -2