運用自動化ツール

【RHEL系Linux】サーバーの障害検知と自動通知|systemdログ監視の実装例

RHEL系Linux環境でsystemdユニットのjournaldエラーログを常時監視し、差分検知でLINEやメールに自動通知する方法を解説します。

多重起動防止、PID管理、除外パターン設定など実用運用に必須の設計・実装・運用例を網羅します。

自動化運用ツール

🟡 自動化運用ツール
📌 面倒な作業を一括効率化!シェルスクリプトで実現する運用自動化術
├─ 基本共通
| ├─【Shellの基礎知識】簡単なログ出力ロジックを作ってみました。
| ├─【Shellの基礎知識】シェルスクリプトの作成を時短!テンプレートで効率化する方法
| ├─【Shellの基礎知識】共通関数定義クラスの完全ガイド!設計から実践まで徹底解説
├─ 開発環境構築
| ├─【RHEL系Linux】開発サーバー初期設定スクリプトの完全自動化
| ├─【RHEL系Linux】Apache+Let's Encrypt 自動構築スクリプト|バーチャルホスト対応
| ├─【RHEL系Linux】Tomcatを自動インストール・設定するスクリプトの作成と活用法
| └─【RHEL系Linux】PostgreSQLを自動インストールするシェルスクリプトの使い方
└─ 運用・保守
  ├─【RHEL系Linux】任意サービスを簡単制御!汎用サービススクリプトの活用術
  ├─【RHEL系Linux】ファイルやログを自動圧縮する汎用スクリプトの実装と活用法
  ├─【RHEL系Linux】リソース(CPU・MEM)監視スクリプトで使用率・異常を検知する仕組み
  ├─【RHEL系Linux】中間ファイル連携を完全制御するファイル転送スクリプト
  ├─【RHEL系Linux】信頼性を重視した完了保証型ディレクトリ転送スクリプトの設計と実装
  ├─【RHEL系Linux】ディスク使用率を自動監視するシェルスクリプトの実装
  └─【RHEL系Linux】サーバーの障害検知と自動通知|systemdログ監視の実装例

概要

Linuxサーバーの安定稼働を維持するには、障害発生時にいち早く検知し、迅速に対応する体制が必要です。本記事では、systemdのjournaldログを監視し、エラーログや警告をリアルタイムに検知してLINEまたはメールで通知する仕組みを構築します。

また、多重起動防止やPID管理、除外パターン設定など、運用環境にそのまま適用できる実装例を紹介します。

目的と背景

サーバー障害は、サービス停止やデータ損失など重大な影響を引き起こす可能性があります。特にデータベースやWebアプリケーションなど、常時稼働が求められるプロセスは、障害発生から復旧までの時間がビジネス継続に直結します。手動監視や定期的なログ確認では対応が遅れるため、systemdのjournaldログを自動で監視し、即時通知することで、復旧時間を短縮することを目的とします。

想定環境と前提条件

本記事で扱う構成は、以下の環境を前提としています。

項目内容
OSRHEL系Linux(RHEL、CentOS、Rocky Linuxなど)
監視対象systemd管理下のサービス(例:postgresql、Tomcat、Apache)など
通知方法LINE Messaging APIまたはメール
権限root権限での実行
依存スクリプトlogger.shrc、utils.shrc

適用範囲と制限事項

この監視スクリプトは、systemdによって管理されているサービスのjournaldログ監視に特化しています。そのため、systemd非対応のサービスや、外部のクラウド監視サービスとは直接連携できません。

また、通知方法はLINE Messaging APIとメール送信に限定しており、SlackやTeamsなど他のチャットツールへは標準では対応していません。除外パターンの設定や監視間隔の調整は可能ですが、監視対象が大量の場合は負荷が高くなる可能性があります。

設計・仕様

本章では、systemdのjournaldログを監視し、障害検知時にLINEまたはメールで通知する監視スクリプトの設計と仕様について説明します。ディレクトリ構成や引数仕様、通知の仕組みなど、運用時に必要となる要素を整理します。

