ホスティングにおける一元的なログ管理のためのLoki

Loki、Alloy、Grafanaを明確に区別する

一元的なログ管理は、イベントを生成するシステム、すなわちLinuxホスト、仮想サーバー、コンテナ、およびアプリケーションから始まります。そこでは、systemdのジャーナルエントリ、Nginxのアクセスログやエラーログ、あるいはDockerコンテナの標準出力などが生成されます。 Grafana Alloy このようなソースを読み取り、送信前に処理して、Lokiに転送します。したがって、Alloyはデータ収集役であり、中央のログストレージではありません。

Grafana Loki ログデータを受け取り、集約して、後での照会に備えて保存します。 オブジェクトストレージは、永続化されたデータを格納することができます。一方、GrafanaはExplore、ダッシュボード、アラート機能のためのインターフェースを提供することが多いですが、技術的にはLoki自体には含まれていません。この分離により、変更、障害、アクセス権限に関する責任の所在を明確に割り当てることが容易になります。

小規模なホスティング環境の例として、VPS上のAlloyがsystemdジャーナル、Nginxファイル、およびコンテナのログを読み取ります。Alloyは選択した行をLokiに送信し、管理者は各ホストに個別にログインして初期のエラー分析を行う代わりに、Grafanaでそれらの行を検索します。 Lokiの前段では、リバースプロキシまたはアイデンティティレイヤーが、認証、TLS、ルーティング、および必要に応じてテナントの割り当てを適切に処理する必要があります。

一元的な集約により検索の手間が省けますが、原因分析や運用プロセスの代わりにはなりません。 アクセス保護 誰がどのデータを閲覧できるかを明確に定めなければなりません。データ最小化の原則に基づき、送信前にどのフィールドを削除するかが決定されます。また、バックアップおよび復旧の計画策定も別途行う必要があります。Lokiは既存のログを検索可能にしますが、それだけではログの保護、完全性、あるいは法的に適正な保管を保証するものではありません。

したがって、実務上、Lokiを活用する価値があるのは、ログの棚卸しを行った後です。どのログが運用やインシデント対応に役立つのか、どのログに機密情報や個人データが含まれているのか、そして誰がアクセス権を必要としているのか。これらの答えが、フィルタリング、保存期間、アクセス権限を決定するのです。 検証もせずにすべてのLinuxログを一元化しても、機密情報は単に検索しやすいストレージに移されるだけになります。

ストリーム、ラベル、LogQLの理解

Lokiは、受信行を主に全文インデックスとして整理するわけではありません。クライアントIDとそのラベルセットに基づいて、それらを1つの ストリーム 。実際のログデータはチャンク単位で圧縮されて保存されており、インデックスはラベルセットとこれらのチャンクを関連付けています。そのため、検索を行う際、Lokiはまずラベルに基づいて該当するストリームを絞り込み、その後、対象となるデータを読み込んで、さらにフィルタリングやパースを行います。

ラベルは、長期的で把握しやすい文脈を表現すべきです。例えば、 env, service また、安定したサーバーであれば host. コンテナ環境では、クラスター、ネームスペース、またはアプリケーションも有用な場合があります。ただし、それぞれの一意な組み合わせが1つのストリームを形成します。リクエストID、ユーザーID、トレースID、変動するコンテナID、あるいはクライアントのIPアドレスなどは、非常に多くの値を生成するため、通常はラベルには含めません。

まれに行われる詳細な調査の場合、このような動的な情報はログ行に残され、クエリ実行時に初めて、例えばJSONやLogfmtのパーシングを通じて解析されます。頻繁に必要とされる高カーディナルなコンテキストデータについては、構造化されたメタデータとして扱う方が適している場合があります。 重要なのは、利用可能なすべてのフィールドを無条件にラベル付けするのではなく、本番環境への展開前にデータモデルを実際のデータソースで検証することです。

Nginxのエラーを対象とした、読み取り専用のLogQLクエリは次のような形になります。これは、例えばGrafana ExploreやLogCLIなどで使用され、選択したラベルが実際にデータ収集時に付与されていることが前提となります。

{env="prod", service="nginx"} |= " 500 "

