同一セグメントにおいてルーティングが必要な場合の対処方法 (ロンゲストマッチはAD値よりも優先される話)

ネットワーク機器やサーバなどにおいては、直接属しているネットワークを「Connected」という状態で認識する。Connectedのネットワークは同一セグメントとなることから、ルーティングはされることなく直接通信することが可能となる。

ただし、同一セグメントにおいても、ネクストホップを指定してルーティングを実施したい場合がある。

本記事では、同一セグメントにおいてもルーティングが必要なケースを例として挙げ、それを解決するための方法について記載する。

Connectedネットワークにおいてもルーティングが必要なケース

例として、負荷分散装置が存在するような以下ネットワーク構成で考えてみよう。負荷分散装置の仮想IP間で通信するサーバが2セット(サーバA-1・A-2とB-1・B-2)ある場合を想定する。すべてのサーバは同一セグメントではあるが、負荷分散装置を経由して通信させたい場合を考える。

この場合、各サーバはConnectedとなっているネットワークとなることから、負荷分散装置経由で通信を受け取っても、戻りの通信を負荷分散装置ではなくサーバに直接返そうとする。これにより、行きと戻りで非対称のルーティングとなるため通信に失敗する。

解消方法①：負荷分散装置でSource NATする

本方法はルーティングによる解決ではないく、負荷分散装置でSource NAT (送信元NAT) をすることで、同一セグメント間の通信として戻り通信を負荷分散装置に戻す方法となる。

Source NATすることで通信は必ず負荷分散装置に戻るため、非対称ルーティングとならない。ただし、通信元のIPアドレスがすべて負荷分散装置のIPアドレスとなってしまうため、通信元のIPアドレスを特定するためには、アプリケーション側で何らかの考慮をする必要がある。

解消方法②：Connectedのネットワークよりもプレフィックス長が長いスタティックルートを設定する

通信元のIPアドレスを必ず実IPで受け取りたい場合など、Source NAT使えない場合がある。そのような場合、あるルールを満たせばスタティックルートをConnectedより優先させることができる。

通常ルーティングには、優先順位として「AD値 (Administrative Distance)」が設定されている。AD値は低いほど優先順位が高く、Cisco機器を例として記載すると、Connectedのネットワークは0、スタティックルートは1、それ以外のダイナミックルーティングは1より大きい数で設定されている。

• 【参考URL】アドミニストレーティブ ディスタンスとは何ですか。 - Cisco

したがって、一見するとConnectedのネットワークは最優先で処理されてしまい、スタティックルートで制御することは困難であると考えてしまう。しかし、もう一つルーティングの優先順位を決めるルールとして、「ロンゲストマッチ (Longest match)」がある。

ロンゲストマッチとは、同じIPアドレス宛てのルーティングルールが複数ある場合、もっともサブネットのプレフィックス長が長いものを優先するというルールである。例えば、以下のような2つのスタティックルートがある場合は、よりプレフィックス長が長い/28のルートが採用される。

種類	ネットワーク	ネクストホップ
Static route	192.168.10.0/24	192.168.20.254
Static route	192.168.10.0/28	192.168.20.201

重要な点は、ロンゲストマッチはAD値よりも優先されて処理されることである。そのため、Connectedのネットワークよりもプレフィックス長が長いスタティックルートを作れば、スタティックルートを優先させることができる。

今回の例では、以下の通りサーバB-1およびサーバB-2に/32のスタティックルートを設定すればよい。これによって、サーバA-1およびサーバB-2あての通信は、必ず負荷分散装置のIPアドレスを経由させることができる。

種類	ネットワーク	ネクストホップ
Connected	192.168.10.0/24	-
Static route	[サーバA-1のIP]/32	[負荷分散装置のIP]
Static route	[サーバA-2のIP]/32	[負荷分散装置のIP]

