ELKの代替を選ぶ：ログ基盤の何を変えるべきか

ELK、Elastic Observability、Loki、クラウドログ、Guanceを、索引、保持、運用責任、段階的な移行から比較します。

Guance編集部 2026-10-27 読了目安 9 分更新日 2026-10-27

障害対応中にエラーログは見つかった。それでも、リクエストの経路、影響を受けた利用者、直近のデプロイを調べるには別の画面をいくつも開かなければならない。その一方で、基盤チームはシャード、mapping の競合、インデックスのライフサイクル、クラスター更新に追われている。こうした状況なら、ELK の代替を検討する理由は具体的です。

本稿の出発点は、Elasticsearch、Logstash、Kibana を中心に自社運用するログ基盤です。APM、インフラ監視、RUM なども備える Elastic Observability を「ログしか扱えない製品」とは捉えません。記事の発行者は候補製品の一つを提供する Guance です。公式資料と運用上の判断材料を整理したもので、実環境で性能を横並びに測定した報告ではありません。

まず、どの層を変えたいのか

選択肢	活かせる既存資産	再検討する仕事
ELK / EFK を継続	クエリ、フィールド設計、Elasticsearch の運用経験	シャード、容量、ライフサイクル、更新、バックアップ、復旧
Elastic Observability	Elastic のクエリと運用手法	エディション、構成、APM の導入、保持期間、課金範囲
Loki + Grafana	Grafana の操作経験、サービスやクラスターからログを絞る調査方法	ラベル、LogQL、長期間のスキャン、関連データソース
SLS / CLS / LTS	クラウドリソースのログ、既存の調達経路	外部データの収集、クラウド間通信費、識別子、クエリ
ClickHouse を基盤に自作	SQL 分析、データ基盤の開発経験	収集、スキーマ、テナント分離、権限、アラート、調査画面
Guance	対応するコレクター、サービス識別子	フィールド変換、ログとトレースの関連付け、権限、費用、移行検証

Elasticsearch の保守だけが負担なら、マネージドサービスで主要な問題が解決する場合があります。クエリの仕組みが用途に合わないなら、ストレージと索引方式を比較します。ツールの間で調査が止まるなら、検索画面単体ではなく、障害を調べる一連の手順が比較対象です。

索引方式が変わると、費用と検索の仕方も変わる

Elasticsearch では、取り込み量とクエリ負荷に合わせてシャード数、レプリカ、mapping、ライフサイクルを見直します。フィールドの競合は取り込みや分析に影響し、インデックスやシャードの増加は管理項目を増やします。ピーク時の書き込みと過去ログの検索が競合するとき、マシンの増強だけでは解決しないこともあります。普段使うクエリを持ち込み、直近 15 分と長期の履歴をそれぞれ試してください。

Loki は主にログストリームを識別するラベルを索引化し、個々のログ本文すべてに従来型の全文転置索引を作る方式ではありません。ただし、本文検索ができないわけではなく、LogQL でログ行のフィルタリングや解析ができます。ラベルでストリームを絞ってから、その内容を処理する点が違います。サービス、環境、クラスターなどの安定したラベルは役立ちますが、リクエスト ID を一件ずつストリームラベルにすると高カーディナリティを招きます。費用の差は、自社のストリーム数、検索期間、同時クエリ数で確かめる必要があります。

ClickHouse はログ分析の保存・クエリ基盤になり得ます。しかし、データベースだけでログ製品一式が完成するわけではありません。収集と解析、テナント分離、権限、通知、画面、更新、復旧を誰が作り、維持するかを含めて評価します。データベース名だけを根拠に、速さや安さは判断できません。

ログを集めても、調査の文脈は自動では揃わない

障害時に知りたいのは、どのサービスが最初に異常になったか、遅いリクエストがどの依存先で待ったか、誰に影響したか、そしてデプロイや設定変更、Pod の再起動が同時に起きたかです。ログを増やすだけでは答えは出ません。サービス名、環境、時刻、trace ID の整合性が、ダッシュボードを一枚増やすことより効く場合があります。

