サーバウォッチ

サーバウォッチによる監視のしくみ

監視サーバがインターネット経由で HTTP や POP などを監視。また、内部監視エージェントがサーバ内のサービス稼働状況を監視し、監視サーバに報告します。

サーバウォッチ

監視の流れ

約 15 分間隔で監視します。監視間隔は変更可能です（有償）。
異常を検知した場合、およそ 1 分間隔で 2 回リトライします。最初の検知を含め 3 回とも異常を検知した場合、お客さま指定のアドレスに障害通知メール（通知メールサンプル）を送信します。

※

障害が継続している場合には１時間に１回通知します。
状況に応じてお客さまによる確認・復旧作業をお願いします。予めいただくお客さま指定の手順（一次対応手順書）による復旧作業をご希望の場合は、一次対応付きをご利用ください。

サーバウォッチの監視のながれ

監視対象

１サーバあたり、最大で 25 項目までの監視が可能です（ 26 項目以上をご希望の場合はご相談ください）。

ネットワーク監視

ネットワークの稼働状況を監視します。疎通ができない場合は障害通知メールを送信します。

監視方法	標準閾値
ping による	パケットロス 60% 以上または RTT ( Round Trip Time ) 1000ms 以上

※: 閾値は変更可能です。

サービス監視（サービスの稼働状況監視）

監視対象ポートへのコマンド送受信によって、サービスの応答状況をサーバ外部から、または監視エージェント経由で監視します。15分ごとの監視サーバ巡回時に異常な応答があった場合や応答がなくタイムアウト（ HTTP・SMTP・POP は 60秒、それ以外は 30秒）した場合に障害通知メールを送信します。

例えば、サーバが停止して一切の疎通が確認できない場合や、一時的にウェブサーバへのアクセスが集中して応答がしづらい状況を通知することができます。

対象

HTTP ・ HTTPS ・ POP ・ SMTP ・ DNS ・ FTP ・ SSH ・ TELNET ・メールの不正中継

ポート	サービス	監視方法
ポート	サービス	サーバウォッチの動作	利用中のサーバ動作
21	FTP	$ telnet 「お客さまサーバ」 21
			< 220 ･･･
		> quit
25	SMTP	$ telnet 「お客さまサーバ」 25
			< 220 ･･･
		> quit
53	DNS	$ nslookup - type = A 「 127.0.0.1 」「 127.0.0.1 」
80	HTTP	$ telnet 「お客さまサーバ」 80
		> GET / HTTP / 1.1
		> Host : $HOST:80
			< HTTP / 1.1 200 OK
110	POP3	$ telnet 「お客さまサーバ」 110
			< +OK ･･･
		> QUIT
443	HTTPS	http クライアントによるアクセス
25	OpenRelay ( 不正中継 ) の操作	$ telnet 「お客さまサーバ」 25
			< 220 ***.at-link.ad.jp ESMTP Sendmail 8.13.1
		> HELO ***.at-link.ad.jp
			< 250 *.at-link.ad.jp Hello *.at-link.ad.jp [xxx.xxx.xxx.xxx]
		> MAIL FROM: < RelayCheck@***.at-link.ad.jp>
			< 250 2.1.0 < RelayCheck@***.at-link.ad.jp > ... Sender ok
		> RCPT TO: < RelayCheck@at-link.ad.jp>
			< 553 5.7.1 ... Relay operation rejected
			< 221 2.0.0 ***.at-link.ad.jp closing connection
		> QUIT

プロセス監視（プロセスの存在監視）

サーバ内部にプロセスが存在しているかを監視します。15分ごとの監視サーバ巡回時にプロセスが立ち上がっていない場合や 30 秒間応答がなくタイムアウトした場合に障害通知メールを送信します。

対象

PostgreSQL ・ MySQL ・ Oracle 各 DB のプロセス・ cron ・お客さま指定プロセス

プロセス	監視方法
プロセス	Linux	Windows
PostgreSQL	ps による	プロセスリスト取得による
MySQL
Oracle
その他

リソース監視（ CPU ・ハードディスクの使用率監視）

内部の CPU 負荷・ディスク使用率・メモリ使用率や Swap 領域の使用状況を監視します。15分ごとの監視サーバ巡回時に設定されている閾値を超えた場合や 30 秒間応答がなくタイムアウトした場合に障害通知メールを送信します。

リソース	標準閾値
リソース	Linux		Windows
CPU	Load Average	10 以上	10 分間の平均負荷	80 % 以上
メモリ	SWAP 使用率	80 % 以上	総メモリ使用率（物理メモリ・仮想メモリ）
ディスク	パーティション毎の使用率	90 % 以上	ドライブ毎の使用率

※: 閾値は変更可能です（お客さまの運営状況に合わせて変更の提案を行うことがあります）。
※: 各リソースに対する閾値は、2008年 2月 25日以降に運用開始のサーバに対する設定です。これより前の閾値については、サーバウォッチのリソース監視の閾値変更についてをご覧ください。

オプション監視項目

オプションでより高度な監視が可能です。

各項目の設定数が合計10までであれば、いくつ設定しても料金は変わりません。10以上になる場合はご相談ください。

例：ログ監視で 5つのログを監視し、URL監視で１つのURLを監視する場合は、合計 6 とカウントします。

※: Windows Server では、以下の項目のうち「帯域監視」「 HTTP 文字列監視」「 URL 監視」のみご利用いただけます。

帯域監視

帯域の使用量（トラフィック）増加を把握することができます。指定された帯域を超えた場合に通知します。

HTTP 文字列監視

出力される HTML を定期的に確認し、指定した文字列が無い場合に障害通知メールを送信します。コンテンツの誤削除や変更、DB から出力される文字列の監視やシステム全体の正常性など、工夫次第でさまざまな監視ができます。

※ スペースを含む文字列の監視も可能です。

URL 監視

指定された URL にアクセスし、コンテンツが正しく表示されるかどうかを監視します。サーバエラー・タイムアウト等のエラー発生時に障害通知メールを送信します。監視対象は、ホスト名やポート番号・ URL が指定できます。バーチャルドメインを使用している場合や、特定の URL への監視に便利です。

ファイル存在監視（ Linux サーバのみ）

指定されたファイルがサーバ内に存在しているかどうかを監視します。存在していない場合に障害通知メールを送信します。 /var/log 以下にあるログファイルや各種アクセスログ、プロセス ID ファイルやデータベースに関わるファイルが存在しているかどうかを監視することができます。

※ URL 監視が外からのコンテンツ状況の確認であるのに対し、ファイル存在監視はサーバ内からの監視となります。

ロードモジュール監視（ Linux サーバのみ）

iptables の iptable_filter など、指定されたモジュールが正常にロードされているかどうかを確認することができます。モジュールが正常に組み込まれていない場合に、障害通知メールを送信します。サーバの再起動後など、本来読み込むべきモジュールがない場合に通知されます。

ログ監視（ Linux サーバのみ）

ログファイルの文字列を監視します。DB のエラー発生など、異常を検出する文字列が出力された場合に障害通知メールを送信します。

オリジナルスクリプトによる監視（ Linux サーバのみ）

お客さまサイドで用意された監視スクリプトをサーバに組み込むことで、様々な監視が可能となります。プロセス監視ではカバーできない DB の応答や、お客さま独自のプロセス状況などが監視できるようになります。ご希望の場合はオリジナル監視仕様に基づきスクリプトを作成し、ご依頼ください。

イベント処理（ Linux サーバのみ）

障害を検知した際（イベントの発生時）に、任意のコマンドを自動実行します。例えば、PostgreSQL の停止を検出すると、そのプロセスを起動するコマンドを自動実行します。コマンドは、予めお客さまにご指示いただきます。

レポートの発行

サーバの稼働状況や障害発生状況のレポートをお客さまに定期的に送信します。

レポートの頻度は、月次送信（月次リポートサンプル）・週次送信（週次リポートサンプル）から選択可能です。

※: レポートの内容は、それぞれ、前月分、前週分です。

一次対応の手順について

一次対応付きは、手順書に基づいた障害対応を行います。

※: 一次対応付きを利用時の障害通知メールには、検知内容に加え、その内容に応じた対応手順フローも記載されています。

一次対応手順書

障害対応手順をご指示ください。コマンドの実行・ブラウザ確認も可能ですので、都度ご相談ください。

対応 1 回あたりの作業量について

ご用意いただく手順書に基づく、障害 1 回あたりの作業量の目安は次のとおりです。コマンド数が多くなる場合は、復旧手順をまとめたスクリプトの作成をお願いしております。

コマンド・手順数	10 回まで ( ブラウザ確認等含む )

※: 上記の作業量を超える場合はご相談ください。
※: 表中の数字はあくまで目安としての作業量です。目安を超えたからといって対応を停止することはありません。また、月間の対応件数にも上限はありません。

サーバウォッチ