ただし、もしサーバA-1とサーバB-1間で負荷分散装置を経由せず、直接通信させる要件などもある場合はこの方法では対処できない。そのような場合は、解消方法①のSource NATによる対応を検討しよう。

以上。

NGINXの負荷分散対象サーバに対してポートチェックするスクリプト

先日、NGINXを使って負荷分散装置(ロードバランサ)を構築する手順を記載した。

• NGINXで負荷分散装置を構築する
• NGINXの負荷分散装置をPacemakerで冗長化する

NGINXは非常に簡単に負荷分散装置として構築できる反面、BIG-IPなどの負荷分散装置にあるような、現在の負荷分散装置対象サーバの状態を確認するコマンドなどは用意されていない。

そこで今回、NGINXの負荷分散対象サーバに対してポート開放状態のチェックを行うスクリプトを作成してみた。

環境

環境としては以下の通りAlmaLinuxを利用した。NGINXは前述したURLの通り、負荷分散装置として構築済みである前提とする。

• AlmaLinux 8.5
• NGINX 1.14.1

スクリプト導入手順

1. 前提パッケージの導入

ポートチェックはncコマンドで行うため、以下の通りパッケージインストールを行う。

# dnf install nc -y

2. スクリプトを配置

スクリプトの内容は以下の通りとなる。スクリプトはGitHubに公開している。

• https://github.com/tech-mmmm/check_nginx_stream

作りとしては、NGINXの設定ファイルを読み込み、負荷分散対象サーバに対してポート開放チェックをする。設定ファイルの記載フォーマットが以前の記事の通りとなっていない場合うまく動作しない可能性があるため、その場合はスクリプトの修正が必要となるかもしれない。

#!/bin/bash
################
# Scripts name : check_nginx_stream.sh
# Usage        : ./check_nginx_stream.sh
# Description  : NGINX負荷分散対象ポートチェックスクリプト
# Create       : 2022/04/30 tech-mmmm (https://tech-mmmm.blogspot.com/)
# Modify       :
################

rc=0      # Return code
array=()  # サーバ＆ポート一覧保存用配列
config_file="/etc/nginx/stream.conf.d/servers.stream.conf" # 設定ファイルパス

# Configからサーバ＆ポート情報抽出
while read line || [ -n "${line}" ]; do
  # upstream行の設定から負荷分散対象グループ名を取得
  if [ $(echo ${line} | grep -c -E "^upstream.*{") -ne 0 ]; then
    pool=$(echo ${line} | cut -d" " -f2)
  fi
  # server行の設定から、負荷分散対象サーバの情報を取得
  if [ $(echo ${line} | grep -c -E "^server.*;") -ne 0 ]; then
    member=$(echo ${line} | cut -d" " -f2 | tr -d ";")
    array+=("${pool}:${member}")
  fi
done < "${config_file}"

# ポートスキャン
for i in ${array[@]} ; do
  # ポート番号取得
  server=$(echo $i | cut -d":" -f1)
  port=$(cat /etc/nginx/stream.conf.d/servers.stream.conf | grep -E -B1 "proxy_pass.*${server}" | grep listen | awk '{print $3}' | tr -d ";")
  if [ "${port}" == "" ]; then
    port="tcp"
  fi

  # ポートスキャン
  if [ "${port}" == "tcp" ]; then
    # TCPの場合
    nc -nvz $(echo $i | cut -d":" -f2) $(echo $i | cut -d":" -f3) > /dev/null 2>&1
    if [ $(echo $?) -eq 0 ]; then
      result="up"
    else
      result="down"
      rc=$((${rc} + 1))
    fi
  else
    # UDPの場合
    nc -unvz $(echo $i | cut -d":" -f2) $(echo $i | cut -d":" -f3) > /dev/null 2>&1
    if [ $(echo $?) -eq 0 ]; then
      result="up"
    else
      result="down"
      rc=$((${rc} + 1))
    fi
  fi

  echo "$i:$port -> ${result}"
done