Alibaba Cloud SLS や Tencent Cloud CLS は、他クラウドやデータセンターのログも収集できます。クラウド事業者の製品だからといって、そのクラウド内だけに限定されるわけではありません。確認すべきなのは、実際の収集経路、外向き通信費、フィールド変換、購入・設定した製品の組み合わせでログとトレース、利用者体験を関連付けられるかです。マルチクラウドでは、アラートからログ、トレース、影響範囲まで一度通して調べてみます。

移行対象を並べる前に、保持方針を決める

全ログの保持期間を短くすれば、当面の請求額が下がる可能性はあります。同時に、次の障害や監査に必要な証拠も失うかもしれません。取引、エラー、監査、デバッグのログを分け、収集範囲、検索できるまでの時間、保持期間、削除要件を決めます。その後で、収集側で除くフィールド、すぐ検索するデータ、アーカイブするデータを選びます。

費用は同じ期間、取り込みバイト数、イベント数、保持期間、検索並列度、復旧要件で比較します。索引やスキャン、アーカイブからの取り出し、通信、サポート、二重運用期間も含めます。事業単位で利用量を配分すれば、データを発生させるチームも判断に参加できます。ログとトレースの関連付けは調査範囲を絞る助けになりますが、取り込み済みデータの料金を自動的に減らすものではありません。

Guance も同じ調査手順で評価する

ログに加えてメトリクス、トレース、RUM、Kubernetes、イベントを関連付けたい場合は、Guance のログドキュメントを参照し、過去に障害を経験したサービスを一つ選びます。フィールド、サービスの識別、時刻、trace ID を照合してから、画面を行き来する手間が減るかを評価します。収集成功は、過去のインデックス、クエリ言語、ダッシュボード、アラートの自動移行を意味しません。

AI の評価では、Agent アプリケーションを監視することと、Obsy Agent Teams に調査タスクを担当させることを分けます。タスクのドキュメントには成果物や承認要求の扱いが説明されています。使えるツール、読めるデータ、実行できる操作は設定次第です。まず読み取り専用の調査から始め、引用されたログ、時間範囲、仮説をエンジニアが確認します。提案は確定した根本原因ではなく、タスクを停止しても外部システムの変更が元に戻るわけではありません。

一つのサービスで移行の境界を確かめる

既存の ELK を残し、管理された環境で代表的なサービスの重要ログを候補先にも送ります。必要に応じてメトリクスとトレースも追加します。コレクターが意図した並行転送に対応するか、キュー、再試行、重複、マスキング、追加料金に問題がないかを確認してください。転送先を増やしても、アプリケーションや既存パイプラインに影響しないとは限りません。

次に、利用を承認された保存データやマスキング済みデータで、過去の障害を三種類ほど振り返ります。同じエラーを検索できるか、リクエストと利用者影響につながるか、旧ルールと新ルールの結果の違いを説明できるかを見ます。Agent Teams も試すなら、使った証拠と人が退けた提案を記録します。一度もっともらしい答えが出ただけでは、安定した性能を示したことにはなりません。二週間は最初の振り返りの目安であり、移行完了の約束ではありません。

検証後に対象を広げます。中核的な取引、エラー、SLO に影響するサービス、トレースとの関連付けが必要なログから着手するのが一案です。調査価値の低いデバッグログは、フィルタ、短期保持、アーカイブを別途検討します。過去のインデックスを残しながら、新しい基盤に一部の調査を任せても構いません。切り替え前に、停止条件、元の収集設定に戻す手順、履歴へのアクセス、結果の確認責任者を決めておきます。

既存の検索・運用モデルが合っているなら ELK の改善を先に行う。Elastic の仕組みを活かして信号を増やすなら Elastic Observability。Grafana とラベル中心の調査が合うなら Loki。複数システムに証拠が分散しているなら、Guance を含むプラットフォームを同じサービスで比較する。選択を決めるのは、実際の調査手順、データ要件、そして総費用です。