パイプラインの手前にあるセレクタは、まずNginxサービスのプロダクションストリームに絞り込み、その後 |= " 500 " テキストを検索します。とはいえ、クエリの品質は、期間、ログの量、ストレージのレイテンシ、およびラベルの設計によって左右されます。Lokiは、これらに基づいて一定の応答時間を保証するものではありません。短い時間枠と、正確で安定したセレクタを設定することが、段階的な調査を進める上で有効な出発点となります。

ホスティングに適したLokiアーキテクチャとは

単一のVPS、ラボ環境、またはログ量が少ない場合には、 モノリシック方式 多くの場合、最もわかりやすい導入方法として、Lokiプロセスが必要なコンポーネントをまとめています。 ドキュメントでは、このモードは実験用や、1日あたり約20 GBまでの小規模なログの読み取り・書き込み量に適していると記載されています。これは、この用途に関するメーカー側の指針であり、あらゆるストレージ、クエリ、またはラベル構造における容量の保証ではありません。

個々のLokiロールを個別にスケーリングする必要がないにもかかわらず、可用性の要件が高まる場合は、高可用性を備えたモノリシックな運用が検討されます。 コンポーネントを個別にスケーリングする必要がある非常に大規模なクラスターやKubernetes環境では、マイクロサービスモードが想定されています。しかし、この細分化によって計画の必要性がなくなるわけではありません。運用構成要素の数が増加するため、診断やメンテナンスの負担も増大します。

「Simple Scalable Deployment」モードは、新たな判断を下す際の中立的な妥協案ではありません。GrafanaはSSDを非推奨としており、Loki 4.0での廃止を発表しています。 したがって、現在システムを構築している場合は、長期的な移行アーキテクチャを計画するのではなく、実際のスケーリング要件に基づいて、適切な可用性を備えたモノリシックなアプローチか、マイクロサービスのアプローチかを評価すべきです。

意思決定の参考となるのは、1日あたりに生成されるギガバイト数だけではありません。書き込みのピーク、ストリームの数とカーディナリティ、必要なテナント分離、データ保持期間、そしてチーム内のKubernetesや分散コンポーネントに関する知識も重要な要素となります。 グローバルに分散した配信を行うプロジェクトでは、そもそも中央の運用サービスとエッジコンポーネントの間を明確に区別する必要があります。これに関連して、以下の記事も参考になります。 エッジレンダリングと分散型配信のためのウェブホスティング.

ログソース、ラベル、アクセスがまだ安定して定義されていない場合は、小規模から始めましょう。アーキテクチャの変更は、将来的な成長に対する漠然とした期待ではなく、特定されたスケーリングや可用性の向上といった、実際に確認された要件に基づいて行うべきです。そうすることで、 ログ管理 一元的な検索およびインシデント対応の利点と比較して。

Alloy を使って Linux のログを安全に収集する

設定を行う前に、ログソースの棚卸しが必要です。運用やインシデント対応に実際に役立つログはどれでしょうか？Linuxウェブサーバーの場合、多くの場合、systemd-journal、Nginxのアクセスログおよびエラーログ、PHP-FPM、SSHイベント、Cronジョブなどが該当します。 コンテナの場合は、ランタイムの出力やアプリケーション固有のプロトコルも加わります。同様に重要なのが、パスワード、APIキー、セッションID、個人データに関する事前チェックです。こうした内容は、確認なしに中央システムへ転送してはなりません。

新規導入の場合は、 Grafana Alloy 収集および転送のためのサポート対象の方法です。Promtailは、これ以上の標準的なソリューションとして計画すべきではありません。そのライフサイクルは2026年3月2日に終了しており、移行や新しい設定については、ドキュメントでAlloyまたはその他のサポート対象クライアントが推奨されています。 したがって、既存のPromtailインストールについては、黙示的な更新ではなく、計画的な移行を行う必要があります。

構成パターンはシンプルです。あるソースがファイル、ジャーナル、またはコンテナログを読み込み、オプションの処理で不要な行を削除したりフィールドを整形したりした後、 loki.write データをLokiに送信します。Alloyは、ファイル、systemdジャーナル、Docker、Kubernetes、Syslog、Windowsイベントなどに対応したコンポーネントを提供しています。どのソースを選択するかは、アプリケーションがイベントを確実に送信する場所によって決まります。