ディレクトリ構成と配置ルール

スクリプトおよび関連ファイルは、以下のディレクトリ構成で配置します。この構成により、運用時の保守性と可読性を確保します。

ディレクトリ用途
scripts/bin実行スクリプト(send_alert.shなど)を配置
scripts/com共通関数・ライブラリ(logger.shrc、utils.shrcなど)を配置
scripts/etc設定ファイルや除外パターンファイルを配置
scripts/logスクリプトの実行ログを保存
scripts/tmpPIDファイルやロックディレクトリなど一時ファイルを保存

引数とオプション仕様

監視スクリプトは複数のモードとオプションを持ち、用途に応じた実行が可能です。

オプション説明必須
-m実行モード(start、stop、status、once、list)必須
-u監視対象のsystemdユニット名(例:postgresql-15)必須(list以外)
-t通知先(lineまたはmail、デフォルトはline)任意
-i監視間隔(秒、デフォルト60秒)任意(runモードで有効)

環境変数と設定ファイル構造

環境変数はホストごとに定義された.envファイルで管理します。このファイルにはLINEのAPIキーやメール送信先などの機密情報を格納します。

変数名用途
LINE_CHANNEL_ACCESS_TOKENLINE Messaging APIのアクセストークン
MAIL_TO通知メールの送信先アドレス

.env設定例

このファイルはホスト名ごとに etc/<ホスト名>/.envとして配置します。機密情報を含むため、アクセス権は600に設定してください。

LINE_CHANNEL_ACCESS_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MAIL_TO=admin@example.com

必要な場合は、Messaging APIのWebhook受信や署名検証機能を実装した際に追加してください。 

ロック機構とPID管理仕様

多重起動を防止するために、監視開始時に専用のロックディレクトリとPIDファイルを生成します。PIDファイルには実行中のプロセスIDを記録し、監視停止時に必ず削除します。ロックディレクトリの形式は「<ユニット名>.lock」とし、scripts/tmp配下に配置します。

これにより、同じユニット名での監視スクリプトの二重起動を防ぎ、異常終了時にも状態を確認できます。また、異常終了やシステム再起動後でもロックディレクトリとPIDファイルを参照することで、監視状態の復旧や調査が容易になります。

ログ出力仕様(logger.shrc準拠)

ログはすべてlogger.shrcを経由して出力します。ログレベルはINFO、DEBUG、ERROR、WARNなどを用意し、以下の形式で出力します。

logOut "INFO" "監視プロセスを起動しました"

これにより、全スクリプトで統一されたログ形式を維持し、運用時の解析を容易にします。

通知仕様(LINE・メール)

障害検知時の通知はLINE Messaging APIまたはmailコマンドで行います。LINEはAPIキーを用いたJSON送信で、スマートフォンなどに即時通知されるため、迅速な対応が可能です。

メール通知はシステムに標準搭載されたmailコマンドを利用しますが、今回はメールサーバーを構築するとセキュリティ設定(認証方式、暗号化設定、外部送信制限など)まで踏み込む必要があるため、運用の初期段階ではLINE通知を優先する方法を採用します。

これにより、障害発生時の検知速度を確保しつつ、構築・運用負荷を軽減します。

監視パターンと除外設定

監視対象のログは、journalctlコマンドで取得したsystemdユニットログとloggerタグ付きログを対象とします。エラー検出パターンは以下のキーワードを含みます。

キーワード説明
error一般的なエラー
fail失敗メッセージ
fatal致命的エラー
warning / warn警告メッセージ
killingプロセス強制終了

除外するログパターンは設定ファイルで定義し、監視対象から除外することで誤検知を防ぎます。

実装・ロジック

本章では、監視スクリプトの実装構造と処理の流れを解説します。全体処理のフローやモードごとの動作仕様、主要関数の役割、状態遷移と例外処理の設計を明確にすることで、運用時の理解と改修の容易さを確保します。

