ログ監視の最小構成：rsyslog+logrotate+スクリプトで始める

本格的ログ監視システムの矛盾

rsyslog はOpenTelemetry (OTLP)ネイティブ出力モジュールを備え、OTLP/HTTPでJSON形式での直接ログ出力に対応するなど、現代的なログ基盤へと進化しています。一方、多くの組織では「包括的なログ管理を望みながら、導入の複雑さに二の足を踏んでいる」という実態があります。本格的なELK Stack や Grafana Loki、Splunk といったプラットフォームは、強力ですが、インストール・設定・保守のコストが見過ごされやすい落とし穴です。

実は、Linux 標準ツール 3 つの組み合わせだけで、実用的でかつ堅牢な監視環境を構築できます。それが rsyslog、logrotate、そしてシンプルな通知スクリプトです。

標準ツールの組み合わせが「なぜ」実務的か

#### 1. rsyslog が変わった：マルチコアスケーリングの革新

従来、TCP 取り込みは単一の実行パスに依存していましたが、最新のrsyslogではこの設計が全面的に見直され、複数のワーカースレッドでワークロードを分散することで、モダンハードウェアで最大限の並列処理が可能になりました。これにより、100 サーバー規模でも単一の rsyslog インスタンスで捌ける可能性が高まっています。

特に重要なのは、rsyslog が従来のシステムログプロセッサから、クラウドネイティブデータプラットフォームへの橋渡しへと進化し、OpenTelemetry出力モジュールにより、生イベントの取り込み、標準化と充実化、効率的なバッチ処理での配信が可能に。つまり、本来は大規模システム向けと思われるモダン監視への「入口」が、すでにrsyslogに統合されているのです。

#### 2. 落とし穴：ディスク満杯がもたらす代償

ログファイルが急速に増大し、過度なディスク領域を消費する可能性があり、logrotate などのツールを使用した回転、圧縮、保持数の制限は、ディスク枯渇を防止してシステム安定性を維持するために必須です。ここで見落とされやすいのが、自動回転なしでも1週間で500GB に達する環境が珍しくないという事実。単一の不具合ログループが実運用を停止させる事例が後を絶ちません。

#### 3. シンプルさがもたらす信頼性

複数サーバー・複数サービスからの集約ログを処理する環境では、中央集約型ログプラットフォムの採用は、もはやオプショナルではなく、本番システムの基本要件とさえ言われます。しかし、この「基本要件」を満たすために、新しいサービスを導入する必要はありません。rsyslog のimtcp入力モジュールの性能向上により、マルチスレッド処理が実装され、真のマルチスレッド処理が可能だからです。

最小構成の3つの層

#### 層1：ログ収集（rsyslog）

rsyslog は多くのRed Hat系ディストリビューションでデフォルトで付属し、元々のsyslog デーモンの改良版で、高速なログ処理と IP ネットワーク内のいかなるロケーションへのログ転送機能を備えているため、別途インストール不要な環境がほとんどです。設定は /etc/rsyslog.conf と /etc/rsyslog.d/ 内のファイルで一元管理できます。

#### 層2：ログローテーション（logrotate）

logrotate は Linux ユーティリティでログをローテーション（回転）するのが中核機能で、シンプルながら強力なオープンソースローテーション機能を提供します。デフォルト設定で多くの環境に適応し、カスタマイズも容易です。

#### 層3：実時間アラート（シェルスクリプト+cron）

上記2層はいずれも「ログの取得・保管」のみです。異常検知と通知は別のレイヤーが必要。ここが多くの組織で「導入に次ぐ導入」を招く原因ですが、実は数行のシェルスクリプト + cron で十分な場合が大多数です。

実装例：エラーレート監視

ここに、直近1時間のアプリケーションエラーを検知し、しきい値超過で通知するシンプルなスクリプトを示します：

#!/bin/bash

LOG_FILE="/var/log/myapp.log"
ERROR_THRESHOLD=100
HOURS=1
EMAIL="admin@example.com"

# 直近N時間のエラー件数をカウント
ERROR_COUNT=$(journalctl --since "${HOURS} hours ago" \
  --grep="ERROR" --output=short-iso | wc -l)

if [ "$ERROR_COUNT" -gt "$ERROR_THRESHOLD" ]; then
  SUBJECT="Alert: ${ERROR_COUNT} errors in the last ${HOURS} hour(s)"
  BODY="Error count exceeded threshold.\nThreshold: ${ERROR_THRESHOLD}\nActual: ${ERROR_COUNT}"
  
  echo -e "$BODY" | mail -s "$SUBJECT" "$EMAIL"
  logger "ERROR_ALERT: ${ERROR_COUNT} errors detected"
fi

このスクリプトを /etc/cron.d/log_monitor に登録し、30分ごとに実行：

*/30 * * * * root /usr/local/bin/check_errors.sh

特筆すべきは、この構成でも 多くの組織にとって90日間のログ保持が基準ラインですが、PCI DSSのような規制基準では最低1年間のログ保持が必須という、規制要件への対応が「logrotate の設定だけ」で実現できる点です。

隠れたパフォーマンス詩学：バッファサイズの誤解

多くの管理者がスキップするのが rsyslog のバッファ調整です。rsyslogのバッファはデフォルト128kで設定されており、これより大きいログは切り詰められるという致命的な制限があります。JSON 形式の構造化ログやバイナリデータを扱う環境では、デフォルトが「ログ損失の罠」になっている。以下で対応できます：

# /etc/rsyslog.conf に追記
$MaxMessageSize 64k

さらに高いスループットが必要な場合、ディスク支援キューはメモリキューとディスクキューの利点を組み合わせ、通常運用では非常に高速で、必要に応じて無制限のメッセージバッファリング（実質的にはディスク容量で制限）と、rsyslogd再起動時のデータ永続化が可能です。

次に何をするか

この最小構成で「なぜ十分か」の答えは、運用スケールにあります。3層構成は単一サーバーから数百台規模まで線形スケールし、追加のインフラ投資なしに適応可能です。本格的なログ集約が必要になった時点で、rsyslog の出力をリモートサーバーに転送するか、OTLP モジュールで直接 Grafana Loki や OpenTelemetry コレクタに統合させれば十分。「先への道」が、すでに標準ツールに組み込まれているのです。