はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富( @yannKazu1 )です。 先日、本番環境でドキュメントの大規模更新を行った際にCPUが100%に張り付く事象が発生しました。検証環境で同じ更新処理を試しても再現せず、原因がわからない。そこで「そもそも自分、Elasticsearchの中で何が起きてるかちゃんと理解してないな」と気づき、インデキシングから検索までの仕組みを一から整理してみました。 同じように「なんでこうなるの？」と悩んでいる方の助けになれば嬉しいです。 前提知識 本記事では、Shard内部の動作にフォーカスして説明していきます。「そもそもShardって？Segmentって？」という方は、 メルカリさんのこちらの記事 がとてもわかりやすいので、先に読んでおくことをおすすめします。 全体の流れ まず、大枠の流れを押さえておきます。 インデキシング開始 — ドキュメントがメモリバッファに蓄積される Refresh — メモリバッファの内容からセグメントが作られ、検索可能になる 検索 — すべてのセグメントを対象に検索が実行される セグメントマージ — 小さなセグメントが統合され、削除済みデータも物理削除される シンプルに書くとこれだけなんですが、それぞれの段階で「何が起きているのか」「どんな時に負荷が上がるのか」を知っておくと、トラブル時の原因切り分けがしやすくなります。 では、各ステップを詳しく見ていきましょう。 1. インデキシング開始 ドキュメントがインデキシングされると、まずメモリバッファに蓄積されます。同時に、各シャードの Transaction Log（translog） にも操作が記録されます。 Lucene commitは変更のたびに実行するとコストが高すぎるため、その役割をtranslogが担います。万が一プロセスの終了やハードウェア障害が発生しても、translogから操作を再生することでデータを復旧できます。 なお、デフォルト設定（ index.translog.durability: request ）では、各リクエストごとにtranslogへのfsyncが発生するため、ディスクI/Oが完全にゼロというわけではありません。 参考ドキュメント： Near real-time search | Elastic Docs Translog settings | Reference 2. Refreshによるセグメント生成 デフォルトでは 1秒ごと にRefresh処理が走ります。この処理で、メモリバッファの内容がファイルシステムキャッシュに書き込まれ、 immutable（不変）なセグメント が新たに作られます。ここで初めて、そのデータが検索可能になります。 RefreshとFlush、何が違うの？ ここで似た名前の処理が出てくるので、先に整理しておきます。この2つ、最初は「同じようなもの？」と思っていたんですが、実は 全く別の操作 です。 操作 やっていること 重さ 目的 Refresh メモリバッファ → メモリ内セグメント作成（ファイルシステムキャッシュ経由） 軽め 検索できるようにする Flush Lucene commit + translogクリア（ディスクに永続化） 重い データを永続化する 重要なのは、 検索可能にするのはRefreshだけ ということです。Flushは永続化のための処理であり、検索可能性には影響しません。検索はメモリ内のセグメントに対して行われるため、Refreshでセグメントが作られて初めて検索できるようになります。 Flushは、translogが一定サイズに達した時や、一定時間が経過した時に発生します。 Search Idleルール ここで重要なルールがあります。自動Refreshは、過去30秒以内に検索リクエストがあったインデックスだけが対象です（厳密にはシャード単位で管理されます）。つまり、検索トラフィックがあるシャードには定期的なRefresh（デフォルト1秒ごと）が走りますが、検索されていないシャードはバックグラウンドRefreshがスキップされ、リソースが節約される仕組みになっています。これはバルクインデックス時のパフォーマンス最適化を目的とした機能です。 「Refreshがスキップされている間に追加されたデータはどうなるのか」と疑問に思われるかもしれませんが、心配は不要です。アイドル状態のシャードに検索リクエストが来ると、その検索操作の一部としてRefreshがトリガーされ、完了してから検索結果が返されます。つまり、データ自体は問題なく検索できます。ただし、アイドル状態からの最初の検索はRefresh完了を待つ分、レスポンスが遅くなる可能性がある点には注意が必要です。 とはいえ、本番環境と検証環境では動きが変わってくる可能性がある点がポイントです。本番では常にユーザーが検索しているので定期Refreshが走ります。しかし検証環境では誰も検索していない場合、シャードがアイドル状態になり、検索時に初めてRefreshが走ります。同じ更新処理でも、裏側で起きていることがまったく異なる場合があります。 Refresh間隔は調整できます index.refresh_interval で設定可能です。大量データを投入する時は、この値を大きくしておくとセグメント数を減らすことができます。なお、アイドル判定の時間は index.search.idle.after （デフォルト30秒）で変更できます。 PUT /my-index/_settings { "index" : { "refresh_interval" : "30s" } } 参考ドキュメント： Near real-time search | Elastic Docs - Refreshの仕組み、ファイルシステムキャッシュ経由でのセグメント生成 Refresh API | Elasticsearch Guide - Refresh APIの詳細、30秒ルール Translog settings | Elastic Docs - FlushとTranslogの関係、Lucene commitの説明 General index settings | Elastic Docs - index.search.idle.after 設定、Search Idle機能の詳細 短期間に大量更新すると何が起きるか さて、ここからが本題です。短期間に大量の更新が発生すると、Refreshのたびに 小さなセグメントがどんどん作られていきます 。 セグメントはimmutableなので、「既存のセグメントにちょっと追加」ということができないんです。更新のたびに新しいセグメントを作るしかない。結果として、細かいセグメントが山のように溜まっていきます。 これが引き起こす問題 セグメントが増えると検索が遅くなる ファイルディスクリプタをたくさん消費する 後で説明するマージ処理の負荷が大きくなる 対策 大量にインデックスする時は refresh_interval を -1 （無効）にしておいて、終わったら手動でRefreshする。これだけでだいぶ違います。 参考ドキュメント： Tune for indexing speed | Elastic Docs 削除処理の仕組み ドキュメントを削除する時、実際にデータを消しているわけではありません。セグメントがimmutableである以上、「この部分だけ消す」ができないんです。 じゃあどうするかというと、 削除フラグ（tombstone）を付けて「削除済み」とマークする だけ。いわゆる論理削除ですね。 実際の流れ 削除リクエストが来る 対象ドキュメントに削除フラグを付ける 検索時はフラグ付きのドキュメントを結果から除外する 後でセグメントマージが走った時に、やっと物理的に削除される つまり、削除したつもりでも マージが完了するまでディスク容量は減らない んです。「削除したのに容量減らないな...」と思ったことがある方、これが原因かもしれません。 参考ドキュメント： Force merge API | Elasticsearch Docs 3. 検索時に何が起きているか 検索処理では、 すべてのセグメントに対して検索が実行されます 。各セグメントの結果をマージして、最終的な検索結果ができあがります。 ここで「セグメントが増えると検索が遅くなる」理由がわかりますよね。検索対象が増えれば増えるほど、当然時間がかかります。 キャッシュの話も重要です Elasticsearchには主に2種類のキャッシュがあるんですが、どちらもセグメントの変更に影響を受けます。 キャッシュ 単位 いつ無効化される？ Node query cache セグメント単位 セグメントがマージされた時 Shard request cache シャード単位 シャードがリフレッシュされた時 新しいセグメントにはまだキャッシュがないので、最初のクエリは必ずキャッシュミスになります。しかもマージが走るとせっかく溜めたキャッシュも消えてしまう。 セグメントが頻繁に作られたりマージされたりする環境では、キャッシュがなかなか効かなくなります。 参考ドキュメント： Tune for search speed | Elastic Docs Node query cache settings | Reference 4. セグメントマージ — 重い処理 バックグラウンドで定期的にセグメントのマージ処理が走ります。小さなセグメントをまとめて大きなセグメントにする処理です。この際、転置インデックスの再構築が行われるため、CPUとI/Oを大量に消費します。 マージがもたらすメリット 細かいセグメントが大きなセグメントに統合されます 削除フラグ付きのドキュメントが物理削除されます セグメント数が減るため、検索が高速化します ただし、マージ中は重い マージ自体はとても重い処理です。マージが走っている間は、検索もインデキシングも影響を受けます。 ElasticsearchにはAuto-throttling（自動スロットリング）という仕組みがあり、マージがインデキシングに追いつけなくなると、インデキシング自体にブレーキがかかります。これは「セグメント爆発」を防ぐための安全装置です。 セグメントマージがどんな感じで進むのか、視覚的に理解したい方は こちらの記事 がおすすめです。 参考ドキュメント： Merge settings | Reference Force merge API | Elasticsearch Docs まとめ 長くなりましたが、ここまで読んでいただきありがとうございます。 今回学んだことで特に大事だなと思ったのは、この3つです。 セグメントはimmutable — 更新・削除のたびに新しいセグメントができる Refreshの30秒ルール — 検索がないシャードはRefreshがスキップされる マージは重い — CPU・I/Oを大量に使い、キャッシュも無効化される 本番環境で「なんか重いな」と思った時は、セグメントの状態やマージの発生状況も見てみてください。きっと何かヒントが見つかるはずです。 もし同じような問題で悩んでいる方がいたら、この記事が少しでも参考になれば嬉しいです。 ちなみに、今回の調査をきっかけに、チームメンバーがElasticsearchの詳細な状況を収集できる仕組みを整えてくれました。実際のデータをもとにした分析や考察、情報収集するための観点や方法については、そのメンバーが続編で紹介してくれるかもしれません。お楽しみに！

