Tech

【OSSでWiki構築】第12回:監視・ログ編

公開

【OSSでWiki構築】連載記事一覧
第1回
第2回:環境構築編
第3回:環境構築編 トラブルシューティング
第4回:Google OAuth編
第5回:Google OAuth編 トラブルシューティング
第6回:アクセス制御編
第7回:アクセス制御編 トラブルシューティング
第8回:日本語対応編
第9回:日本語対応編 トラブルシューティング
第10回:データ保全・バックアップ編
第11回:データ保全・バックアップ編 トラブルシューティング
第12回:監視・ログ編※本記事


1. はじめに

この記事は、安定したWiki運用に不可欠な「システム監視」と「ログ調査」の仕組みを構築する手順をまとめたものです。
障害発生時に「何が起きているか」を迅速に把握するための、コマンドラインおよびGUI(ダッシュボード)での監視体制を確立します。

ステップ1: コマンドラインでのログ調査

トラブルシューティングの基本となる、Dockerコマンドを使ったログ確認方法です。

1-1. 過去のログを確認する

特定のコンテナ(サービス)の過去のログを表示します。

# Caddy(Webサーバー)のログを見る場合
docker compose logs caddy

1-2. リアルタイムでログを監視する (f オプション)

今まさに書き込まれているログをリアルタイムで表示し続けます。障害発生の瞬間を捉えるのに最適です。

docker compose logs -f caddy

※ 監視を終了するには Control + C を押します。

【Tips】: Caddyなどのミドルウェアは、デフォルトではアクセスログを出力しない設定になっている場合があります。開発・検証段階では詳細なログが必要なため、設定ファイル(Caddyfileなど)でログ出力を有効化(log { output stdout })することが重要です。

ステップ2: 自動健康診断(Healthcheck)の理解

システムが正常に稼働しているかを自動判定する仕組みについてです。

2-1. コンテナの健康状態を確認する

以下のコマンドで、コンテナの状態(STATUS)を確認できます。

docker compose ps
  • (healthy): 健康診断に合格し、正常に稼働中。
  • (unhealthy): 健康診断に失敗し、異常が発生している。
  • (health: starting): 起動直後で、まだ診断中。

2-2. OutlineのHealthcheck仕様

Outlineの公式Dockerイメージには、デフォルトで最適な健康診断の仕組みが組み込まれています。
独自に設定を追加しなくても、自動的に内部的な接続確認が行われ、正常であれば healthy と表示されます。基本的にはこの公式設定を利用するのが推奨されます。

ステップ3: ログ監視ダッシュボード(Dozzle)の導入

ターミナルだけでなく、ブラウザから視覚的に全コンテナのログを監視・検索できるツール「Dozzle」を導入します。

3-1. docker-compose.yml への追加

docker-compose.yml に以下のサービス定義を追加します。

  # ログ監視ダッシュボード
  dozzle:
    image: amir20/dozzle:latest
    restart: unless-stopped
    volumes:
      # Dockerソケットをマウントし、他のコンテナのログを読み取れるようにする
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      # ブラウザからポート8888でアクセス
      - 8888:8080
    # 【本番運用時の注意】
    # ログには機密情報が含まれるため、必ずBasic認証などを設定する
    # environment:
    #   DOZZLE_USERNAME: admin
    #   DOZZLE_PASSWORD: secure_password

3-2. 動作確認

  1. コンテナを起動します:docker compose up -d
  2. ブラウザで http://localhost:8888 にアクセスします。
  3. 画面左側のメニューから各コンテナを選択し、リアルタイムでログが表示されることを確認します。
  4. ブラウザの検索機能(Cmd+F / Ctrl+F)などを使い、特定のキーワード(例: error, handled request)でログを素早く特定できることを確認します。

まとめ

コマンドラインによる詳細な調査と、ダッシュボードによる俯瞰的な監視、そしてヘルスチェックによる自動診断。これらを組み合わせることで、トラブルの予兆を検知し、迅速に原因を特定できることが可能になりました。


前の記事:第11回:データ保全・バックアップ編 トラブルシューティング
次の記事:準備中

【OSSでWiki構築】連載記事一覧
第1回
第2回:環境構築編
第3回:環境構築編 トラブルシューティング
第4回:Google OAuth編
第5回:Google OAuth編 トラブルシューティング
第6回:アクセス制御編
第7回:アクセス制御編 トラブルシューティング
第8回:日本語対応編
第9回:日本語対応編 トラブルシューティング
第10回:データ保全・バックアップ編
第11回:データ保全・バックアップ編 トラブルシューティング
第12回:監視・ログ編※本記事

J.B. K.Shinada

.Engineering

HTML/CSS/JavaScriptを用いたWebサイトの実装を担当しています。
現在は業務の幅を広げるため、バックエンド領域のキャッチアップに取り組んでいます。