2026.08.26 データベース

Elasticsearchのログ収集｜ELKスタックの収集経路とインデックス分割・保持期間の設計

ログをElasticsearchへ流す構成は、9.5系（2026年8月時点）では組み方が一つではありません。各サーバにFilebeatを置く従来の形、Elastic AgentをFleetで集中管理する形、そのAgentをOpenTelemetryモードで動かす形が並存し、さらにLogstashを挟むかElasticsearch側のingest pipelineで済ませるかの分岐が加わります。この記事では、収集経路の選び分け、緩衝をどこに置くか、データストリームの命名で保持期間と権限をどう割るか、保管費を左右する設定はどれかを、公式ドキュメントの現行記述に沿って実装目線で整理しました。設定値と既定値はすべて出典の記述に合わせています。

まとめ：着手前に決めておく収集経路と保持設計の6つの値

ELKのログ基盤で後から変えにくいのは、送信側の常駐プロセスとインデックスの分け方です。次の6点を先に決めてから構築へ入ると、作り直しが起きません。

収集エージェント：新規はFleet管理のElastic Agent、統合や出力が揃わない場合のみBeats
整形の位置：フィールド抽出をLogstashで行うか、Elasticsearchのingest pipelineへ寄せるか
緩衝の置き場所：Logstashの永続キュー、前段のKafka、緩衝なしのどれか
データストリーム命名：namespaceを環境・チーム・システムのどれで割るか
ロールオーバー条件：max_primary_shard_sizeとmax_ageの組み合わせ
保持日数と層構成：hot・warmで何日置き、cold以降へ落とすかどうか

結論を先に置くと、新規構築でLogstashを常設する必然性は薄くなりました。Elastic Agentの統合パッケージがingest pipelineを同梱し、grokを自前で書く区間が減るからです。残す理由は、複数の宛先へ配る・ディスクへ溜める・他系へ渡すのいずれかに集約されます。保管費は9.0以降の新規logs-*-*へlogsdbが自動で当たるため、その既定を崩さないのが最初の一手です。

ELKスタックの四つの区間とログが到達するまでの処理の受け渡し

ELKはElasticsearch・Logstash・Kibanaの頭文字で、Beats登場後の製品群はElastic Stackという総称へ変わりました。2026年8月時点の最新はElastic Agent 9.5.2、Filebeatも9.5.2が2026年8月20日に公開されています。実際に運用する構成は三つではなく四つの区間に分かれ、区間ごとに障害の出方も切り分け方も違います。

収集・整形・保存・可視化という四区間の役割と障害切り分けの順序

収集はログの出どころに常駐して読み取り位置を覚えるプロセス、整形は1行のテキストを型付きフィールドへ分解する処理、保存はElasticsearchへの書き込み、可視化はKibanaの検索と描画にあたります。

障害の切り分けはこの順に見ると速く終わります。まず送信側の常駐プロセスのログでファイル読み取りと出力先接続の状態を見る。次に整形段階でパース失敗のタグが付いていないかを確認する。それでも見えないなら、Elasticsearch側のインデックス作成拒否やマッピング衝突を疑う。可視化で「出ない」と言われる事象の多くは、時刻フィールドのずれか対象データストリームの選択違いです。Kibana側の接続設定とデータビューの定義はElasticsearchとKibanaの連携｜接続設定とデータビュー定義へ分けて整理しました。ログ本体をJSONで出しておけば、整形段階の失敗そのものを減らせます。出力側の書き方はJSONでログを機械可読にする構造化ログの実装に整理しています。

Elasticsearch側の受け口｜データストリームとingest pipeline

ログの宛先は、通常のインデックスではなくデータストリームです。追記中心の時系列データ向けの抽象で、実体は自動生成される隠しバッキングインデックス群になります。書き込みは常に最新のものへ向き、ロールオーバーで新しい書き込み先が作られます。

ingest pipelineは、Elasticsearchのノード上で書き込み直前に走る処理列です。grok・dissect・date・renameなどのプロセッサを並べれば、Logstashのfilter段と同等の整形をクラスタ側で実行できます。統合パッケージを入れると、このpipelineとindex template、ダッシュボードが同時に登録されました。自前でパイプラインを書くときの構文の詰め方はLogstashのgrokフィルターの使い方で扱っており、パターンの考え方はingest pipelineのgrokプロセッサでも通用します。