RAG＝ベクトルDBは誤解。BM25、Web検索、GraphRAGなど7つの手法を比較表で整理。データ規模・コスト・精度での選び方を解説します。 はじめに 「RAGを導入したい」という話になると、多くの場合「じゃあベクトルDBを選定しなきゃ」という流れになります。 弊社でもRAG構築・導入支援サービスを提供しており、RAGについて説明する機会が多くあります。その中で「RAG」と「ベクトル検索」を同じ文脈で質問されることがよくあります。 確かに、トレンドとしてRAGとベクトル検索を同じ文脈で語ることは間違いではありません。しかし、実はChatGPTやClaudeの検索機能もWeb検索エンジンと連携した「RAG」の一種です。 本記事では、RAGの原論文に立ち返り、 RAGの本質は「検索手法」ではない ということを整理します。そして、ベクトル検索以外にどのような外部情報の取り込み方があるのかを俯瞰的に紹介します。 RAGの定義に立ち返る RAGとは何か RAG（Retrieval-Augmented Generation：検索拡張生成）とは、LLM（大規模言語モデル）に外部の情報を与えることで、回答の精度を向上させる手法です。LLMは学習データに基づいて回答を生成しますが、学習後の最新情報や社内固有の知識は持っていません。RAGはこの課題を「外部から必要な情報を検索して補う」というアプローチで解決します。 RAGの階層構造を整理する RAGを理解するために、以下の階層構造を整理しておきましょう。 ここで重要なのは、 RAGの本質は「外部知識をコンテキストに補うアプローチ」であり、「どう取り込むか」は手段の話 だということです。ベクトル検索は実装選択肢の一つに過ぎません。 原論文（Lewis et al., 2020）の定義 RAGの原論文 では、RAGを以下のように定義しています。 “models which combine pre-trained parametric and non-parametric memory for language generation” （言語生成のために、事前学習済みのパラメトリックメモリと非パラメトリックメモリを組み合わせたモデル） パラメトリックメモリ : LLMが学習時に獲得した知識（モデルの重みに格納） 非パラメトリックメモリ : 外部から取得する知識（検索で取得） 注目すべきは、この定義に「ベクトル検索」という限定がないことです。論文の実装例ではDPR（Dense Passage Retrieval）というベクトル検索手法が使われていましたが、RAGの定義自体は「外部知識をどのように取得するか」を限定していません。 論文における概念の発展 RAGという概念は、様々な論文が発表される中で発展を続けています。 2020年 : RAGは「BART + DPR」という 特定のモデルアーキテクチャ として提案されました。論文では “RAG models”、”fine-tuning recipe” といった用語が使われています。 2024年 : RAGは「外部知識とLLMを統合するための 包括的な概念 」として再定義されています（ RAG Survey 、 Modular RAG ）。”RAG paradigms”、”framework”、”LEGO-like framework” といった用語が使われ、単一の技術ではなく 目的達成のための概念・考え方 として扱われています。 補足 : RAGの発展段階（Naive → Advanced → Modular）や各手法の数値的な比較については、弊社ブログ「 RAGはどのように進化しているのか？ 」で体系的に解説しています。本記事では「RAGとは何か」という概念の整理に焦点を当てます。 RAGにおける外部情報の取り込み方 RAGを実現するための外部情報の取り込み方は、ベクトル検索だけではありません。ここでは代表的な手法を紹介します。 手法選択の考え方は「 ユースケースに適した方法で、必要な情報をLLMに与える 」です。各手法には得意な情報の特性があり、ユースケースに応じて選択します。また、単一の手法だけでなく、複数の手法を組み合わせることも有効な選択肢です。 なお、どの手法を選択しても、導入して終わりではありません。精度測定と継続的なメンテナンス（チューニング、データ更新、クエリ最適化など）は共通して必要な取り組みです。 ベクトル検索型 埋め込みベクトルによる意味的類似度検索を行う手法です。 特徴 : 意味的な類似性を捉えられる 適したユースケース : 「〇〇に似た事例は？」「関連するドキュメントを探したい」など、意味的に類似した情報を探す場面 実現キーワード : Auzre AI Search , Pinecone, FAISS, pgvector, Milvus, Chroma, Weaviate, Qdrant キーワード検索型（BM25） 従来の全文検索アルゴリズムを活用する手法です。 特徴 : 完全一致が重要な場面で有効 適したユースケース : エラーコード検索、法律条文、製品型番、固有名詞など、完全一致・部分一致が重要な場面 実現キーワード : Auzre AI Search, Elasticsearch, OpenSearch, Apache Solr, Whoosh ハイブリッド検索型 ベクトル検索とキーワード検索を組み合わせ、リランキングと併用する手法です。 特徴 : 意味的類似性と完全一致の両立 適したユースケース : 意味的類似性と完全一致の両方が求められる場面、大規模データで高い検索精度が必要な場面 実現キーワード : Azure AI Search, Elasticsearch (kNN + BM25), OpenSearch, Pinecone (Hybrid), Weaviate (Hybrid) Web検索型 外部検索エンジンと連携してリアルタイム情報にアクセスする手法です。 特徴 : リアルタイム情報へのアクセスが可能 適したユースケース : 最新ニュース、現在の価格・在庫、イベント情報など、リアルタイム性が求められる情報 実現キーワード : ChatGPT Search, Claude Web Search, Gemini Grounding, Perplexity, Bing API, Google Custom Search API 構造化検索型 ナレッジグラフや構造化データベースを活用する手法です。 GraphRAG ナレッジグラフを活用し、エンティティ間の関係を検索 適したユースケース : 「AとBはどう関係する？」「〇〇に関連する人物は？」など、関係性を辿る必要がある場面 SQL検索 構造化データからの正確なデータ取得 適したユースケース : 売上データ、在庫数、ユーザー情報など、構造化データから正確な値を取得する場面 実現キーワード : Neo4j, Amazon Neptune, Azure Cosmos DB (Gremlin), PostgreSQL, BigQuery マニュアルRAG（人力補填型） 人間が選択的に文章を補填する手法です。 特徴 : 文脈理解や暗黙知の活用が可能 適したユースケース : PoC・少量運用、暗黙知の活用、システム化前の検証、文脈依存で人間の判断が必要な場面 実現キーワード : コピー&ペースト、社内Wiki参照、ドキュメント手動選択 実は、ChatGPTやClaudeにファイルをアップロードして質問するのも、広義ではマニュアルRAGの一種と言えます。言葉が異なるだけで、概念的にはRAGを触っている機会は多いのかもしれません。 手法の分類まとめ 手法の全体像 手法選択の比較表 手法 情報の特性 データ規模 初期コスト 運用負荷 精度安定性 ベクトル検索 意味的類似 大規模対応 高 中〜高 高 BM25 完全一致 大規模対応 中 低〜中 高 ハイブリッド 両方 大規模対応 高 高 最高 Web検索 リアルタイム 外部依存 低 低 外部依存 GraphRAG 関係性 中規模向き 高 高 ユースケース依存 SQL検索 構造化データ 大規模対応 中（既存活用） 低〜中 高 マニュアルRAG 文脈依存 小規模のみ 低 高（人的） 人依存 まとめ 本記事では、RAGの本質と外部情報の取り込み方について整理しました。 RAGは単一の技術ではなく、LLMの回答精度を向上させるための概念です。 論文でも2024年以降は「パラダイム」「フレームワーク」として扱われています。 RAGの目的は「要求される回答精度の達成」です。 手法はあくまで目的達成のための手段であり、ベクトル検索は選択肢の一つに過ぎません。 ただし、ベクトル検索が有効なケースが多いのも事実です。 大規模データで意味的な検索が必要な場面では、ベクトル検索やハイブリッド検索が有効であり、多くのRAGシステムで採用されています。それが唯一の選択肢ではない、ということです。 手法選択は戦略的判断です。 精度要件、コスト、スケール、運用負荷を考慮し、ユースケースに応じて最適な取り込み方を選びましょう。 RAG導入をご検討の方へ 弊社では、RAGを活用したソリューションを提供しています。 社内ナレッジ活用AIチャット導入サービス : お客様のAzure環境に弊社RAGプロダクトを構築します。導入だけでなく、導入後の精度改善の支援や、利用普及に向けた支援などトータル的にサポートを行います。 RAGスターターパック : RAGプロダクトをスピーディーに導入します。、チャットUI＋回答精度の評価・改善のためのオールインワン基盤をご提供しています。導入後はお客様側で自由なカスタマイズを実地いただけます。とりあえず試してみたい！という方にお勧めです。 「RAGを導入したい」「どの手法を選べばいいかわからない」「RAGの精度が出ない」といったお悩みがあれば、お気軽にご相談ください。 参考文献 Lewis, P., et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401. https://arxiv.org/abs/2005.11401 Gao, Y., et al. (2024). “Retrieval-Augmented Generation for Large Language Models: A Survey.” arXiv:2312.10997. https://arxiv.org/abs/2312.10997 Gao, Y., et al. (2024). “Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks.” arXiv:2407.21059. https://arxiv.org/abs/2407.21059 関連記事 RAGはどのように進化しているのか？ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ベクトル検索以外のRAG手法7選｜比較表付き解説 first appeared on SIOS Tech Lab .

