Posted inホームラボ

HomeLab向け集中型ログ管理：Grafana Lokiですべてを監視

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

HomeLab監視の迷路：現実世界の問題

長年、私のHomeLabの管理は、ログとの絶え間ないかくれんぼのようなものでした。Jellyfinのようなメディアサーバー用のDockerコンテナ、開発環境用の仮想マシン、さらにはデータを出力する多数のIoTデバイスなど、さまざまなサービスを運用しています。各サービスとデバイスは独自のログストリームを生成し、これらのログは、多くの場合、異なるディレクトリに隠されたり、さまざまなファイル形式であったり、特定のコマンドを介してのみアクセス可能でした。

コンテナのクラッシュ、アプリケーションの異常動作、ネットワークの問題など、何か問題が発生した場合、診断プロセスは、数十のログファイルを手動で探し回る苦痛なものでした。異なるマシンにSSHで接続し、そこでログを`tail -f`したり、エラーを`grep`したりして、一貫した全体像を組み立てようとしました。この断片的なアプローチは非効率的であるだけでなく、問題が顕在化してかなりの時間が経過してから対処する、受動的な対応を意味することがよくありました。これは、より良い解決策が必要であるという明確な兆候でした。

根本原因分析：分散ログが頭痛の種となる理由

ログが散在していることの核心的な問題は、集中管理された可視性と相関関係が根本的に欠如している点に尽きます。すべてのコンポーネントが独自のサイロで動作する場合、そのログは当然ながら隔離されます。以下の主要な問題を考慮してください。

  • **統一されたビューがない：** すべての運用データを同時に表示できる単一のインターフェースがありません。ログを見るためだけに異なるターミナルやWeb UIを切り替えることは、精神的に負担がかかり、時間も消費します。
  • **非効率なトラブルシューティング：** インシデントの根本原因を特定することは、困難な科学捜査のようになります。Webサーバーが遅かったのはデータベースが遅延したためか、それともキャッシュサービスが障害を起こしたためか？異なるシステムからの関連するすべてのログエントリを並べて確認する方法がなければ、サービス間のイベントを関連付けることは非常に困難です。
  • **異常の見落とし：** ギガバイトのテキストを手動で選別していると、微妙なパターンやまれなエラーは簡単に見落とされます。あるログの早期警告サインは、焦点が他にあると完全に気づかれない可能性があります。
  • **予防的な監視がない：** ログを集約して分析する集中システムがなければ、重要なイベントに対するアラートを設定することは事実上不可能です。問題は、目に見えて何かが壊れたときに初めて発見され、異常なアクティビティが最初に始まったときに通知されるわけではありません。

私の個人的な経験は、これらの点を繰り返し浮き彫りにしました。例えば、あるコンテナのメモリリークが、再試行の増加により別のコンテナで高いCPU使用率を引き起こすことがあります。このような連鎖的な影響をバラバラなログから追跡するのは悪夢で、何時間もかかることがよくありました。

ソリューション比較：ELK Stack vs. Grafana Loki

より良い方法が必要であると認識し、私は集中型ロギングソリューションを検討し始めました。特に目立った2つの主要な候補は、ELK StackとGrafana Lokiでした。

ELK Stack（Elasticsearch、Logstash、Kibana）

ELK Stackは、この分野の長年のベテランであり、強力で機能豊富なスイートを提供します。

  • **Elasticsearch:** この非常にスケーラブルな検索エンジンは、あらゆる種類のデータを処理し、全文検索と複雑な集計に優れています。
  • **Logstash:** さまざまなソースからログを取り込み、変換し、Elasticsearchに送信するデータ処理パイプラインです。
  • **Kibana:** この可視化レイヤーはElasticsearchの上に構築されており、リッチなダッシュボード、強力な検索機能、詳細なレポート機能を提供します。

