監視〜ネットワーク勉強会資料

2017/12/26
佐々木健
ネットワークの基本について学ぶ
第6回
監視

この文書について
毎度おなじみ、日々のお菓子をめぐんでもらうた
めの勉強会です。いつもありがとうございます。
今回はリクエストがあった監視の話をしようかと思っ
ています。

お願い
定時後の勉強会なので気楽に行きましょう。
飲食、雑談は自由にしてください。
みんなであれこれ雑談してくれるほうが私もおやつ
を食べやすいです。
わからないことがあったら遠慮せずに聞いてね。
#beginner-net-study というSlackチャンネルを
作ったので雑談に使ってくださいませ。

本日のタイムスケジュール(予定)
●
参加者の自己紹介(5分)
– 人数が少なかったら全員
– 人数が多かったら近くにいる5人に自己紹介
●
前回までのおさらい(5分)
●
本編(15分)
●
質疑(5分)

自己紹介
●
名前
●
所属
●
趣味
●
意気込み
●
ネタ

本日の内容
●
良い監視/悪い監視
●
なんのために監視をするか？
●
何を監視するのか？
●
アラートが上がったらどうするか？
●
監視ツールの選び方
●
今的な監視システム
●
最近の話題

なぜ良いか
●
目的が明確
●
なにかあったときの対応策がある
●
ローコスト

なぜ悪いか
●
目的が不明確(監視が目的になっている)
●
なにかあったらひどいことになる
●
コストかけすぎ

監視をするときに考えること
●
監視をする目的は何か？
●
その目的を決めるのは誰か？
●
何を監視する？
●
どうやって監視する？
●
異常が発生したらどのように対応する？
●
コストはどのぐらいかける？

考えた例1
●
サービスが止まると売上が上がらなくなっちゃう
●
サービス提供者としてはそれは困るので
●
サービスがちゃんと動いてるかどうかを
●
専門の監視チームに依頼しつつ
●
なにかあったら一次対応もしてもらおう
●
利益に影響しない程度のコストだと嬉しいな

考えた例2
●
趣味でやってるのでサービスが止まってもOK
●
システムがどんな挙動をしてるかは把握したい
●
フリーの監視ツールを使って
●
なにかあったときのトラブルシュートができるよ
うにしておく
●
即時対応する必要もない

真面目に考えると
●
リスクマネジメント？
●
ISMSみたいなフレームワークを使う？
●
情報資産管理台帳作るの？
●
リスクアセスメント？
●
運用設計？
●
ITILも勉強するの？
楽しい運用沼へようこそ

今日は運用沼はスルーします

ビジネスにおける監視の動機
●
売ってるものが動いてることを確認したい。
●
売ってるものの異常は把握したい。
「売ってるもの」に
注目してみる

ハードウェア監視
●
売ってる人
– ハードウェアメーカー
●
売ってるもの
– 汎用コンピュータ
– サーバ
– ネットワーク機器
– ストレージ
●
監視システム例
– ハードウェア監視プログラム
– 統合プラットフォーム管理ツール
●
監視プロトコル、インターフェイス例
– IPMI
– SNMP
– syslog

設備監視
●
売ってる人
– データセンター
●
売ってるもの
– 電気
– セキュリティ
●
監視方法
– 防災センター
– Network Operation Center

回線監視
●
売ってる人
– 電話会社、通信会社
●
売ってるもの
– 電話回線
– 専用線
– イーサネット接続
●
監視方法
– OSS(Operation Support System ※電話会社用語)
– NMS(Network Management System)
●
監視プロトコル例
– SNMP
– syslog
– Ether OAM

インターネット接続監視
●
売ってる人
– ISP
– データセンター
●
売ってるもの
– インターネット接続
– 経路情報
●
監視方法
– NMS(Network Management System)
– OpenBMP
– Nagios/Zabbix 等の汎用監視ツール
●
監視プロトコル例
– Ping
– BFD
– BMP

サーバ監視
●
売ってる人
– ホスティング事業者
– MSP
●
売ってるもの
– サーバ(物理、仮想)
●
監視方法
●
監視プロトコル等
– Ping
– syslog、サーバログ
– HTTP/SMTP/DNS等の汎用プロトコル

