課題:障害発生時に各サーバーへSSHログインして調査する悪夢
管理しているインフラで10台のサーバーが稼働しているとします。Nginx Webノード3台、バックエンドAPIクラスタ2台、PostgreSQLデータベース、そしてゲートウェイ2台です。午後3時、決済処理でユーザーから502エラーが多発しているという連絡が入りました。急いでターミナルを何枚も開き、各サーバーでtail -f /var/log/nginx/error.logを実行してリクエストIDをgrepします。しかし、この作業は煩雑で視認性が悪く、重要なエラーを見落とすリスクも高まります。
サーバー台数が30台、50台と増えるにつれ、このような手作業での調査は完全に限界を迎えます。集中ログ管理がない環境では、根本原因の特定にかかる平均時間(MTTR)が数分から数時間へと大幅に延びてしまいます。すべてのログデータを単一の場所に集約し、たった1つのクエリで即座に検索できる環境が必要です。
Graylogクラスタのアーキテクチャ
Graylogはデータ受信センターのように機能します。システム全体のあらゆる場所からログを収集し、フィールド情報をパース(抽出)して、インデックス付きのデータストアに保存します。
完全なGraylogクラスタは、以下の3つのコンポーネントで構成されます。
- MongoDB: システム設定、ユーザー情報、アラートストリーム、ダッシュボードのメタデータを保存します。ログ本文そのものは保存しません。
- OpenSearch: ログの保存と全文検索クエリの処理を担う中核コンポーネントです。数百万行のログを高速にフィルタリングできるかどうかは、OpenSearchに割り当てられたRAM容量に直接依存します。
- Graylog Server: ログ処理の中心となるサービスです。クライアントからSyslog/GELF/Beats経由でログを受信し、構文解析(パース)を行い、OpenSearchへデータを転送するとともに、Web UIを提供します。
CentOS Stream 9でのGraylog構築手順
ステップ 1: 環境の準備とJava OpenJDKのインストール
GraylogとOpenSearchはいずれもJVM上で動作します。CentOS Stream 9では、標準リポジトリで提供されているOpenJDK 17をそのまま利用します。
sudo dnf update -y
sudo dnf install -y java-17-openjdk-headless pwgen wget curl lsof
ステップ 2: MongoDB 6.0のインストール
Graylog 6.xにはMongoDB 6.0以上が必要です。MongoDB用のリポジトリ設定ファイルを作成します。
cat <<EOF | sudo tee /etc/yum.repos.d/mongodb-org.repo
[mongodb-org-6.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/9/mongodb-org/6.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc
EOF
sudo dnf install -y mongodb-org
sudo systemctl daemon-reload
sudo systemctl enable --now mongod
systemctl status mongodコマンドを実行し、サービスがactive (running)状態であることを確認します。
ステップ 3: OpenSearch 2.xのインストールと最適化
OpenSearchの公式リポジトリを登録します。
cat <<EOF | sudo tee /etc/yum.repos.d/opensearch.repo
[opensearch-2.x]
name=OpenSearch 2.x Repository
baseurl=https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/yum
gpgcheck=1
gpgkey=https://artifacts.opensearch.org/publickeys/opensearch.pgp
enabled=1
EOF
sudo dnf install -y opensearch
/etc/opensearch/opensearch.ymlを開き、シングルノード構成用に設定を更新します。
cluster.name: graylog-cluster
node.name: node-1
path.data: /var/lib/opensearch
path.logs: /var/log/opensearch
network.host: 127.0.0.1
http.port: 9200
discovery.type: single-node
action.auto_create_index: false
plugins.security.disabled: true
8GB RAMのサーバーの場合、/etc/opensearch/jvm.options内のJVMヒープサイズを-Xms4gおよび-Xmx4g(システムRAMの約50%)に設定することをおすすめします。設定後、サービスを起動します。
sudo systemctl daemon-reload
sudo systemctl enable --now opensearch
ステップ 4: Graylog Serverのインストールと設定
Graylog 6.0のリポジトリとパッケージをインストールします。
sudo rpm -Uvh https://packages.graylog2.org/repo/packages/graylog-6.0-repository_latest.rpm
sudo dnf install -y graylog-server
Graylogの起動には、以下の2つのシークレット文字列が必要です。
password_secret: ユーザーのセッションCookieを暗号化するために使用します。root_password_sha2:adminアカウントのSHA-256ハッシュ化パスワードです。
ターミナルでこれら2つの文字列を生成します。
# 96文字のランダムなシークレットキーを生成
pwgen -N 1 -s 96
# 管理者パスワードをハッシュ化(MatKhauAdmin@2026をご自身のパスワードに変更してください)
echo -n "MatKhauAdmin@2026" | sha256sum | cut -d" " -f1
/etc/graylog/server/server.confを開き、生成した値をそれぞれ貼り付けます。
password_secret = <生成したpwgenの文字列>
root_password_sha2 = <生成したsha256の文字列>
http_bind_address = 0.0.0.0:9000
ファイルを保存し、Graylogを有効化して起動します。
sudo systemctl daemon-reload
sudo systemctl enable --now graylog-server
ステップ 5: ファイアウォールの設定とWeb UIの確認
Webインターフェース用のポート9000と、クライアントからログを受信するためのポート1514 UDPを開放します。
sudo firewall-cmd --add-port=9000/tcp --permanent
sudo firewall-cmd --add-port=1514/udp --permanent
sudo firewall-cmd --reload
ブラウザを開き、http://<サーバーIP>:9000にアクセスします。ユーザー名adminと、ステップ4でハッシュ化する前に設定した平文パスワードでログインします。
ステップ 6: Inputの作成とクライアントからのログ転送設定
GraylogのWeb UI上でログ受信用ポートを設定します。
- System > Inputsにアクセスします。
- ドロップダウンからSyslog UDPを選択し、Launch new inputをクリックします。
- Titleに
Linux Syslog Input、Portに1514、Bind addressに0.0.0.0を入力してSaveをクリックします。
監視対象のクライアントサーバーに切り替えます。Graylogサーバーへログを転送するようにrsyslogの設定を追加します。
echo "*.* @<GRAYLOG_SERVER_IP>:1514;RSYSLOG_SyslogProtocol23Format" | sudo tee /etc/rsyslog.d/50-graylog.conf
sudo systemctl restart rsyslog
GraylogのSearchタブに戻ると、クライアントからのログがリアルタイムで受信されていることを確認できます。
まとめ
集中ログ管理システムを導入することで、各ターミナルに個別に接続してログを探し回る手間から解放されます。GraylogとOpenSearchを活用すれば、認証ログ、カーネルログからアプリケーションログまでが一元管理され、障害調査やTelegram/Slackを通じた自動アラート通知の設定もスムーズに行えます。