収集エージェントの選択｜BeatsとElastic Agentの機能差と移行条件

送信側に何を常駐させるかは、後から差し替えると全ホストへの再配布が発生します。ここは最初に決める箇所です。

Filebeatが担う入力とモジュール｜軽量な単機能の常駐という設計

Beatsは用途ごとに分かれた単機能の送信プログラム群です。ログファイルはFilebeat、OSメトリクスはMetricbeat、WindowsイベントログはWinlogbeat、通信の観測はPacketbeat、死活監視はHeartbeatが担当します。ログとメトリクスの両方を集めるなら、ホストごとに2つの常駐プロセスが必要になります。

Filebeatはファイルの読み取り位置をレジストリに保持し、再起動しても続きから送ります。出力先はElasticsearch・Logstash・Kafka・Redis・File・Consoleから選べる構成です。単機能ゆえに設定ファイルが読みやすく、構成管理ツールでの配布と相性が良い点が利点になります。

Elastic AgentとFleet｜統合パッケージと集中管理で減る設定作業

Elastic Agentは、複数のBeatsが担っていた機能を1つのバイナリへまとめたものです。ホストには1プロセスだけを置き、何を収集するかはKibanaのFleet画面から配るポリシーで指定します。公式ドキュメントはElastic Agent managed by Fleet is the recommended option for most usersと明記し、Filebeatのモジュールよりも統合パッケージ側を推奨しています。

この差が効くのは台数が増えたときです。Beatsは設定変更のたびに全ホストへ配布し直しますが、Fleet管理ならポリシーを更新すればエージェント側が取りに来ます。統合パッケージはingest pipelineとダッシュボードを同時に入れるため、標準フィールドへ載せる作業も省けます。

9.0で入ったOTelモード｜EDOT内蔵とFilebeat receiverの効果

9.x系で構成が一段変わりました。EDOT Collector（Elastic Distribution of OpenTelemetry Collector）がElastic Agentに内蔵され、AgentをOpenTelemetryモードで動かすとトレース・メトリクス・ログを同じ経路で転送できます。

9.0.0ではFilebeat receiverが入り、Filebeatの入力をコレクタのレシーバとして動かす形が既定になりました。Beatのサブプロセスを別に起動しないぶん、待機時のメモリ消費が下がります。すでにOpenTelemetryで計装しているアプリがあるなら、ログの経路もここへ寄せると送信側の常駐が1つで済みます。使っていない環境で無理に寄せる利点は小さく、通常モードのElastic Agentで十分です。

移行を止める条件｜Redis出力・ローカル退避・keystoreの不足

Elastic Agentが常に上位互換というわけではありません。公式の比較表には、Beatsにしかできないことが残っています。

機能	Beats	Elastic Agent
Elasticsearch出力	対応	対応
Logstash出力	対応	対応
Kafka出力	対応	対応
Redis出力	対応	非対応
File・Console出力	対応	非対応
ローカルディスク退避	対応	検討中の段階
認証情報の保管場所	ローカル	エージェントポリシー

実務で効くのは下の3行です。配送先にRedisが挟まる環境、送信側でディスクへ溜めて回線断に耐える設計、認証情報をローカルの秘密情報として扱いたい要件のいずれかがあるなら、Beatsを続ける判断が現実的になります。移行判定は「必要な統合がGAか」「必要な出力が対応するか」の2点を先に確認してください。

Logstashを挟む構成と外す構成｜整形の位置と障害時の緩衝設計

ELKという名前に引きずられてLogstashを必ず立てる構成が多く見られますが、9.x系では常設しない構成のほうが運用は軽くなります。挟む理由を要件から言語化しておきます。

Logstashを外してよい条件｜ingest pipelineで足りる整形の範囲

統合パッケージで対応済みのミドルウェアだけを集めるなら、Logstashは不要です。Nginx・Apache・PostgreSQL・システムログといった定番は、統合を入れた時点でingest pipelineが登録され、パース済みのフィールドで入ってきます。自作アプリのログも、JSONで出しておけばjsonプロセッサ1つで型が付きます。