メリット： ELKは、詳細なログ分析に非常に堅牢です。優れた検索機能と膨大な数のプラグインを提供します。多様なデータタイプと複雑なクエリ要件を持つエンタープライズ規模の運用には、確実な選択肢です。多くの大企業が正当な理由でこれに依存しています。

デメリット： HomeLab環境では、ELKのリソースフットプリントはかなりのものになる可能性があります。特にElasticsearchは、大量のRAMとCPUを必要とするJavaベースのアプリケーションです。

3つのコンポーネントすべてを設定および保守し、Logstashパイプラインを構成し、Elasticsearchインデックスを最適化することは、急な学習曲線とかなりの時間投資を伴う可能性があります。当初はELKを検討しましたが、私の比較的控えめなHomeLab（例えば、Raspberry Pi 4や低電力NUC）では、そのオーバーヘッドがメリットに比べて不均衡だと感じました。HomeLabの半分を監視するためだけに、HomeLabのリソースの半分を消費しないような効率的なものが欲しかったのです。

Grafana Loki

一方、Grafana Lokiは異なる哲学を採用しています。「ログのためのPrometheus」とよく表現され、効率性とシンプルさを重視しています。

  • **Promtail:** この軽量エージェントは、さまざまなソース（ファイル、Dockerコンテナ、systemdジャーナル）からログを収集し、効率的にLokiに送ります。
  • **Loki:** ログ集約システム自体です。Elasticsearchとは異なり、Lokiはログの「完全なコンテンツ」をインデックス化しません。代わりに、ログストリームに関連付けられたメタデータ（ラベル）のみをインデックス化します。ログはその後、圧縮されてオブジェクトストレージまたはローカルファイルに保存され、かなりのスペースを節約します。
  • **Grafana:** この広く使用されている可視化およびダッシュボードツールは、独自のクエリ言語LogQLを使用してLokiにクエリを実行するため、多くのユーザーにとって既に馴染み深いものとなっています。

メリット： Lokiはメタデータのみをインデックス化するため、ログコンテンツ全体をインデックス化しません。これにより、ストレージとCPUへの負荷がはるかに軽くなり、中程度のログ量でも通常は数百MBのRAMしか必要としません。

HomeLabユーザーの多くが既にメトリクス監視に利用しているGrafanaとシームレスに統合します。セットアップは比較的簡単で、その運用上のシンプルさはHomeLabにとって大きな利点です。私にとって、軽量であることと、既存のGrafanaダッシュボードとの統合が重要なセールスポイントでした。

デメリット： Lokiのクエリ機能（LogQL）は、ラベルに基づいてフィルタリングおよび集計するには強力です。しかし、Elasticsearchのような任意の全文検索の深さは提供しません。膨大なデータセットに対して、非常に複雑でインデックス化されていない全文検索を頻繁に実行する必要がある場合、ELKの方が適しているかもしれません。ただし、HomeLabで問題を特定し、既知のログパターンを監視する場合、Lokiのアプローチは十分すぎるほどであり、特定のクエリに対しては多くの場合高速です。

HomeLabに最適なアプローチ：Grafana Lokiの採用

両方のオプションを評価した後、私は自信を持ってHomeLabにGrafana Lokiを採用することを決定しました。その軽量設計、効率的なストレージ、およびGrafanaとのネイティブ統合が、私のニーズにとって明確な勝者となりました。強力なログ管理とリソースの節約の間で優れたバランスを取っており、制約のある環境に最適です。

以下に、Loki、Promtail、Grafanaを一体化したスタックとしてDocker Composeを使用して集中型ロギングシステムをセットアップする方法を示します。

実装ガイド：Docker ComposeでLokiをセットアップする

まず、Lokiスタック専用のディレクトリを作成します。次に、その中に`docker-compose.yaml`ファイルを作成します。


mkdir ~/loki-stack
cd ~/loki-stack
nano docker-compose.yaml