全体処理フロー

監視スクリプトは、起動から終了まで以下の流れで処理を行います。

処理段階概要
前処理ログ出力の初期化、引数解析、ロックディレクトリとPIDファイルの設定
引数検証モードやユニット名、通知先、監視間隔などの妥当性を確認
メイン処理指定されたモードに応じた関数を実行(常駐監視、単発監視、停止、一覧取得など)
終了処理ロック解除、終了ログ出力、正常終了コードの返却

モード別動作仕様(start・run・once・stop・list・status)

スクリプトは実行時のモードに応じて動作が変わります。

モード動作概要
startロック取得後、指定ユニットの存在確認を行い、-m runモードをバックグラウンド起動
run指定間隔で監視対象の稼働状態とjournaldログを確認し、障害検知時に通知します。
startモードから内部的に呼び出されるものであり、運用時に引数で直接指定して実行することはありません。
onceロックを取らずに単発でログ監視を行い、検知結果を通知
stopロックディレクトリとPIDファイルを確認し、実行中の監視プロセスを終了
list現在起動中の監視ジョブ一覧を取得し、稼働状況を表示
status指定ユニットの監視プロセス稼働状況を表示

主要関数の役割と処理概要

checkJournald関数では、検出したエラーメッセージを一時ファイルに保存し、前回送信時の内容と比較します。

同一内容であれば送信をスキップし、時刻だけを更新することで、同じ障害メッセージが連続送信されることを防ぎます。これにより、障害継続時の通知スパムを抑止し、通知の実効性を高めます。

スクリプトは複数の主要関数で構成され、それぞれの役割は以下の通りです。

関数名役割
checkArgs引数の妥当性を検証し、不正時はusageを表示して終了
acquireLock / releaseLockロックディレクトリとPIDファイルの生成・削除で多重起動を防止
checkUnitExistssystemctlの一覧から監視対象ユニットの存在を確認
startMonitor監視プロセスのバックグラウンド起動とPID保存
runMonitor監視ループの実行、プロセス稼働確認、ログ監視関数の呼び出し
onceMonitor単発でログ監視を行い、結果を通知
stopMonitor実行中の監視プロセスを終了し、ロックを解除
listMonitor稼働中の監視ジョブを一覧表示
checkJournaldjournaldログとloggerタグ付きログからエラー・警告を抽出し、必要に応じて通知
sendToLine / sendToMail検知した障害内容をLINEまたはメールで通知

状態遷移と例外処理設計

監視スクリプトは、以下の状態遷移を基本とします。

現在状態イベント次状態備考
未起動startモード実行監視中ロックディレクトリとPIDファイル生成
監視中障害検知監視中(通知後継続)通知送信後も監視を継続
監視中stopモード実行未起動プロセス終了、ロック解除
監視中異常終了未起動(ロック残存)次回起動時に残存ロックを確認し処理

例外処理としては、引数不正時の即時終了、監視対象が存在しない場合のエラーログ出力、通知先設定ミス時のエラー出力などを行います。これにより、誤動作や意図しない監視開始を防止します。

Linuxサーバー障害検知・自動通知スクリプト

設計・仕様および処理ロジックに基づき、障害検知と通知を行う監視スクリプトの全文を掲載します。

このスクリプトはRHEL系Linux環境でsystemd管理下のサービスを対象に動作し、journaldログの監視とLINEまたはメールによる通知を行います。

コード内には主要処理ごとにコメントを付与しており、そのままコピーして環境に合わせた設定を行えば実運用が可能です。

実行例・活用法

本章では、監視スクリプトを実際に運用するための手順と活用方法を解説します。初期設定から実行例、運用中のチューニング方法、そして障害発生時のトラブルシューティングまでをまとめています。

前提となる実行環境

Beエンジニアでシェルスクリプトを実行する環境は下記の通りとします。

実行環境