Logstashが要るのは、整形の内容が重いか、宛先が複数あるときです。外部APIを叩いて情報を付与する、大きなイベントを分割する、同じログをオブジェクトストレージへも配る、といった処理はLogstash側が書きやすく、Elasticsearchのノードへ計算負荷を載せずに済みます。

永続キューの設定値｜queue.typeとmax_bytesの既定と容量計算

Logstashを緩衝として使う場合、既定のままでは意味がありません。queue.typeの既定値はmemoryで、プロセスが落ちればメモリ上のイベントは消えます。ディスクへ書くにはpersistedへ変更してください。保存先の既定はpath.data/queue、queue.max_bytesは1024mb、queue.checkpoint.writesは1024です。

容量は公式の式で見積もります。1時間あたりの受信バイト数に、許容する停止時間の時間数と、データ形態ごとの膨張係数を掛けた値が必要容量です。この係数の幅が大きく、58KB級の大きなドキュメントはほぼ1.01倍で収まる一方、短いプレーンテキストのイベントでは最大18倍を超える例が示されています。行単位の短いログでは、素の流量から見積もると足りません。

保護範囲にも限界があります。TCP・UDP・ZeroMQのように受信確認のない入力では取りこぼしを防げず、チェックポイント書き込み前の異常終了では欠損し、ディスク破損やマシン喪失は対象外です。キューは複製されません。可用性まで求めるならKafka前置の段階です。

Kafkaを前段に置く構成｜複数系統への配送と再処理という要件

kafka・logstash・elasticsearchを直列に並べる構成は、要件が2つ揃ったときに選びます。1つは同じログを複数の系へ配ること。ログ検索基盤とストリーム処理基盤へ同じイベントを流すなら、トピックを共有すれば送信側は1系統で済みます。もう1つは再処理で、マッピングを直してから過去分を入れ直すとき、保持期間内のトピックから読み直せます。

この2つが無いなら、Kafkaは運用対象を1つ増やすだけです。BeatsもElastic AgentもKafka出力に対応するため、Logstashを介さず直接トピックへ書く形も取れます。判断軸は「配送先が複数か」「再取り込みが要件か」の2点だけです。Logstashを介す場合のinput設定と重複の扱いはLogstash Kafka連携の設計にまとめています。

インデックス分割の設計｜データストリーム命名と保持単位の切り分け

ログ基盤の運用費と権限管理は、インデックスの分け方でほぼ決まります。統合を使うと命名規則が自動で適用されますが、namespaceだけは設計者が決める値です。

type-dataset-namespaceの三要素で分ける命名と権限の粒度

Elastic Agentのデータストリームはtype-dataset-namespaceの三要素で命名されます。typeはlogs・metrics・traces・synthetics等のデータ種別、datasetは統合が定める取得対象、namespaceは利用者が決める任意のグループで、上限は100バイトです。Nginx統合をprod名前空間で動かすとlogs-nginx.access-prodが生成されます。

適用には条件があります。全ドキュメントがdate型またはdate_nanos型の@timestampを持ち、書き込みが追記中心で、同一IDの上書きに依存しないことの3つです。分割の狙いはフィールド数の膨張を抑えることにあります。全ログを1インデックスへ入れるとマッピングが数万フィールド規模になる一方、データセット単位なら各インデックスが持つのは自分の項目だけです。公式ドキュメントはロールオーバー・保持期間・セキュリティ権限を個別に持てる点を利点に挙げています。namespaceを環境で割れば本番だけ保持を延ばせ、部署で割れば参照権限を閉じられます。

業務検索と同居させない線引き｜クラスタ分離とノード役割の指定方法

ログと業務検索を1つのクラスタに同居させると、取り込みの山が検索の応答時間を押します。ログは書き込み量が読み取り量を上回り、業務検索は逆になるため、要求されるノード構成が食い違うからです。

