Contenu connexe
Similaire à hbstudy#06 (20)
hbstudy#06
- 2. agenda
インフラエンジニアのお仕事
監視とは
なぜ監視が必要なのか
どうやって監視するか
監視チームを作る
- 3. 誰?
坂口利樹 ( さかぐちとしき )
twitter : tsakaguchi
Mail : sakaguchi.toshiki@gmail.com
インフラエンジニア
エンジニア歴 2 年半 ( しんそつ )
PostgreSQL Confarence 2009 Tokyo/Fall 実行委員
- 4. インフラエンジニアのお仕事
定例業務
定例業務 非定例業務
設計、アーキテクト
●
管理
● ●
ボトルネックの解析・ログ解析
●
機器・設定情報の管理 高負荷プロセスの分析
●
リソース管理 ●
運用方法・監視方法の検討・提案
●
バックアップ
●
権限・セキュリティ管理 選定
●
●
ネットワーク・サーバ
監視
●
OS ・アプリケーション
●
システム・機器の稼働状況、 iDC ・回線等の選定
リソース状況・ログ出力、改竄検知 ●
負荷テスト
●
障害対応
構築
●
問い合わせ対応・サポート
● ●
サーバ、機器のセットアップ
●
社内外からの問い合わせ ラックマウント・ケーブリング
SSL 証明書取得・設定
- 5. インフラエンジニアのお仕事
定例業務
定例業務 非定例業務
設計、アーキテクト
●
管理
● ●
ボトルネックの解析・ログ解析
●
機器・設定情報の管理 高負荷プロセスの分析
●
リソース管理 ●
運用方法・監視方法の検討・提案
●
バックアップ
●
権限・セキュリティ管理 選定
●
●
ネットワーク・サーバ
監視
●
OS ・アプリケーション
●
システム・機器の稼働状況、 iDC ・回線等の選定
リソース状況・ログ出力、改竄検知 ●
負荷テスト
●
障害対応
構築
●
問い合わせ対応・サポート
● ●
サーバ、機器のセットアップ
●
社内外からの問い合わせ ラックマウント・ケーブリング
SSL 証明書取得・設定
- 8. 監視とは
システムやネットワークの状況変化を
知るための情報収集活動
- 10. なぜ監視が必要なのか
大前提:ビジネス・サービスが動いている
高可用性が求められる
すべての障害を予期することは困難
機能停止 性能低下
機能監視 性能把握
- 11. 監視の種類を分類
機能監視 性能把握
●
L1 〜 L3 ネットワーク
●
L4 〜 L7 サービス
● HTTP(S) システムリソース
●
POP3(S)
CPU 使用量
●
●
● SMTP(S)
● IMAP(S) ●
メモリ使用量
DNS
Disk I/O
●
●
● SSH
● (S)FTP ●
Network( 遅延・帯域 )
●
DB への接続状態 ●
DB の内部状態
●
プロセス死活
●
ログ出力
● RAID
- 12. 監視の種類を分類
機能監視 性能把握
●
L1 〜 L3 ネットワーク
●
L4 〜 L7 サービス
● HTTP(S) システムリソース
●
POP3(S)
CPU 使用量
●
●
● SMTP(S)
● IMAP(S) ●
メモリ使用量
DNS
Disk I/O
●
●
● SSH
● (S)FTP ●
Network( 遅延・帯域 )
●
DB への接続状態 ●
DB の内部状態
●
プロセス死活
●
ログ出力
● RAID
- 14. どうやって監視するか
監視ツールを使う
メリット
既に欲しい機能が作り込まれている
オープンソース
ZABBIX
Hinemos
Nagios
hobbit(Xymon)
- 17. 監視ツール選定 (1)
機能
スケジューリング
人間のスケジュールに合わせた運用
例:バッチ処理時間帯はある程度の負荷を許容
柔軟性
プラグインで拡張可能か!?
Nagios の場合、プラグインの exit code で判定
0: OK
1: WARNING
2: CRITICAL
- 18. 監視ツール選定 (2)
性能
Nagios の場合、 3 年前のマシン 1 台で 400 台く
らいが目安
Pentium4 3GHz, mem 1GB で検証→ 400 台、 4000 項目程度は OK
Nagios は AMQP と組み合わせてスケールアウト
もできるらしい ( 未検証 )
- 19. 監視ツール選定 (3)
運用
設定内容の管理
バージョン管理システム ( ハートビーツでは SVN)
で管理できると楽
テスト環境の用意
バージョン管理システムと組み合わせて
テスト環境を構築しています
テスト環境はメールが一切飛ばないようにしています
- 20. 監視設定手順
2.設定・動作確認 1.チェックアウト
Nagios(test)
3.コミット SVN リポジトリ
5.設定反映
4 .チェックアウト
Nagios (1)
7.設定反映
Nagios (2) 6.チェックアウト
- 21. 監視のポイント
何のサービスが動いているか
最適な監視
必要なところ ( 使っているところ )
監視項目をむやみに増やしすぎない
使う側の視点
- 22. 監視サーバのネットワーク
2拠点から監視
別キャリアのネットワーク
Nagios(1)
Internet 監視対象サーバ
Nagios(2)
- 23. 監視項目例 (Web サイト )
外部
内部
HTTP/HTTPS LoadAverage
表示されるまでの時間
メモリ
文字列
プロセス総数
ログイン
ログ出力
シナリオ
プロセス稼働状況
回線使用状況
DB レプリケーション
Disk 残容量
Disk I/O
- 24. 監視項目例 (JavaVM)
プロセス死活
ヒープ域不足 (Out of Memory)
OOM Killer によりプロセスが Kill される
Tomcat/Jboss プロセスサイズ
ログ監視
- 25. 監視項目例 (MySQL)
Mysql Status の取得
Web サーバから DB サーバへの接続
レプリケーションの状況
テーブルを作成して削除
- 26. システム監視だけじゃない!
大事なのはビジネスなので、そのレイヤーまで見る!
IBM 用語で「センス アンド レスポンド」というそうです
例えば・・・
システムのログインユーザ数を監視 (DB へのクエリ結
果)
広告からのサイト流入量を監視 (DB へのクエリ結果 )
- 27. 閾値の調整
閾値の決定ポリシー
サービスによって様々
運用しながら
誤報
なくすことはできない(宿命)
減らすことはできる
リトライチェック
根本的な解決を !
- 28. 誤報撲滅!
遠い場合 (EC2 、中国にあるサーバ )
パケットロスは容認
リトライ回数を増やす
対応しないアラートは誤報と同じ
「アラートを無視する習慣」につながるので、重点
的になくす!
「アラートを無視する習慣」がついたら一巻の終わ
り
- 29. 閾値の調整例
どこまでが正常なのか
サイト表示: 3 秒〜 5 秒 ( 目標値 )
LoadAverage : CPU のコア数
SWAP : 20%
プロセス総数
Web サーバ (Apacheprefork) の場合
稼働中のプロセス総数
+
(MaxClients 稼働中の httpd プロセス数 )
- 30. 対応の自動化
イベントハンドラの活用
LB から切り離す
落とし穴に注意
例: Apache の自動再起動スクリプト
セマフォによるリソース管理の上限で Apache が自動起動されず、
web サービスが復旧しない
Apache 管理ユーザのセマフォの削除を手動で行い解決
- 31. 監視の種類を分類
障害監視 性能監視
●
L1 〜 L3 ネットワーク死活
●
L4 〜 L7 サービス監視
● HTTP(S)
POP3(S)
システムリソース
●
● SMTP(S) ●
● IMAP(S)
● DNS ● CPU
SSH
メモリ使用量
●
● (S)FTP ●
DB への接続状態・内部
● Disk I/O
●
●
システムリソース
●
ログインユーザ数 ● Network
プロセス死活
DB の内部状態
●
●
● CPU
●
Memory 使用量
●
SWAP 使用量
●
ディスク空き容量
●
ログ出力
- 32. なぜ監視するか
変化の把握
ボトルネックの把握
チューニング
スケールアウト / スケールアップ
後々必要になってくるので早い段階からの実装
キャパシティプランニング
このシステムでどれだけこなせるか
どのタイミングで増設が必要になるか
- 33. どうやって監視するか
ツールを使う
MRTG
Cacti
Munin
ZABBIX
Hinemos
- 34. 何を監視するか
想定されるボトルネックはどこか?
想定されるトラブルは何か?
- 35. 監視項目例 (MySQL)
Cacti
Login Count /Session Count
InnoDB BuffrePool / I/O / Insert Buffer
Row Operations / Log Buffer Size.....
- 37. 監視チームを作る
監視と障害対応は切り離せない
一人ではやりきれない
夜間の障害対応
複数同時の障害
精神的・労務的な問題
24 時間 365 日
4 人は最低必要 ( 休み無し )
- 38. 情報共有
アラートメールの送信先
インフラ担当だけでなく開発や企画担当の人も
ドキュメント ( 監視仕様書 )
人を育てるのにも有効
- 39. ドキュメントの書き方のコツ
ネットワーク構成図
アプリケーション構成図
対応フローの確定
監視項目ごとの状況確認方法
監視項目ごとの対応方法
- 40. アプリケーション構成図 ( 例 )
hb-web01
ハートビーツ Postfix:25
Internet apache(123.123.1.1:80)
共有 FW
tomcat(8009)
MySQL:3306
(Master)
hb-nfs01
apache2(123.123.1.21:80)
ト
ウン ファイル共有
smb マ
ト
vsftpd:21 sshd:22 ウン
sm bマ rs
yn
c+
ss
h
hb-webdev01 バ
ッ
Postfix:25 ク
apache(123.123.2.1:80) ア
ッ
プ
tomcat(8009)
MySQL:3306 hb-backup01
MySQL:3307 MySQL:3306
Replication Replication
apache2(123.123.2.2:80) Slave Slave
rsync+ssh バックアップ sshd:22
vsftpd:21 sshd:22 svn リポジトリ
- 45. 対応する人の決定の補足
お見合いが一番怖い
ダウンタイムだけが伸びたら・・・ビジネスに影響大!
誰がボールを持っているか、常に明確に!
アラート同報だと誰がボールを持っているか不明確
深夜の場合、ボールを受け取った後や、対応中にホストダウン ( 居
眠り ) の可能性も・・・
ハートビーツの場合、ひとりずつ電話をかけるのでボールの持ち
主は明確になります
対応完了のご連絡をいただけない場合、ベストエフォートでリ
マインドもできます