exit ${rc}

上記スクリプトを任意の場所に配置し、実行権限をつければ動作する。今回はgitをインストールしていないため、wgetで取得した。

# wget https://raw.githubusercontent.com/tech-mmmm/check_nginx_stream/main/check_nginx_stream.sh
--2022-04-30 08:41:22--  https://raw.githubusercontent.com/tech-mmmm/check_nginx_stream/main/check_nginx_stream.sh
192.168.33.23:8080 に接続しています... 接続しました。
Proxy による接続要求を送信しました、応答を待っています... 200 OK
長さ: 1853 (1.8K) [text/plain]
`check_nginx_stream.sh' に保存中

check_nginx_stream. 100%[===================>]   1.81K  --.-KB/s 時間 0s

2022-04-30 08:41:22 (62.6 MB/s) - `check_nginx_stream.sh' へ保存完了 [1853/1853]

# chmod +x check_nginx_stream.sh

3. 動作確認

実際に私の環境で実行した結果は以下の通り。

# ./check_nginx_stream.sh
proxy_server:192.168.33.27:8080:tcp -> up
proxy_server:192.168.33.28:8080:tcp -> up
dns_server:192.168.33.27:10053:udp -> up
dns_server:192.168.33.28:10053:udp -> up
mail_server:192.168.33.27:25:tcp -> up
mail_server:192.168.33.28:25:tcp -> up
ntp_server:192.168.33.27:123:udp -> up
ntp_server:192.168.33.28:123:udp -> up

以上 。

NGINXで負荷分散装置(ロードバランサ)を構築する

自宅では、プロキシやDNSなどを負荷分散装置(ロードバランサ)にてロードバランスして利用している。負荷分散装置としてはZEVENETを利用していたが、コミュニティ版は2020年5月から更新がないことや、冗長構成した際にうまく切り替わらないなどの問題が起きていたため、今回別製品に変更することにした。

調べていくと、Webサーバ用途のソフトウェアとして知られる「NGINX (エンジンエックス)」が負荷分散装置としても利用できることがわかった。ただし、OSS版のNGINXにおいては、以下機能が実装されていない点に注意しよう。以下機能は商用のNGINX Plusであれば利用可能となる。

• セッションパーシステンスの機能なし
• 負荷分散対象サーバに対するNGINXからの定期的なヘルチェック (アクティブヘルスチェック) の機能なし。通信発生時に都度ヘルスチェックを行うパッシブヘルスチェックのみ利用可能
• NGINXの機能を利用した冗長化構成の機能なし

今回、「NGINX」を利用して負荷分散装置(ロードバランサ)を構築する手順を記載する。先に言っておくと、NGINXの設定は非常に簡単だった。

環境

環境としては以下の通りAlmaLinuxを利用したが、そのほかのRed Hat系のディストリビューションであれば、ほぼ同様の手順で構築できるはずだ。

• AlmaLinux 8.5
• NGINX 1.14.1

負荷分散装置の構成は以下の通りとする。クライアントからの通信と負荷分散対象サーバが同一のインタフェースとなる「ワンアーム」構成となる。なお、NGINXでは、通信は必ずSource NATされるため、ワンアーム構成としたとしても特別な設定は不要となる。

負荷分散対象は以下の通りとする。

用途	待ち受けポート	負荷分散対象サーバ	ポート番号
Proxy	8080/tcp	192.168.33.27, 192.168.33.28	8080/tcp
DNS	53/udp	192.168.33.27, 192.168.33.28	10053/udp
MTA	25/tcp	192.168.33.27, 192.168.33.28	25/tcp
NTP	123/udp	192.168.33.27, 192.168.33.28	123/udp

NGINXにて負荷分散装置を構築する手順

1. dnfでNGINXをインストール

Red Hat系のディストリビューションの場合は、NGINXは標準のリポジトリに用意されている。NGINX本体に加え、負荷分散装置の設定に必要なstreamモジュールをインストールする。