分ける基準は運用側の指標で決めます。日次取り込みが数十GBを超える、または検索に応答時間の約束があるなら、クラスタを分けてください。同居させる場合は、データ層のノードにhot・warmの役割を割り当て、ログのデータストリームをhot層へ固定したうえで業務検索用インデックスと物理ノードを分けます。ノード役割とシャード本数の考え方はElasticsearchのクラスタ設計の章に整理しました。

保管費を左右する三つの設定｜logsdb・ロールオーバー・凍結層

ログ基盤の費用はディスクとノード数で決まります。9.x系では既定のまま使うだけで効く設定が入っており、まずそこを崩さないことから始めます。

logsdbインデックスモード｜9.0以降の既定と6割削減の代償

logsdbはログ向けの保存モードで、index templateのindex.modeをlogsdbにすると有効になります。Elastic Stack 9.0以降は、logs-*-*に一致する新規データストリームへ自動で適用されます。8.x時代から存在するデータストリームは自動適用の対象外で、こちらは明示指定が必要です。

公式の計測では、保存容量を最大60%削減し、取り込み性能への影響は10〜20%と示されています。ディスクを6割減らす代わりに取り込みが2割ほど遅くなる交換条件なので、取り込みが常時ピーク近くで回っている基盤では、ノードを増やす前にこの影響を切り分けてください。9.5時点では列指向で保存するlogsdb_columnarがPreview提供で、本番へ当てる段階ではありません。

ロールオーバー条件の決め方｜主シャード容量と非推奨になった設定

ロールオーバーは、書き込み先のバッキングインデックスを切り替える操作です。上限条件はmax_age、max_docs、max_primary_shard_size、max_primary_shard_docsの4つで、最低1つの指定が要ります。かつて使われたmax_sizeは9.3で非推奨です。インデックス全体の容量はシャード数に左右されるため、主シャード単位の指定へ寄せる流れになりました。

実務では主シャード容量と経過日数の併用が扱いやすくなります。容量条件だけでは流量の少ないデータストリームが切り替わらず、経過日数だけでは突発的な増加で1インデックスが肥大化するためです。なお、空のインデックスはmax_ageを満たしてもロールオーバーしません（min_docsを0に指定した場合を除く）。加えて、いずれかのシャードが200000000ドキュメントに達すると、条件に関係なく暗黙にロールオーバーされます。

凍結層とsearchable snapshot｜Enterpriseという前提

ILMのフェーズはhot・warm・cold・frozen・deleteの5つです。ILMはElastic Stackの全デプロイ形態で使えますが、Elasticsearch Serverlessでは使えません。ポリシーの構造とmin_ageの起点、データストリームライフサイクルとの分担はElasticsearchのILMとフェーズ設計で扱っています。

ここに費用計画へ響く制約があります。cold層とfrozen層はsearchable snapshotで容量と運用費を下げる仕組みですが、そのsearchable snapshotはEnterpriseライセンスを必要とする機能です。無償のBasicで組む前提の基盤なら、cold・frozen前提の保管費試算は成立しません。長期保管はクラスタ外のスナップショットへ出して必要時に復元するか、ライセンス費と削減額を並べて比較する判断になります。ライセンス系列の選び分けはElasticsearchとOpenSearchの違いで整理しています。

保持日数の逆算｜監査要件と再調査の頻度から日数を決める判断軸

保持日数を「念のため1年」で決めると費用が跳ねます。決め方は逆算です。まず外部要件を確認し、監査やセキュリティ規程で保存年数が指定されているログは、その年数を下限に置きます。次に社内の利用実態を見てください。障害調査でさかのぼる期間の実績が2週間なら、検索可能な状態で置くのはその範囲で足ります。

この2つを分けて設計するのが要点です。検索性が必要な期間はhot・warmでデータストリームに置き、監査目的の長期保管はスナップショットとして安価なストレージへ出す。両方を同じ層で賄うと、めったに検索しないデータのために高速ストレージを持ち続けることになります。namespaceを用途で割っておけば、この日数は個別に変えられます。

自前ELKを採用してよい条件と、見送って外部サービスへ寄せる場面

ここは条件を付けて言い切ります。ELKを自前で組むかどうかは、取り込み量ではなく運用に割ける人手で決まります。