以下の内容を`docker-compose.yaml`に貼り付けます。この設定は、Grafana、Loki、Promtailをセットアップします。PromtailがDockerソケットをマウントするように構成されていることに注目してください。これにより、他の実行中のコンテナからログを自動的に検出し、収集することができます。


version: "3.8"

networks:
  loki:

volumes:
  grafana_data:
  loki_data:

services:
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=your_secure_grafana_password
    networks:
      - loki
    restart: unless-stopped

  loki:
    image: grafana/loki:latest
    container_name: loki
    ports:
      - "3100:3100"
    command: -config.file=/etc/loki/local-config.yaml
    volumes:
      - ./loki-config.yaml:/etc/loki/local-config.yaml # このパスが正しいことを確認してください
      - loki_data:/loki
    networks:
      - loki
    restart: unless-stopped

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    command: -config.file=/etc/promtail/config.yaml
    volumes:
      - ./promtail-config.yaml:/etc/promtail/config.yaml # このパスが正しいことを確認してください
      - /var/log:/var/log
      - /var/lib/docker/containers:/var/lib/docker/containers:ro # Dockerコンテナのログ用
      - /run/docker.sock:/run/docker.sock:ro # Dockerコンテナを検出するため
    networks:
      - loki
    restart: unless-stopped

次に、Lokiの設定ファイル`loki-config.yaml`を同じディレクトリに作成します。


nano loki-config.yaml


auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  storage_config:
    boltdb_shipper:
      active_index_directory: /loki/boltdb-shipper-active
      cache_location: /loki/boltdb-shipper-cache
    filesystem:
      directory: /loki/chunks
  replication_factor: 1
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory

query_range:
  # query_timeout: 10s

schema_config:
  configs:
    - from: 2020-10-27
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      period: 24h

compactor:
  working_directory: /loki/boltdb-shipper-compactor
  shared_store: filesystem

次に、Promtailの構成ファイル`promtail-config.yaml`を作成します。これにより、収集するログが正確に指定されます。


nano promtail-config.yaml


server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__:
            - /var/log/*.log
            - /var/log/*/*.log

  - job_name: docker
    docker_sd_configs:
      - host: unix:///var/run/docker.sock
        refresh_interval: 5s
        filters:
          - name: label
            values: ['logging=promtail']
    relabel_configs:
      - source_labels: ['__meta_docker_container_name']
        regex: '/(.*)'
        target_label: container
      - source_labels: ['__meta_docker_container_id']
        target_label: container_id
      - source_labels: ['__meta_docker_image_name']
        target_label: image

PromtailのDocker構成に関する注意： `docker`ジョブの`filters`セクションは非常に重要です。これにより、Promtailは`logging=promtail`ラベルを持つDockerコンテナからのみログを収集するようになります。これにより、Promtailがすべてのコンテナをスクレイピングするのを防ぎ、システムが簡単に過負荷になることを回避できます。特定のコンテナのロギングを有効にするには、`docker-compose.yaml`構成に`labels:`エントリを追加するだけです。例：


  my_app:
    image: my_image:latest
    labels:
      - logging=promtail
    # ... その他の設定

これらのファイルがすべて作成されたら、Docker Composeを使用してスタックを起動します。


docker-compose up -d

Grafanaの設定とログのクエリ

Grafanaインスタンス（通常`http://your-homelab-ip:3000`）に移動します。ユーザー名には`admin`、パスワードには`your_secure_grafana_password`（`docker-compose.yaml`で設定したもの）を使用してログインします。

  1. Lokiをデータソースとして追加する：
    • 設定（左側の歯車アイコン）に移動し、「Data Sources」を選択します。
    • 「Add data source」をクリックし、リストから「Loki」を選択します。
    • URLには`http://loki:3100`と入力します。これは、GrafanaとLokiが同じDockerネットワーク上にあるため機能します。
    • 「Save & Test」をクリックします。「Data source is working.」のような確認メッセージが表示されるはずです。
  2. ログを探索する：
    • 探索（左側のコンパスアイコン）に移動します。
    • 新しく設定したLokiデータソースを選択します。
    • これでLogQLを使用してログを効果的にクエリできます。