# dnf install nginx nginx-mod-stream -y

2. NGINXの設定ファイルを作成

負荷分散装置の設定ファイル用のディレクトリを作成する。

# mkdir /etc/nginx/stream.conf.d

ディレクトリ作成後、以下2つのファイルを作成・追記を行う。

/etc/nginx/stream.conf.d/servers.stream.conf

以下内容で設定ファイルを新規作成する。

# Proxy
upstream proxy_server {
    least_conn;
    server 192.168.33.27:8080;
    server 192.168.33.28:8080;
}

server {
    listen       8080;
    proxy_pass   proxy_server;
}

# DNS
upstream dns_server {
    server 192.168.33.27:10053;
    server 192.168.33.28:10053;
}

server {
    listen       53 udp;
    proxy_pass   dns_server;
}

# MTA
upstream mail_server {
    least_conn;
    server 192.168.33.27:25;
    server 192.168.33.28:25;
}

server {
    listen       25;
    proxy_pass   mail_server;
}

# NTP
upstream ntp_server {
    server 192.168.33.27:123;
    server 192.168.33.28:123;
}

server {
    listen       123 udp;
    proxy_pass   ntp_server;
}

/etc/nginx/nginx.conf

以下を最下行に追記する。

stream {
    include /etc/nginx/stream.conf.d/*.conf;
}

3. サービス起動

これだけで必要な設定は完了となるため、NGINXのサービスを起動しよう。

# systemctl start nginx
# systemctl enable nginx

4. 動作確認

サービス起動後に待ち受けポートが開放されていることをssコマンドで確認する。以下の通り、負荷分散装置の設定を行ったポートがLISTEN (UDPに関してはUNCONN) になっていることがわかる。

# ss -nl | egrep ":(8080|53|25|123)" | sed -e 's/  */\t/g'
udp     UNCONN  0       0       0.0.0.0:123     0.0.0.0:*
udp     UNCONN  0       0       0.0.0.0:53      0.0.0.0:*
tcp     LISTEN  0       128     0.0.0.0:8080    0.0.0.0:*
tcp     LISTEN  0       128     0.0.0.0:25      0.0.0.0:*

負荷分散対象サーバに対しても問題なく通信できていることを確認しておこう。

# ss -n | egrep "192.168.33.27:(8080|53|25|123)" | sed -e 's/  */\t/g'
udp     ESTAB   0       0       192.168.33.41:57935     192.168.33.27:123
tcp     ESTAB   0       0       192.168.33.41:39962     192.168.33.27:8080
tcp     ESTAB   0       0       192.168.33.41:39592     192.168.33.27:8080

# ss -n | egrep "192.168.33.28:(8080|53|25|123)" | sed -e 's/  */\t/g'
udp     ESTAB   0       0       192.168.33.41:37953     192.168.33.28:123
tcp     ESTAB   0       0       192.168.33.41:35096     192.168.33.28:8080
tcp     ESTAB   0       0       192.168.33.41:33832     192.168.33.28:8080

以上を確認したうえで、実際にプロキシ経由でのインターネット閲覧やDNSの名前解決を確認し、問題なく動作することを確認した。

以上にて、「NGINX」を利用して負荷分散装置を構築する手順は完了となる。

参考

• NGINXとは？ NGINXとNGINX Plusを徹底解説します

Linuxの設定情報を一括取得するスクリプト

ネットワーク機器などの設定値はshow runなどコマンド実行結果をテキストファイルとして残すことで、変更作業を行った前後のファイルでdiffツールによる比較を行うことができる。

OSの設定については、設定内容が多岐にわたるため、なかなかテキストファイルに残すといったことは難しく、都度コマンドを実行して情報を取得するというパターンが多い。
※Red Hat系のLinuxであれば、ログの取得ツールとしてsosreportがある。こちらは必要な設定やファイルを1つの圧縮ファイルにまとめるものとなり、設定の比較という観点では使いづらい。

そこで今回は、Red Hat系のLinuxの設定情報を1つのテキストファイルに出力し、一括取得するスクリプトを作ってみた。このスクリプトを使うことで、OSの設定に関しても、ネットワーク機器のように設定変更時の差分をdiffツールにて比較できるようにする。

環境

本スクリプトの動作確認をしたOSは以下の通り。Red Hat系のLinuxディストリビューションであるCentOS、AlmaLinux、Rocky Linuxでも動作するはずだ。

• OS : Red Hat Enterprise Linux 8 または 7
• 実行シェル : Bash

Linux設定項目一覧

本スクリプトで取得する設定項目は以下となる。

取得設定項目	取得設定内容
ホスト名・OSバージョン情報	OSのバージョン、カーネル番号、稼働時間など
ハードウェア情報	CPUのコアやソケット数、メモリ容量、PCIデバイス一覧
インストール設定	インストール時の設定 (/root/anaconda-ks.cfg)
OS基本設定	grub、kdump、SELinuxの設定
カーネルパラメータ	カーネルパラメータとシステムリソース制限(ulimit)設定
ネットワーク設定	各種ネットワーク関連設定。DNSやhostsファイルの設定を含む
ディスク設定	各種ディスク情報、LVM関連設定、fstabの設定
ユーザ・グループ設定	ユーザー一覧、グループ一覧、sudoの設定
sshd設定	sshdに関する設定
時刻設定	時刻同期 (Chrony) に関する設定
OS言語設定	使用している言語とインストール済み言語
サービス設定	systemdのサービス一覧
パッケージ設定	yum・dnfの設定、インストールされているrpm一覧
rsyslog設定	rsyslogに関する設定
logrotate設定	logrotateに関する設定
Postfix設定	Postfixに関する設定
Dovecot設定	Dovecotに関する設定
Squid設定	Squidに関する設定
Unbound設定	Unboundに関する設定
Apache (httpd) 設定	Apache (httpd) に関する設定
Zabbix Agent設定	Zabbix Agentに関する設定

PostfixやDovecotなどのソフトウェアについては、パッケージのインストール有無によって設定値の取得判断をする。これ以外にもインストールしているソフトウェアがある場合は、適宜追加するといったカスタマイズが必要となる。

スクリプト

今回作成したスクリプトはGitHubに置いてあるので、そちらを参照いただきたい。

• https://github.com/tech-mmmm/get_linux_config/blob/main/get_linux_config.sh

スクリプトには以下の関数を用意しており、効率よく設定値を取得できるようにしている。以下に関数の動作概要を記載する。

関数名	内容
show_title	取得対象の設定項目のタイトルを表示
get_command	コマンドを実行して、その結果を取得
get_config	設定ファイルからコメント(#から始まる行)及び空行を削除して内容を取得
get_config_files	ディレクトリを指定し、その中のファイル及びシンボリックリンクの内容を取得
check_install_package	パッケージのインストール状況を確認

使い方

任意のディレクトリに配置しroot権限にて以下の通り実行する。実行時間は環境にもよるが、10秒程度もあれば終了する。

# chmod +x get_linux_config.sh
# ./get_linux_config.sh

同じディレクトリ内に以下のファイル名でログが出力される。

[ホスト名]_config_[yyyyMMdd-HHmmss].log

情報取得結果のサンプル

以下に取得とした設定情報を例として記載する。コマンドによる情報取得の場合は(command)# [実行コマンド]、設定ファイルの情報取得の場合は(config)# [ファイルのフルパス]と表示することで、どのように情報取得をしたかわかるようにしている。

################################
情報取得開始 2022/05/22 11:55:25
################################

################################
ホスト名・OSバージョン情報
################################

(command)# uname -n
rhel8

(command)# uname -a
Linux rhel8 4.18.0-240.el8.x86_64 #1 SMP Wed Sep 23 05:13:10 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux

(config)# /etc/redhat-release
Red Hat Enterprise Linux release 8.3 (Ootpa)

(command)# uptime
 11:55:25 up 63 days, 20:09,  1 user,  load average: 0.00, 0.00, 0.00

～(中略)～

################################
ディスク設定
################################

(command)# ls -l /dev/?da*
brw-rw---- 1 root disk 8, 0  5月 22 10:51 /dev/sda
brw-rw---- 1 root disk 8, 1  5月 22 10:51 /dev/sda1
brw-rw---- 1 root disk 8, 2  5月 22 10:51 /dev/sda2
brw-rw---- 1 root disk 8, 3  5月 22 10:51 /dev/sda3

(command)# ls -l /dev/mapper/*
crw------- 1 root root 10, 236  3月 19 15:46 /dev/mapper/control
lrwxrwxrwx 1 root root       7  3月 19 15:46 /dev/mapper/rhel-root -> ../dm-0
lrwxrwxrwx 1 root root       7  3月 19 15:46 /dev/mapper/rhel-swap -> ../dm-1

(command)# fdisk -l
ディスク /dev/sda: 16 GiB, 17179869184 バイト, 33554432 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: A18174EE-DDA9-4DD9-8999-D1225E510848

デバイス   開始位置 終了位置   セクタ サイズ タイプ
/dev/sda1      2048  1230847  1228800   600M EFI システム
/dev/sda2   1230848  3327999  2097152     1G Linux ファイルシステム
/dev/sda3   3328000 33552383 30224384  14.4G Linux LVM

～(以下略)～

以上。

サービス監視スクリプト (Windows版)

サーバーのプロセス監視 (Windowsの場合はサービス監視) は、監視ソフトウェア(ZabbixやJP1など)を使えば当たり前のように実現できる。ただし、環境やライセンスの関係でエージェントの導入ができない場合がある。

そのような場合でも、スクリプトを使ってプロセス監視 (サービス監視) を行うことは可能となる。

今回、Windowsのサービス監視を行うスクリプトを作ってみたので、その内容を記載する。

なお、Linuxのプロセス監視のスクリプトについては、以下記事を参照いただきたい。

• プロセス監視スクリプト (Linux版)

実現方法

本スクリプトの設計概要を図示する。

このスクリプトは、確認対象のサービスを設定ファイル(check-service.conf)に記載しておき、Get-ServiceコマンドレットにてサービスがRunningステータスであるかどうかを確認する。

サービスダウンを検知した際は、Write-EventLogコマンドレットでApplicationイベントログにエラーメッセージを出力する。エラーメッセージ出力タイミングは、サービスダウンの初回発生時のみとし、それ以外は情報メッセージとして出力する。

以下に、本スクリプトで発生するメッセージを記載する。

サービス状態	メッセージ
正常時	[INFO] Service XXX up
正常状態継続時	[INFO] Service XXX still up
ダウン時	[ERROR] Service XXX down
ダウン状態継続時	[INFO] Service XXX still down

この処理をタスクスケジューラーで1分間隔で実行するよう登録し、定期的なサービス監視を実現する。

スクリプト実行手順

1. スクリプト実行前にイベントソースを登録

Windowsイベントログにイベントを出力する際に、事前にイベントソースの登録が必要となる。事前に管理者権限でPowerShellのプロンプトを開き、以下コマンドを実行しておくこと。

PS C:\> New-EventLog -LogName Application -Source "Service Check Script"

なお、イベントソースの登録削除は、以下のコマンドとなる。

PS C:\> Remove-EventLog -Source "Service Check Script"

2. スクリプト配置

以下にスクリプトのコードを記載する。GitHubにも配置してある。

• https://github.com/tech-mmmm/check-service-windows

スクリプトファイル：check-service.ps1

################
# Scripts name : check-service.ps1
# Usage        : ./check-service.ps1
#                同一ディレクトリにcheck-service.confを配置し、タスクスケジューラーで定期実行する。
#                事前にAdmin権限で以下コマンドをを実行すること。
#                New-EventLog -LogName Application -Source "Service Check Script"
# Description  : Windowsサービスチェックスクリプト
# Create       : 2022/05/02 tech-mmmm (https://tech-mmmm.blogspot.com/)
# Modify       : 
################

$currentdir = Split-Path -Parent $MyInvocation.MyCommand.Path
$conffile = $currentdir + "\check-service.conf"    # 設定ファイル
$tmpfile = $currentdir + "\check-service.tmp"      # サービス情報保存用一時ファイル
$event_source = "Service Check Script"             # スクリプトソース名

# すでにDownしているサービス情報を取得
if ( Test-Path -Path $tmpfile ){
    $down_service = Get-Content $tmpfile
}
Write-Output $null | Out-File $tmpfile

# 設定ファイル読み込み
foreach ($line in (Get-Content $conffile)) {   
    # コメント行と空行を処理しない
    if ( $line -notmatch "^ *#|^$" ){
        # 現在のサービス数を取得
        $count = (Get-Service -Name $line | Where-Object { $_.Status -eq "Running" }).count
        
        # サービス数チェック
        if ( $count -lt 1 ){
            # Down時の処理
            # Downしているサービスか確認
            if ( $down_service -eq $line ){
                # すでにDown
                $message = "Service """ + $line + """ still down"
                $event_type = "Information"
            }else{
                # 初回Down
                $message = "Service """ + $line + """ down"
                $event_type = "Error"
            }
            
            # イベントログに出力
            Write-Output $message
            Write-EventLog -LogName Application -EntryType $event_type -Source $event_source -EventId 100 -Message $message

            # Donwしているサービス情報を出力
            Write-Output $line | Out-File -Append $tmpfile
        }else{
            # Up時の処理
            # Downしていたサービスか確認
            if ( $down_service -eq $line ){
                # Downだった
                $message = "Service """ + $line + """ up"
                $event_type = "Information"                
            }else{
                # すでにUp
                $message = "Service """ + $line + """ still up"
                $event_type = "Information"
            }

            # イベントログに出力
            Write-Output $message
            Write-EventLog -LogName Application -EntryType $event_type -Source $event_source -EventId 100 -Message $message
        }
    }
}

exit 0

設定ファイル例：check-service.conf

# Service mame
Netlogon
W32Time
VMTools

3. タスクスケジューラーへの登録

タスクスケジューラーにて本スクリプトを1分間隔で実行するように設定する。こちらの方法については、以下別記事を参照いただきたい。

• タスクスケジューラーを使って1分間隔で実行するタスクを作成する方法

4. 監視テスト

実際にサービスを停止させて動作確認をしてみよう。W32Timeを停止させてサービス停止を検知することを確認してみる。

PS C:\> Stop-Service -Name W32Time
PS C:\> Get-EventLog -LogName Application -Source "Service Check Script"

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
   12652 5 03 06:27    Information Service Check Script          100 Service "VMTools" still up
   12651 5 03 06:27    Error       Service Check Script          100 Service "W32Time" down　　★停止を検知
   12650 5 03 06:27    Information Service Check Script          100 Service "Netlogon" still up
～(以下略)～

次に、復旧時の動作を確認する。

PS C:\> Start-Service -Name W32Time
PS C:\> Get-EventLog -LogName Application -Source "Service Check Script"

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
   12655 5 03 06:29    Information Service Check Script          100 Service "VMTools" still up
   12654 5 03 06:29    Information Service Check Script          100 Service "W32Time" up　★復旧
   12653 5 03 06:29    Information Service Check Script          100 Service "Netlogon" still up
～(以下略)～

以上。

更新履歴

• 2017/12/18 新規作成
• 2022/05/14 全体的にスクリプトの構成を見直し