サービス監視
●
売ってる人
– コンテンツ事業者
– インターネットでサービスをしている事業者
●
売ってるもの
– インターネットを使ったサービス
●
監視方法
– エージェント型監視ツール
– サービスチェックツール
●
監視プロトコル
– HTTP/SMTP/DNS等のインターネットサービスプロトコル
– 独自サービスチェックプロトコル
– 各種ログ

「売ってるもの」についてまとめ
●
売ってるもの(お金を生み出してるもの)について
はちゃんと監視をしとくと良い
●
ものによって監視方法等は違う
●
買ってるものについては、売る側のほうで監視し
てくれてることも多い
●
必要だけど不足してるところは自前で頑張る必要
がある。

異常が見付かったら
●
売ってる人に直してもらうのが基本
●
でも自分で作ったところは自分で直さないといけ
ない。
●
そんなあなたにMSP!!
– 詳細は社内Confuence見よう
– 監視、運用の相談もできる

よくある判断パターン
●
サービスのアラート
– 即時対応。
– 対応手順は作っておく。
●
リソース(CPU、メモリ、ネットワーク)のアラート
– サービスが動いていれば様子を見る。
– 必要なら後日増強する。
●
複数台あるうちの1台に異常
– サービスが動いていれば問題なしと判断
– 必要なら後日対応を行なう。
悩んだらMSPに相談

監視ツール選定での悩み
●
すごく沢山ツールがある
– どれを選べばいいの？
– ツールごとの違いが良くわからない
●
ツールの設定方法
– 設定方法がわからない
– 設定が面倒くさい
●
どこから監視するか
– 監視専用のネットワークを作る？
– 外からも監視したほうが良いの？

ツールの選び方
●
ツールのコンテクストは合っているか？
– 誰が何の目的で作ったものか。
– 同じようなユースケースで使われているか
●
人気はあるか？
●
中身は綺麗か？
●
新しいか？
– 新しいものはたいてい良いところがある
●
利用者が使いこなせるか？
– 高機能すぎたり複雑すぎたりすると現場がつらい

新しいものは基本いいぞ
●
お勧め汎用監視ツールの変遷
– Nagios → Zabbix → Prometheus
●
Nagiosの良いところ
– 沢山のサーバをまとめて監視できる
●
Zabbixの良いところ
– Nagiosができることは大体できる。
– ストレージをデータベースに変更。Nagiosはテキスト。
– ダッシュボードが簡単に作れる。

新しいものは基本いいぞ(2)
●
Prometheusの良いところ
– Zabbixができることは大体できる
– インストールが簡単
– モジュール分割設計
– フロントエンドのGrafanaにグラフ描画を任せること
でサーバ負荷低減
– アラート数抑制

新しめの監視ツールの特徴
●
配布が楽な言語で書かれている。(Go、Rust等)
●
インストール、設定が楽。
●
モジュールごとに機能分離されていて、大規模になって
もスケールしやすい形になっている
●
他のシステムと連携するためのAPIがある
●
Docker等のコンテナで動かすことを想定した作りになっ
ている
●
設定ファイルはYAML
●
アラート集約や抑制ができるようになっている

今どきの監視方針
●
取れるデータはとりあえず取っておく
●
ツールはお手軽なやつで
– エージェント型のツール等はとても簡単
●
ログはログ収集基盤に飛ばす
– クラウドや、SaaSはとても便利
●
ダッシュボードは、Kibana、Grafanaのようなフ
ロントエンドツールやBIツールを活用
●
アラートは必要なものだけ飛ばす

いちおう考えなきゃいけないセキュリティ
●
監視システムは侵入元になったりもする
●
セキュリティとはリスクコントロール
●
監視とは切り離せない
●
とはいえセキュリティは沼!!
●
専門家を活用しよう

今後の動向
●
いろいろな技術が出てくると、それによるサービス(売るも
の)が増えてくる。そのための監視も必要になる。
●
最近の技術、これから出てくる技術↓
– クラウド
– フォッグ
– 5G
– IoT
– AI
– ブロックチェーン
– VR、AR

次回予告
●
次に聞きたいネタはあるかしら？
– Ethernet
– ルーティング
– ネットワークプログラミング
– サーバハードウェア
– ネットワーク仮想化
– 機器管理
– ICN(Information Centric Networking)
– IPv6

監視〜ネットワーク勉強会資料

Recommandé

Recommandé

Contenu connexe

Plus de Ken SASAKI

Plus de Ken SASAKI (20)