テンプレートは、まだ本番環境向けの構成とは限りません。ファイル権限については、Alloyプロセスに必要な読み取りアクセス権のみを付与すれば十分です。ジャーナルへのアクセス、宛先アドレス、証明書検証、TLS、ネットワーク障害時のバッファリング、および障害時の対応については、インストール環境に応じて確認する必要があります。 アクセスデータやクライアント情報は、共有されるサンプルファイルには含めないでください。まずは少数のソースから始め、内容と容量を確認した上で、その後に収集範囲を拡大してください。

エージェント側でのフィルタリングは、発信元に対する責任を軽減するものでもなければ、権限管理の仕組みに取って代わるものでもありません。しかし、既知のデバッグ出力や明確に特定された機密情報が、そもそも中央のデータベースに流入するのを防ぐことができます。 業務上必要なコンテンツについては、どのサービスが送信したのか、後で誰が閲覧できるのか、そしてどのくらいの期間必要とされるのかが、追跡可能であるべきです。

展開前のブランドコンセプトと計画

A レーベルのコンセプト ログがどの安定したコンテキストで見つかるかを指定します。複数のホストや環境には、例えば次のようなものが適しています。 env, cluster, namespace, app, service また、その関連付けが永続的に有用である場合は、ホスト名も指定します。これらの値は限定的で、予測可能である必要があります。ラベルの組み合わせが異なるごとに独自のストリームが形成されるため、このモデルは取り込み、インデックス作成、およびその後のクエリに直接影響を与えます。

一方、リクエストID、トレースID、ユーザーID、クライアントIPアドレス、および動的コンテナIDは、適切なラベルとは言えません。これらはあまりにも多くの異なる値を生成し、その結果、多数の小さなストリームを生み出してしまうからです。高カーディナルな情報は、必要に応じて構造化されたメタデータとして付加することができます。 時折の調査においては、クエリ実行時に初めて json, logfmt, pattern 或いは regexp を解析する。

この表はストレージの予測値を示すものではなく、意思決定の根拠となるものです。特に保存期間（リテンション）は、ログのボリュームからは導き出せないため、計画に組み込む必要があります。業務上の保存義務、セキュリティ要件、および削除基準は、それぞれ異なる場合があるからです。 復元可能性もまた、独自の要件です。有効期限が切れたログの自動削除は、バックアップや復旧の仕組みに代わるものではありません。

実用的な最初の基準としては、例えば env, service そして host 従来のWebサーバーで使用します。コンテナプラットフォームは、以下の場合にのみ補完として使用します cluster そして namespace、トラブルシューティングの際に実際にそれらを絞り込む場合です。このスキームは、開発者や運用担当者と調整しておく必要があります。事後的に付けられた、統一性のないラベルは、環境間の比較を困難にし、一元的な検索の信頼性を低下させます。

計画においては、技術的に把握可能な事項だけでなく、責任の所在も重要である。あるチームはソースとフィルタを担当し、別のチームは必要に応じてストレージとアクセスを担当すべきである。そうすることで、ログ形式に欠けているフィールドを補完すべきか、構造化メタデータとして扱うべきか、あるいは意図的に収集しないべきかが明確になる。

クライアントとアクセスを確実に保護する

Loki はログデータをマルチテナント対応で処理できます。テナント分離が有効になっている場合、Loki は各リクエストに対してヘッダーを期待します X-Scope-OrgID. ただし、このヘッダーはログインでも権限の証明でもありません。そうでなければ、クライアントがその値を独自に決定できてしまうからです。Lokiには完全な認証レイヤーは備わっておらず、保護と強制的な割り当ては、その前に実施される必要があります。

堅牢な処理フローは、信頼できるリバースプロキシまたはアイデンティティ層から始まります。ログインに成功すると、この層は権限を持つ組織を特定し、サーバー側でクライアントIDを設定し、TLSを強制し、許可されたリクエストのみをLokiに転送します。 ネットワークから直接アクセス可能なLokiエンドポイントでは、この制御が回避されてしまいます。また、エージェントによる書き込みアクセスにおいても、明確に制限された識別情報と、保護された通信経路が必要です。