基本的なLogQLの例：

  • `{job=”docker”}`: すべてのDockerコンテナログを表示します。
  • `{job=”docker”, container=”my_app”}`: `my_app`という名前のコンテナからのログのみを表示します。
  • `{job=”varlogs”, filename=”/var/log/syslog”} |= “error”`: システムのsyslog内で「error」という単語を検索します。
  • `{job=”docker”, container=”jellyfin”} |~ “fail|error”`: Jellyfinログ内で「fail」または「error」を含む行を検索します。

これらの単純なクエリは、ラベルによるフィルタリングがいかに強力であるかを示しています。`count_over_time({job=”docker”}[5m])`のような集計関数を使用して、過去5分間のログのレートを表示することもできます。

6ヶ月後のメリット：安定性と明確な洞察

このアプローチを本番に近いHomeLab環境で適用したところ、その結果は常に安定しており、示唆に富むものでした。6ヶ月が経過し、私のHomeLab監視体験は劇的に改善されました。私が観察した即座のメリットは次のとおりです。

  • **迅速なトラブルシューティング：** 問題が発生した場合、私はすぐにGrafanaのExploreページに移動します。サービスまたはコンテナでフィルタリングする簡単なLogQLクエリで、問題はほんの数秒で特定できます。異なるサービス間のイベントの相関関係は今や取るに足らないことであり、同じクエリに別のラベルフィルターを追加するだけです。これにより、トラブルシューティング時間が推定70%削減されました。
  • **予防的な監視：** ログが一元化されたことで、重要なログパターンに対するGrafanaアラートを簡単に設定できるようになりました。たとえば、特定のコンテナが1分間に5回を超える「failed connection」エラーをログに記録した場合、私はTelegram経由で即座に通知を受け取ります。これにより、潜在的な問題が大規模な障害に発展する前に対応することができます。
  • **履歴分析：** サービス稼働時間、エラーにつながるリソース消費、特定のイベントの頻度など、長期的な傾向を理解することは今や簡単です。過去のインシデントを調査したり、数週間または数ヶ月にわたるパフォーマンス傾向を分析したりするために、時間を遡って（例えば3ヶ月前のログを取得して）簡単に調査できます。
  • **リソース効率：** Lokiは本当にその約束を果たしています。低電力のHomeLabサーバー（8GB RAMのIntel NUC）でスムーズに動作し、最小限のCPUとRAM（通常、CPU使用率5%未満、RAM使用量200MB）しか消費せず、実際のサービスに十分なリソースを残します。ログのストレージ使用量も非常に合理的で、ラベルベースのインデックス作成と効率的な圧縮のおかげで、数ギガバイトのログを数百メガバイトのディスクスペースに保存することがよくあります。

HomeLabとのやり取りや管理方法が本当に変わりました。際限なくテキストファイルをスクロールする日々はもう過去のものです。今では、インフラストラクチャの隅々まで明確で実用的なビューが得られ、より信頼性の高い効率的なホーム環境を維持できるようになりました。

今後の展望

集中型ロギングのためにGrafana Lokiをセットアップすることは、HomeLabのために行った最良の決定の1つでした。システム動作を分かりやすくし、予防的なメンテナンスを可能にし、トラブルシューティングの時間を大幅に節約します。ある程度複雑なHomeLabを運用している人にとって、集中型ロギングソリューションは贅沢品ではなく、必需品です。

Lokiを使えば、その必要性は、制約のあるリソースであっても、強力かつ達成可能です。次のステップは、より多くのカスタムアプリケーションログを統合し、Alertmanagerのようなツールを使った高度なアラートルートを検討することですが、今のところ、私が得た安定性と洞察は計り知れません。強くお勧めします。

Share:
Tags: