現場で使えるシェルスクリプト入門23：loggerコマンドによるOSシステムログ連携の実践

シェルスクリプト IT

前回、前々回の記事（入門21・22）で、リダイレクト（>>）を使ってスクリプト専用の「独自ログファイル」へ実行履歴を保存し、cron による定期自動実行と組み合わせる手法を習得しました。

スクリプトごとに専用のログファイルを用意して処理結果や詳細データを書き出す方法は、中身を直接確認しやすく、独立したバッチ処理を構築する上で広く使われている定番のアプローチです。

一方で、サーバー全体の運用やシステム監視を見据えたとき、もう1つの選択肢となるのが「OS標準のシステムログ基盤（syslog / systemd-journald）への統合」です。
Linux環境には、シェルスクリプトからOSのシステムログへ直接メッセージを届ける標準コマンド「logger（ロガー）」が用意されています。

今回は、独自ログファイルの良さを活かしつつ、スクリプトの実行状況やエラーをOS側へ適切に通知できる logger コマンドの基本構文から、監視に役立つタグ付け・優先度設定、そして両者を組み合わせた実践的な併用パターンまでを分かりやすく解説します！

独自ログとシステムログの役割・使い分け

シェルスクリプトの出力先を考える際、「独自ログファイル」と「OS側システムログ」にはそれぞれ異なる強みがあります。

比較項目独自ログファイル（リダイレクト）OS側システムログ（logger）
主な記録先./logs/app.log など任意のファイル/var/log/messages、journalctl など
得意な用途処理の詳細明細、入出力データ、業務ロジックの追跡サーバー全体の稼働状況、障害・エラーの検知
管理単位スクリプトやプロジェクトごとの自己完結OS全体で一元管理（集中管理）
監視連携ログファイルを個別に指定して監視OS標準の監視ツールや統合ログ監視基盤（SIEM）へ自動連携

※SIEM（シーム）：Security Information and Event Managementの略。サーバーやネットワーク機器など、組織内の様々な機器から出力されるログを一か所に集約し、一元的に分析・監視する統合セキュリティ基盤のこと。

どちらか一方だけが優れているわけではありません。「詳細な処理内容はスクリプト専用の独自ログに残し、運用担当者へ知らせたい重要エラーやタスク完了の合図は logger でOS側へも通知する」といった両者の併用が効果的です。

loggerコマンドの基本とメッセージの保存先

logger は、シェルスクリプトやコマンドラインからシステムロギングデーモン（rsyslogd や systemd-journald）へメッセージを送信するための標準コマンドです。

# シンプルな実行例
logger "バックアップ処理を開始しました"

上記のように実行するだけで、OSのログ管理デーモンへメッセージが渡されます。送信されたメッセージは、OSの環境に応じて主に以下の場所に記録されます。

  • Red Hat系（RHEL / AlmaLinux / Rocky Linuxなど）：
    通常は /var/log/messages に記録されます。
  • Debian / Ubuntu系：
    通常は /var/log/syslog に記録されます。
  • systemd導入環境（近年のLinux全般）：
    journalctl コマンドでリアルタイムに確認・検索できます。

ログの分類と重要度（ファシリティとプライオリティ）

システムログには多種多様なログが混ざり合うため、メッセージの「発生元（ファシリティ）」と「深刻度（プライオリティ）」を明示して送信します。これらは -p オプションで ファシリティ.プライオリティ の形式で指定します。

# 例: userファシリティ、infoレベルで出力
logger -p user.info "定期データ集計が完了しました"

# 例: local0ファシリティ、errレベルで出力
logger -p local0.err "データベース接続に失敗しました"

主なファシリティ（Facility）

メッセージの種別や出所を示します。シェルスクリプトでは主に以下が利用されます。

  • user：一般的なユーザープロセスからのメッセージ（省略時のデフォルト）。
  • local0 〜 local7：管理者が自由に用途を決めて良いカスタム枠。社内スクリプトや特定業務アプリケーションでよく活用されます。

主なプライオリティ（Priority / Severity）

ログの重要度・深刻度を表します。代表的なレベルは以下の通りです。