権限コンセプトは、誰がログを閲覧または書き込みできるかを定めています。これは、機密情報のフィルタリングやデータ保護チェックに代わるものではありません。トークン、セッションID、個人データは、正しく割り当てられたテナント内であっても問題となる可能性があります。 したがって、データの最小化はデータ源および処理の段階ですでに実施される必要があり、一方で権限設定は、残りのデータ量をタスクやテナントごとに制限する役割を果たします。

分散型ホスティングアーキテクチャでは、アクセスポイントを独立したセキュリティ境界として扱うことが有効です。この記事は 分散型ホスティングとそのアーキテクチャに関する課題 分散型コンポーネントが、アイデンティティやデータアクセスに関する一元的な責任を排除しない理由を説明します。Lokiにとって、これは具体的には、すべての転送が、信頼できるインスタンスおよび定められたクライアントルールに追跡可能な形で紐付けられなければならないことを意味します。

したがって、定期的な検査はダッシュボードだけにとどめるべきではありません。 プロキシが匿名アクセスを拒否しているか、クライアントによって指定されたクライアントヘッダーが上書き可能かどうか、書き込み用アカウントが所定の宛先のみに到達しているかを確認してください。このような検証は完全なセキュリティを保証するものではありませんが、ログイン、ルーティング、ログ保存の間に生じがちな典型的な脆弱性を早期に発見することができます。

リテンションとストレージを管理しながら運用する

中央ログは、オブジェクトストレージに空き容量がある限り、ただ漫然と保存し続けるべきではありません。その 保持 法的、契約上、および業務上の保存義務に適合している必要があり、また、エラー分析においてデータがもはや有用でなくなる時点とも整合していなければならない。 ドキュメントによると、保存機能が有効になっていない場合、Lokiに送信されたログは無期限に保持されます。これにより、コストやデータ保護上のリスクが増大し、将来的な復旧作業の規模も拡大する可能性があります。

TSDB および BoltDB-Shipper では、コンパクターが設定された削除期限を適用します。コンパクターは単一のインスタンスとして実行し、再起動時に作業が未完了のまま失われないよう、永続的な作業ディレクトリを割り当てる必要があります。 なお、オブジェクトストレージにはログチャンクとインデックスデータの両方が格納されるため、その設計は単なる容量計画にとどまらず、運用コンセプトの一部となります。

ログストリームごとに異なる保持期間を設定することは、例えば、セキュリティイベントのログが詳細なデバッグ出力よりも長く保持される必要がある場合などに有用です。このようなストリーム固有のルールでは、少なくとも24時間の保持期間が必須であり、ラベルセレクタのみを使用して機能します。 コンテンツベースのフィルタや任意のLogQL式は、この目的には想定されていません。そのため、保持ルールがラベルに基づいて適用される前に、ラベルが業務上のコンテキストを確実に反映している必要があります。

警告：ストレージバケット全体に一律に適用されるライフサイクルルールは、インデックスやクラスタの状態オブジェクトを削除し、クエリに支障をきたす可能性があります。Lokiのレテンション、ストレージクラス、および個別のバケットやプレフィックスを考慮した、対象を絞った削除方針を採用することをお勧めします。 また、リテンションはバックアップの代わりにはなりません。リテンションはログデータの計画的な削除を決定するものであり、一方、復旧要件は、障害発生後にどの構成、アクセスパス、および必要に応じてどの保存データが利用可能でなければならないかを規定するものです。

エラー波形を検出し、録音の問題を確認する

Grafana Explore では、特定の期間における複数のホストのイベントをまとめて調査することができます。これにより、インシデント発生時の対応が効率化されます。Web サーバーに一つずつログインする代わりに、まず環境やサービスごとに調査範囲を絞り込むことができるからです。 ただし、一元的な検索では相関関係は明らかになりますが、原因が自動的に特定されるわけではありません。診断においては、メトリクス、トレース、デプロイメント、アプリケーションの状態が依然として重要な補足情報となります。

エラーの波が発生した場合、LogQLは該当する行からメトリクスを導き出すことができます。以下のクエリは、例として、HTTPステータス500のNginx行を5分間のレートとして集計するものです。これは分析やアラートの基礎となるものですが、各アプリケーションにおいてどの値がクリティカルであるかについては示唆するものではありません。

sum(rate({env="prod", service="nginx"} |= " 500 " [5m]))

理にかなった アラートの閾値 通常のエラー率、アプリケーションの動作、および既存のモニタリング信号に基づいて算出されます。 利用頻度の低い管理機能における単発の500エラーは、チェックアウト時のエラーとは異なる評価が必要となる場合があります。したがって、まず過去の傾向を確認し、アラームを明確な担当チームに紐付けてから、本番環境へエスカレーションするようにしてください。

書き込み時にLokiが429を返した場合、反射的に制限値を引き上げてはなりません。まず、あるサービスが異常に多くの行を生成しているのか、ループによってエラーが繰り返されているのか、あるいは動的なラベルによって多数の小さなストリームが生成されているのかを明らかにする必要があります。 Lokiは、プラットフォームを保護するために、グローバルおよびストリームごとの記録量を制限しています。この確認を行ってから初めて、フィルタリング、ラベルの修正、あるいは正当な理由に基づく制限値の調整が必要かどうかを判断することができます。

ロキを適切かつ責任を持って活用する

Nginx、systemd、および少数のコンテナで構成される単一のVPSの場合、ログソース、ストレージ、およびアクセスが明確に管理されていれば、Lokiはモノリシックモードで管理しやすい一元的な検索環境を構築できます。 ドキュメントでは、このモードは実験用途や読み書き量が少ない環境向けと位置付けられています。1日あたり約20GBのログという数値は、メーカーによる目安であり、あらゆるストレージ、クエリ、ラベル構造に対して容量を保証するものではありません。

複数のLinuxウェブサーバーでは、ウェブ、ログ、アプリケーションのイベントを共通のタイムラインで管理できることが特に有効です。コンテナ展開においては、環境とサービスに対する安定したラベルモデルが、この検索を管理可能な状態に保てるかどうかを決定づけます。 非常に大規模なKubernetes環境や、意図的に個別にスケーリングする必要があるロールでは、マイクロサービスモードの採用が正当化される場合がありますが、その場合は運用および障害分析の負担が大幅に増大します。新規計画においては、このモードは非推奨とされているため、SSDは恒久的な標準オプションとはなりません。

マルチテナント対応のプラットフォームには、さらに堅牢なアクセスチェーンが必要です。LokiはテナントIDに基づいてリクエストを分離しますが、完全な認証レイヤーは提供していません。 信頼できるプロキシまたはアイデンティティ層が、アクセスの認証を行い、TLSを強制し、サーバー側でマッピングを設定する必要があります。また、サポートされているエージェントも基盤の一部です。Promtailはサポート終了となっており、新規導入の場合は、例えばGrafana Alloyが推奨される選択肢となります。

• 個々のVPS：ロールアウト前に、ソースのインベントリ、機密情報のフィルタ、およびシンプルで検証可能な保持期間を設定する。
• 複数のホスト：環境とサービスに対して一貫性のあるラベルを定義し、一元的な検索によってインシデントの解決までの時間を確実に短縮できるようにする。
• コンテナプラットフォーム：動的IDをラベルとして使用しない。ストリームの数と取り込み状況を継続的に監視する。
• マルチテナント環境：Lokiエンドポイントの公開前に、認証、サーバー側でのテナント割り当て、および権限設定を実施する。
• あらゆる環境において：復旧要件を文書化し、構成、ストレージの設計、および削除期限を定期的に確認する。

ログソースの責任者、機密性の高いコンテンツに関する方針、あるいは明確な復旧目標が定まっていない場合は、まずこれらを 事業基盤 明確にしておく必要がある。Lokiはログを集約し、検索可能にすることはできるが、データの最小化やバックアップ、アクセス制御、あるいは専門的な原因分析の代わりにはならない。技術、責任分担、保存期間が一体となって計画されて初めて、その真価が発揮される。