自前運用を選ぶ条件｜取り込み量・保持年数・機能要件の三点の確認

次の3条件が揃うなら自前運用が有利です。第一に、日次取り込みが安定して数十GB以上あり、従量課金のログサービスでは費用が読みにくいこと。第二に、保持年数の要件が長く、保管先を自分で選べる利点が効くこと。第三に、全文検索やベクトル検索など、ログ検索以外の機能を同じ基盤で使う予定があること。

この3つのうち2つ以上に当てはまるなら、クラスタ運用の手間を払う価値があります。検証は本番と同じ版のコンテナで先に組むのが早く、単一ノードと3ノードの立ち上げ方はElasticsearchのDocker構築の手順にまとめています。

見送る場面｜運用人数を割けないときに外部へ寄せるときの判断基準

逆に、次の場合は自前ELKを見送ってください。クラスタの面倒を見る担当が実質1人以下、版upgradeの計画を持てない、夜間のノード障害に応答できる体制がない。この状態で踏み込むと、ディスク枯渇でクラスタが読み取り専用へ落ちた場面などで復旧が長引きます。ログ基盤は障害調査で使う道具なので、障害時に道具側が落ちている構成は目的を果たしません。

この場合はマネージドのElastic Cloudか、課金体系の違うログサービスへ寄せる判断が妥当です。取り込み量課金と保管量課金の切り分け方はDatadogのログ収集3経路とインデックス制御が参考になります。どの構成を選んでも、送信側の設計とデータの分け方は同じ検討です。自社で決めきれない場合は、データ分析基盤構築の支援で要件の整理から構成設計まで引き受けています。

よくある質問

ELKでのログ収集を検討する場面で実際に多い質問を、判断に必要な範囲で答えます。

ELKスタックとElastic Stackは何が違いますか？

指す対象はほぼ同じで、呼び方の世代が違います。ELKはElasticsearch・Logstash・Kibanaの頭文字で、Logstashが収集と整形の両方を担っていた時期の通称です。その後にBeatsとElastic Agentが加わり、総称はElastic Stackへ変わりました。現在はLogstashを置かない構成もあるため、社内資料では「Elastic Stack（旧称ELK）」と併記しておくと認識のずれが起きません。

Logstashは必ず必要ですか？

不要な構成が組めます。Elastic AgentやFilebeatからElasticsearchへ直接送り、整形はingest pipelineで行う形が9.x系では標準的で、統合パッケージを入れればミドルウェア用のpipelineも一緒に登録されます。Logstashを入れる判断は、重い整形をクラスタ外へ出したい、同じログを複数の宛先へ配りたい、ディスクへ溜めて回線断に耐えたいのいずれかに当てはまるときです。

FilebeatとElastic Agentはどちらを入れるべきですか？

新規ならFleet管理のElastic Agentが公式の推奨です。1ホスト1プロセスで済み、収集内容の変更をKibana側から配れます。ただしRedis出力やFile出力を使っている、送信側でディスクへ退避したい、認証情報をローカルのkeystoreで持ちたい、といった要件があるならBeatsを続ける判断になります。必要な統合がGA提供かどうかも移行前に確認してください。

ログの保持期間は何日にすればよいですか？

監査要件の年数と、障害調査でさかのぼる実績の日数を分けて決めます。検索可能な状態で持つのは後者の範囲とし、監査目的の長期保管はスナップショットへ出す形が費用の面で無理がありません。namespaceを環境や用途で割っておけば、本番だけ長く開発環境は短くといった設定を個別に当てられます。cold層やfrozen層を使う設計は、searchable snapshotがEnterpriseライセンス前提である点を織り込んでください。

Elasticsearchのログ基盤は無料で運用できますか？

Basicの範囲でも構築できます。データストリーム、ILM、Fleet管理のElastic Agent、logsdbインデックスモードはいずれも標準機能として使えます。費用が発生するのはサーバとストレージ、そして上位機能を使う場合です。cold・frozen層で使うsearchable snapshotはEnterpriseライセンスを必要とするため、長期保管の費用計画をこの機能に依存させる構成は、ライセンス費まで含めて試算してください。