レベル名意味活用例・使いどころ
info一般情報処理の正常開始・完了通知など
notice通常だが注意すべき情報設定の変更、主要処理の切り替えなど
warning警告処理は続行できるが確認が望ましい事象（リトライ発生など）
errエラー処理が中断・失敗した致命的な事象（ファイル不在、通信失敗など）

適切にプライオリティを設定しておくと、後述する監視ツールで「err レベルのメッセージのみを検知して担当者へ通知する」といったアラート運用の設定がしやすくなります。

現場で役立つloggerオプション

logger コマンドを活用する際、よく使われる主要な3つのオプションを紹介します。

タグ付け（-t）によるログ監視とスクリプトの特定

OSログには、カーネルや各種デーモン、他のスクリプトなど、膨大なログが同時に集約されます。オプションを指定せずに実行すると、実行ユーザー名などしか付与されず、「どのスクリプトが出力したメッセージなのか」を特定するのが難しくなります。

そこで -t オプションを使い、スクリプト名などの識別用タグを明示します。

# タグ「backup_task」を付与して出力
logger -t "backup_task" -p user.info "設定ファイルのバックアップを開始"

タグ付けを行うことで、以下のメリットが得られます。

  • 障害発生時のスクリプト特定：
    エラーが発生した際、膨大なログの中から問題の発生元スクリプトを特定しやすくなり、初動調査の手間を軽減できます。
  • ログ監視システムでの検知：
    Zabbix、Datadog、CloudWatchなどの運用監視ツールで、「タグ backup_task かつ重要度 err」といった条件を設定することで、特定業務のアラート通知を的確に自動化できます。

プロセスIDの記録（-i のメリットとスクリプトPIDの活用）

ログにプロセスID（PID）を記録しておくと、同じ処理が並行して実行された場合でも、どの実行インスタンスが出力したメッセージなのかを識別できます。

logger でPIDを記録する基本的な方法として -i オプションがあります。指定するだけでSyslog標準のフォーマットに従って自動的にPIDが付与されます。
ターミナルからの実行や、cronで単発コマンドの実行結果をパイプラインで流し込むようなケースでは、変数展開などを記述することなくプロセス情報を付加できる利点があります。

なお、-i は「実行された logger コマンド自身」のPIDを記録します。そのため、1つのシェルスクリプト内で複数回 logger -i を呼び出すと、行ごとに異なる子プロセスのPIDが付与されます。
「スクリプト全体の開始から終了までを一貫して同じ親プロセスのPIDで追跡したい」という場合は、シェルスクリプト自身のプロセスID（特殊変数 $$）をタグ名に含めるアプローチ（または環境に応じた --id=$$）を併用すると、さらに管理しやすくなります。

# -i オプションでPIDを自動付与（単発実行など）
logger -i -t "api_sync" -p user.info "データ同期タスクを実行"

# スクリプト全体の実行を一貫したPIDで追跡したい場合（$$ をタグに付与）
logger -t "api_sync[$$]" -p user.info "処理開始"
logger -t "api_sync[$$]" -p user.info "処理完了"

標準エラー出力への同時表示（-s）

-s オプションを付けると、システムログへメッセージを送信すると同時に、端末の標準エラー出力（画面）にも同じ内容を表示してくれます。
「ターミナルで手動テストするときは画面で確認し、本番のバックグラウンド実行時はOSログにしっかり残す」という動作が1つのコマンドで実現できます。

# 画面に表示しつつ、OSシステムログにも記録
logger -s -t "deploy_tool" -p user.notice "デプロイ作業を開始します"

実践：独自ログとシステムログを併用するロギング関数

「独自ログへの詳細出力」と「loggerによるOS側への通知」を併用したサンプルスクリプト（smart_backup.sh）です。

#!/bin/bash
set -euo pipefail

# スクリプト自身のディレクトリへ移動
cd "$(dirname "$0")" || exit 1

# スクリプト名からタグを自動設定
TAG_NAME="$(basename "$0")"

# 独自ログファイルの配置準備
CUSTOM_LOG_DIR="./logs"
mkdir -p "${CUSTOM_LOG_DIR}"
CUSTOM_LOG_FILE="${CUSTOM_LOG_DIR}/backup_detail.log"

# 独自ログ出力用関数（詳細な処理経過を独自ファイルへ記録）
log_custom() {
    local level="$1"
    local message="$2"
    local timestamp
    timestamp=$(date +'%Y-%m-%d %H:%M:%S')
    echo "[${timestamp}] [${level}] ${message}" >> "${CUSTOM_LOG_FILE}"
}