目次 はじめに 開発環境 構成図 事前準備 リポジトリの取得と展開 環境変数の設定 コンテナの起動 EDOT Collector の設定 5.1. Python コンテナへの接続 5.2. EDOT Collector のダウンロード Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 6.2. API Key の生成 6.3. otel.yml の編集 6.4. EDOT Collector の起動 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する 7.2. 計装 (Instrumentation) の準備 7.3. Python アプリの実行 観測データの確認 8.1. Dashboard の表示 8.2. Logs の表示 8.3. トレースの表示 まとめ 参考URL はじめに これまで Elastic Observability でフルスタックな観測を実現するには、Fleet Server や Elastic Agent、および各 Integration（System, APM等）の個別設定が必要でした。 しかし、最新の Elastic Observability (v9.2以降) では、OpenTelemetry (OTel) をネイティブにサポート。 これにより、独自エージェントの複雑な管理をスキップして、より標準的かつ柔軟にデータを集約できるようになりました。 本記事では、この新しい機能の使い方を解説します。 開発環境 Elasticsearch / Kibana: v9.2.4 Basic License Python : v3.14 Docker環境 : 筆者は Windows 上の Rancher Deskop 1.20.1 を利用 ※ステータス: OpenTelemetry Integration は、Elasticsearch 9.2 時点で Preview です。 構成図 今回の構成では、Pythonアプリケーションが稼働するコンテナ内に EDOT (Elastic Distribution of OpenTelemetry) Collector を配置し、そこから直接 Elasticsearch へデータを送信します。 事前準備 リポジトリの取得と展開 まずは検証用コードをダウンロードします。 https://github.com/SIOS-Technology-Inc/elastic-blogs/tags  にアクセスします。 release-2026-02-02 をクリックします。 Assets の Source code (zip) をクリックします。 elastic-blogs-release-2026-02-02.zip がダウンロードされます。 elastic-blogs-release-2026-02-02.zip を解凍します。 環境変数の設定 Windows などでターミナルを開きます。 2026-02-otel/app フォルダに移動します。 cd 2026-02-otel/app .env.sample をコピーして、パスワードやメモリ制限などの環境変数を設定します。 cp .env.sample .env メモ帳などで .env ファイルを編集します。 ... ELASTIC_PASSWORD=... (Elasticsearchのパスワードを設定します。) KIBANA_PASSEORD=... (Kibana用の内部パスワードを設定します。) ... SAVEDOBJECTS_ENCRYPTIONKEY=... (SavedObjects用の暗号化キーを設定します。) ... ES01_MEM_LIMIT=... (Elasticsearchのメモリ上限を設定します。) KB_MEM_LIMIT=... (Kibanaのメモリ上限を設定します。) コンテナの起動 docker compose -f docker-compose-es-kibana-python.yml up -d EDOT Collector の設定 5.1. Python コンテナへの接続 ※今回は、Python を動かすコンテナに Elastic Distribution of OpenTelemetry (EDOT) Collector をインストールするので、Python コンテナへ接続します。 root 権限でインストールおよび実行するので、-u 0 を指定します。 docker exec -itu 0 app-python-app-1 /bin/bash 5.2. EDOT Collector のダウンロード 下記で Elastic 9.2.4 用の EDOT Collector をダウンロードします。 wget https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.2.4-linux-x86_64.tar.gz tar xvfz elastic-agent-9.2.4-linux-x86_64.tar.gz cd elastic-agent-9.2.4-linux-x86_64 # 設定用ディレクトリの作成とサンプルのコピー mkdir data/otel cp ../otel.yml.sample otel.yml otel.yml.sample は、あらかじめ elastic-agent-9.2.4-linux-x86_64 内の otel.yml.sample を抽出し、改変したものです。 exporters/elasticsearch/otel/tls などを改変しています。 ※otel.yml の編集は、後で行います。 Elasticsearch との連携設定 6.1. System OpenTelemetry Assets の有効化 Web ブラウザから  http://localhost:5601  へアクセスし、 ユーザーID: elastic パスワード: 4.2. で ELASTIC_PASSWORD に設定した文字列 で Kibana にログインします。 Management / Integrations 画面を表示します。 Display: beta integrations を ON にします(※System OpenTelemetry Assets は、Elastic 9.2.4 の時点では Preview 版のため)。 System OpenTelemetry Assets を検索し、クリックします。 右上の [↓ Install System OpenTelemetry Assets] ボタンをクリックします。 Install System OpenTelemetry Assets のダイアログが表示されるので、右下の [Install System OpenTelemetry Assets] ボタンをクリックします。 ※Assets欄にあるダッシュボードがインストールされます。 6.2. API Key の生成 EDOT Collector から Elasticsearch へ書き込むための API Key を生成し、控えておきます。 Kibana の Home 画面から Elasticsearch アイコンをクリックします。 [Create API key ] ボタンをクリックします。 Name : otel と入力し、[Create API key] をクリックします。 API Key が生成されるので、コピーしておきます（メモ帳などに一時的にペーストしておきます）。 6.3. otel.yml の編集 Python を動作させているコンテナ上で作業します。 vi otel.yml 取得した API Key を 5.2. で配置した otel.yml に反映させます。 ... exportes: elasticsearch/otel: endpoints: ["https;//es01:9200"] api_key: "YOUR_API_KEY_HERE" ... 6.4. EDOT Collector の起動 今回は、あくまでも検証用のための実行なので、ターミナルからバックグラウンドで実行します。 ./otelcol --config ./otel.yml >> /var/log/otelcol.log 2>&1 & これで、Python コンテナのログやメトリクスが Elasticsearch へ送信されるようになります。 このコンテナからは、exit して OK です。 Python アプリのトレース取得 7.1 appuser で Python コンテナへ接続する docker exec -it app-python-app-1 /bin/bash 7.2. 計装 (Instrumentation) の準備 OpenTelemetry のライブラリをインストールします。 edot-bootstrap --action=install opentelemetry-bootstrap -a install 7.3. Python アプリの実行 コードに Elastic 専用の処理を書く必要はありません。 opentelemetry-instrument を冠して実行するだけで、自動的にトレースが送信されます。 実行する Python アプリ (src/test.py) のソースコード 3回ループするだけの単純な Python コードです。 import time from opentelemetry import trace def func1_sub(tracer): with tracer.start_as_current_span("func1_sub"): print ("Hello") time.sleep(1) def func1(tracer): with tracer.start_as_current_span("func1"): i = 0 while i < 3: func1_sub(tracer) i += 1 if __name__ == "__main__": tracer = trace.get_tracer(__name__) func1(tracer) Python アプリを実行します。 opentelemetry-instrument python src/test.py このコンテナからは exit して OK です。 観測データの確認 8.1. Dashboard の表示 Kibana の Analytics / Dashboard からダッシュボードを表示してみます。 [Otel] Hosts Overview ※このダッシュボードは、6.1 で追加されたものです。 EDOT Collector を動作させているホストの稼働状況が可視化されます。 [Otel] Host Details – Metrics EDOT Collector を動作させているホストの CPU や Memory, Network など各種メトリクスが可視化されます。 8.2. Logs の表示 Kibana の Discover から logs-* を表示してみます。 EDOT Collector を動作させているホストの /var/log/*.log の内容が表示されます。 ※ログが表示されない場合、表示対象期間を調整してみてください。 8.3. トレースの表示 Kibana の Observability / Application 画面を表示します。 Service inventory 画面が表示されます。 my-python-script を選択します。 “my-python-script” という名前は、python/Dockerfile に OTEL_SERVICE_NAME として記載していたものです。 my-python-script の Overview が表示されます。 Transactions をクリックします。 src/test.py のトランザクションに関する情報が表示されます。 画面の下の方の Transactions の func1 をクリックします。 func1 の trace 情報が表示されます。 func1 内で func1_sub が3回実行され、実行時間はそれぞれ、3秒、1秒となっていることがわかります。 ※ “func1” や “func1_sub” といった名前は、src/test.py 内に記載したものです。 まとめ OpenTelemetry を採用することで、以下の大きなメリットが得られます。 運用の簡素化: Fleet Server や複雑な Agent 管理から解放されます。 脱ベンダーロックイン: 業界標準のプロトコル（OTLP）を使用するため、将来的なプラットフォームの移行や併用が容易になります。 ポータビリティ: Elastic 固有のコードをアプリに埋め込む必要がなくなり、コードの純粋性を保てます。 現在 Preview 機能ですが、今後の Observability のデファクトスタンダードになることが予想されます。ぜひ今のうちに触れてみてください。 参考URL https://qiita.com/takeo-furukubo/items/2747bdf3e28037b1870b https://qiita.com/takeo-furukubo/items/5f5322977daf6d48fc8c https://www.elastic.co/docs/solutions/observability/get-started/opentelemetry/quickstart/self-managed/hosts_vms https://github.com/SIOS-Technology-Inc/elastic-blogs The post OpenTelemetry を使って Elastic Observability にログ、メトリクス、トレースを取り込んでみよう。 first appeared on Elastic Portal .