BASE_DIR(任意のディレクトリ)

  • scripts
    • bin(実行スクリプト格納領域)
      • <<各種実行スクリプト>>.sh (実行ファイル)
    • com(共通スクリプト格納領域)
      • logger.shrc(共通ログ出力ファイル)
      • utils.shrc(共通関数定義ファイル)
    • etc(設定ファイル等の格納領域)
      • infraMessage.conf(メッセージ定義ファイル)
    • log(スクリプト実行ログの格納領域)
      • スクリプト名.log 
    • tmp(テンポラリ領域)
    • rep(レポート出力領域)

初期設定と事前準備手順

スクリプトを運用する前に、環境構築と必要な設定を行います。ディレクトリ構成を作成します。

mkdir -p /home/user/projects/scripts/{bin,com,etc,log,tmp}

共通ライブラリを配置します。(logger.shrc、utils.shrc)監視スクリプト(send_alert.sh)をbinディレクトリに配置します。

ホスト名ごとの.envファイルをetc/<ホスト名>/配下に作成します。

LINE_CHANNEL_ACCESS_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx MAIL_TO=admin@example.com

実行権限を付与します。

chmod +x /home/user/projects/scripts/bin/send_alert.sh

基本的な実行例

監視スクリプトは複数のモードで利用できます。主な実行例を以下に示します。

目的コマンド例
常駐監視を開始sh bin/send_alert.sh -m start -u postgresql-15 -t line -i 60
監視状態を確認sh bin/send_alert.sh -m status -u postgresql-15
常駐監視を停止sh bin/send_alert.sh -m stop -u postgresql-15
単発監視を実行sh bin/send_alert.sh -m once -u postgresql-15
監視ジョブ一覧を表示sh bin/send_alert.sh -m list

運用時のチューニングと負荷対策

運用環境に合わせて以下の項目を調整することで、監視精度と負荷のバランスを取ることができます。

項目推奨設定例目的
監視間隔(-i)60秒負荷を抑えつつ障害検知までの遅延を最小化
ログ取得件数直近15分不要な過去ログの検出を防止
除外パターン設定etc/exclude_patterns_send_alert.conf誤検知や不要な通知の抑止

また、不要な監視対象や冗長な通知を削減することでシステム全体の負荷を軽減できます。

トラブルシューティングとFAQ

運用中によく発生する問題とその対処方法をまとめます。

症状原因対処方法
監視が開始できないロックディレクトリが残存しているscripts/tmp配下の該当.lockディレクトリを削除
通知が届かないLINEアクセストークンが誤っている.envファイルの設定を確認し、再取得
メール通知が送信されないメールサーバーが未設定または制限中postfixなどのMTA設定を確認、またはLINE通知に切り替え
同じ障害が何度も通知される過去メッセージの比較ファイルが削除されているcheckJournaldのlastメッセージ保存機能を確認
本サイトにて記載のすべてのスクリプト利用により発生した利用者の損害全てに対し、いかなる責任をも負わないものとし、損害賠償をする一切の義務はないものとします。また、この記事は、実際の案件対応を通じて得た知見をもとに筆者が作成したものであり、全コードと解説は著者本人による設計・検証結果に基づいています。

よく読まれている記事

1

「シェル」と「シェルスクリプト」という言葉を聞いたことがありますか?どちらもLinuxやMacのターミナルで使われるものですが、それぞれの役割や使い方には違いがあります。 本記事では、「シェル」と「シ ...

2

「私たちが日々利用しているスマートフォンやインターネット、そしてスーパーコンピュータやクラウドサービス――これらの多くがLinuxの力で動いていることをご存じですか? 無料で使えるだけでなく、高い柔軟 ...

3

この記事は、Linuxについて勉強している初心者の方向けに「Shellスクリプト」について解説します。最後まで読んで頂けましたら、Shellスクリプトはどのような役割を担っているのか?を理解出来るよう ...

-運用自動化ツール