# システムログ通知用関数（OS監視基盤へ連携）
# ※タグにスクリプト自身のPID（$$）を付与し、一連の実行を一貫して追跡
syslog_notify() {
    local priority="$1"
    local message="$2"
    logger -t "${TAG_NAME}[$$]" -p "user.${priority}" "${message}"
}

# --- 処理開始 ---
log_custom "INFO" "定期バックアップタスクを開始します。"
syslog_notify "info" "定期バックアップタスクを開始しました。"

# バックアップ対象の確認
TARGET_FILE="./config.env"
BACKUP_DIR="./backups"
mkdir -p "${BACKUP_DIR}"

if [ -f "${TARGET_FILE}" ]; then
    BACKUP_NAME="${BACKUP_DIR}/config_backup_$(date +'%Y%m%d_%H%M%S').tar.gz"
    tar -czf "${BACKUP_NAME}" "${TARGET_FILE}"
    
    # 正常終了時：独自ログにファイル名を詳細記録、OSログには完了を通知
    log_custom "INFO" "アーカイブを作成しました: ${BACKUP_NAME}"
    syslog_notify "info" "定期バックアップが正常に完了しました。"
else
    # 異常発生時：独自ログに原因を記録し、OSログへerrでアラート送信
    log_custom "ERROR" "対象ファイル ${TARGET_FILE} が存在しません。"
    syslog_notify "err" "バックアップ失敗: 対象ファイル ${TARGET_FILE} が見つかりません。" >&2
    exit 1
fi

このスクリプトでは、以下の設計を採用しています。

  • スクリプト名とPIDの自動タグ化：${TAG_NAME}[$$] により、スクリプト名に加えて実行中のスクリプト自身のPID（$$）をタグに埋め込んでいます。これにより、並行して複数動く環境でも、どの実行インスタンスのログかを一貫して追跡できます。
  • 役割の明確な分担：作成されたアーカイブファイル名などの詳細な業務データは「独自ログファイル」へ記録し、システムの死活監視や運用チームが検知すべき状態（開始・完了・失敗）は「OSシステムログ」へ通知しています。

記録されたログの確認と検索方法

スクリプトを実行した後は、OS側で正しくメッセージが受領されているかを確認します。

journalctlコマンドによるログの絞り込み（推奨）

近年のLinux環境では、journalctl コマンドを使うことで、付与したタグをキーにしてログを抽出できます。

# タグ「smart_backup.sh」のログだけを抽出
journalctl -t "smart_backup.sh"

# エラーレベル（err）のみを絞り込んで障害調査
journalctl -t "smart_backup.sh" -p err

# リアルタイムにログ出力を追跡（監視）
journalctl -t "smart_backup.sh" -f

タグを指定することで、OS全体のログから該当スクリプトの出力のみを抽出でき、トラブル調査の初動対応を進めやすくなります。

ログファイルから確認する場合

従来のsyslog環境やファイルベースで確認したい場合は、grep コマンドでタグ名を検索します。

# Red Hat系の場合
grep "smart_backup.sh" /var/log/messages

# Debian / Ubuntu系の場合
grep "smart_backup.sh" /var/log/syslog

まとめ

今回は、Linux環境でOS標準のログ基盤と連携する「logger コマンド」の基本から、タグ付けによる障害特定の利点、ファシリティ・優先度の設定、独自ログとの併用パターンまでを解説しました。

  • 独自ログとシステムログの併用：業務詳細を追跡する独自ログファイルと、システム全体で監視するOSログのそれぞれの強みを組み合わせる。
  • タグ付け（-t）の活用：膨大なシステムログの中から発生元スクリプトを特定しやすくし、監視ツールでのアラート連携を円滑にする。
  • 重要度（プライオリティ）の活用：info や err などを適切に使い分け、障害検知の初動を迅速化する。

リダイレクトによる独自ログと、logger によるOSログ連携という2つの手法を理解しておくことで、目的に応じた柔軟なログ設計が可能になります。スクリプトの規模や運用の要件に合わせて、適切なロギング手法を選択してみてください。

コメント

タイトルとURLをコピーしました