Elasticsearch：ログ分野で最高峰、現在はメトリクス分野でも最高峰に

Store high-cardinality metrics efficiently with time series data streams, and keep your Prometheus and PromQL workflows along for the ride. 

Dig into infrastructure and metrics monitoring. Start a free cloud trial or try Elastic on your local machine now.

ここ数か月にわたり、Elasticは時系列データ専用に構築されたElasticsearchのカラム型ストレージエンジン、ネイティブなPrometheusのインジェストおよびストレージ、PromQLサポートをリリースしたほか、新しいメトリクス探索エクスペリエンス、事前構築済みのインフラダッシュボード、自律型エージェントによる調査機能、DatadogおよびGrafanaからの移行パスなどを提供してきました。現在利用可能な機能は以下のとおりです。

• ElasticsearchはPrometheus互換のメトリックバックエンド — Prometheus Remote Write またPromQLがKibanaでネイティブに動作し、変換レイヤーは不要です。

• メトリクスはElasticsearchのカラム型TSDSアーキテクチャに取り込まれ、データを最大でPrometheusより2.5倍、ClickHouseよりも2倍効率的に格納します。

• ES|QL時系列クエリは、高カーディナリティワークロードを含む、ゲージ平均およびカウンターレートにおいてPrometheusより最大30倍高速に実行されます。

• ElasticのコストはDatadogよりも約50％低く、カスタムメトリックの分類やカーディナリティベースの課金もありません。

• Grafanaは、ネイティブのPrometheus API経由でElasticsearchに直接クエリを実行でき、バックエンドを置き換えながら可視化レイヤーを維持できます。

• KubernetesおよびAWSモニタリングには、事前構築済みのダッシュボード、アラートテンプレート、ML異常検知ジョブ、エージェント型調査コンテンツが用意されており、データ取り込み後すぐに利用できます。さらに、スキルやMCPアプリもご利用いただけます。

• メトリクス、ログ、トレース用の統合バックエンドにより、ツール間でコンテキストを統合することなく、エージェント調査(https://www.elastic.co/observability-labs/blog/ai-powered-kubernetes-observability-elastic-mcp)が可能になります。

• Discoverでのメトリクス探索により、クエリ言語の専門知識がなくても、誰でもすぐにメトリックのクエリと分析を開始できます。

• カスタムダッシュボードは高速かつ柔軟です。コードとしてのダッシュボード、AI支援によるダッシュボード作成、可変コントロール、折りたたみ可能なパネルにより、構築時間を短縮し、調査に費やす時間を増やすことができます。

• DatadogやGrafanaからダッシュボードやアラートルール/モニターを簡単に移行できるように支援する移行ツール。

Elasticsearchのメトリクスは現在、SREにとって重要なあらゆる面で高い競争力を備えています。すべてのメトリクスをフル解像度で保持でき、Prometheusより最大30倍高速にクエリを実行でき、Datadogより50％低いコストで利用でき、GrafanaまたはDatadogからダッシュボードやアラートルールを簡単に移行できるほか、分断されたツール間でコンテキストをつなぎ合わせることなく、アラートから根本原因の特定へと進めます。このブログ記事の残りの部分では、これらをそれぞれ詳しく説明します。

Elasticsearchのメトリクスパフォーマンス：PrometheusやMimirよりも30倍高速

DatadogとPrometheusは、高カーディナリティのデータを削除するか、コストの急増を受け入れるかのトレードオフを迫ります。Kubernetes、AWS、または高カーディナリティのインフラを管理するSREは、この問題がどのようなものかをよく知っています。インシデント発生時に最も重要となるKubernetesラベル、一時的なポッドデータ、きめ細かなOTelディメンションは、予算が厳しくなると真っ先に失われます。

Elasticは、時系列データストアとES|QLコンピューティングエンジンを完全にカラム型のメトリクスエンジンへと再構築しました。新しいKubernetesラベル、新しいAWSインスタンスタグ、または新しいアプリケーションディメンションを追加しても、システムに負荷はかかりません。すべてのラベルをインデックス化するシステムに比べて、はるかにコストが少なくて済みます。OTel、Prometheus、アプリケーション定義のメトリクスはすべて、完全な解像度で同じカラム型バックエンドに集約され、ログ、トレース、メトリクスが単一のストアにまとめられます。データがドロップされることも、保持期間が短縮されることもありません。

Elasticsearchは、Prometheusよりも最大2.5倍効率的に（圧縮などの要因により結果は異なる場合があります）、ClickHouseよりも2倍効率的にメトリクスを保存します。ES|QLによるクエリパフォーマンスは、Prometheusよりも最大30倍高速に実行されます（競合他社が失速する高カーディナリティのワークロードを含む、ゲージ平均やカウンターレートにおいて）。アーキテクチャに関する記事 では、TSDSがどのように構成されているか、そしてなぜカラム型レイアウトがこれらの結果を生み出すのかについて説明しています。

重要なアーキテクチャ上の違いは、Elasticsearchのメトリクスは、カーディナリティに応じてスケーリングするシリーズごとのインメモリ状態を保持しないため、数千もの新しいKubernetesポッドラベルやOTelディメンションを追加しても、メモリ負荷が増大しない点です。

OTel、Prometheusネイティブ、アプリケーション定義のメトリクスはすべて、フル解像度で同じように格納され、高速にクエリでき、Datadogの半分のコストで利用できます。

Datadogのカスタムメトリクスに伴うペナルティなしのElastic Observabilityメトリクス価格設定

オブザーバビリティのコストは、チームがプラットフォームを切り替える最大の理由です。Datadogの顧客にとって、問題の根源はカスタムメトリクスという価格設定の仕組みにあります。Datadogの搭載のインテグレーション以外でユーザーが定義した値はすべてカスタムメトリクスに分類され、割高な料金で請求されます。これには、Kubernetes、OpenTelemetry、クラウドネイティブのワークロードがデフォルトで生成する高カーディナリティデータも含まれます。インストルメンテーションが細かくなるほど、請求額はより速く膨らみます。最新のインフラストラクチャを運用するチームは、すぐにこの限界に達し、それに対応する対応は予測可能です。つまり、データの破棄、データ保持期間の短縮、そしてインシデント発生時に最も重要なコンテキストの喪失です。

Elasticsearchのメトリクスでは、そうした分類は不要です。すべてのメトリクスが同一料金であり、メトリクスごとのペナルティやカーディナリティに基づく課金、強制的なロールアップもありません。すべてのメトリクスをフル解像度で保持でき、月末に予期しない請求が発生することもありません。また、ElasticはDatadogの50％のコストで利用できるため、財務担当者との議論の内容も変わり、予算内に収めるためにどのデータを破棄しなければならなかったかではなく、すべてを保持したことで何を発見できたかという内容になります。AIによる調査が機能するのも、そのためです。Grafanaの断片化されたLGTMスタックとは異なり、アラートが発生した時点でコンテキストはすでに統合されており、分断されたツール間で手作業で集約する必要はありません。

ElasticsearchにおけるネイティブPrometheusおよびPromQLのサポート

ほとんどのSREチームは、クリーンで単一形式のテレメトリパイプラインを運用していません。Prometheusは、アプリケーション、サービス、プラットフォーム、自動化に深く組み込まれています。従来、メトリクスバックエンドの移行には、クエリの書き換え、ダッシュボードの再構築、エンジニアの再トレーニングが必要だったため、チームは移行作業を行うよりも、既に時代遅れになったプラットフォームを使い続けることが多いのが実情でした。

Elasticsearchメトリクスは、そうした摩擦のほとんどを取り除きました。PrometheusメトリクスはPrometheus Remote Write経由で送信され、セマンティックな変更なしに同じカラム型ストアに格納され、エンドツーエンドでメトリクスの忠実性を完全に維持します。Mimirの代わりにElasticsearchに向けるだけで、データが流れます。変換レイヤーは不要で、既存のスクレイピング設定も変更しません。

KibanaでPromQLがネイティブに動作するようになったため、日常的にPromQLを使用しているエンジニアは作業方法を変える必要がありません。既存のPromQLクエリ、ダッシュボード、アラートルールをKibanaに直接移行できます。 

PromQLクエリはElasticsearchでそのまま動作

チームですでにPromQLを記述している場合、何も変更する必要はありません。これらのクエリは、バックエンドとしてのElasticsearchに対してそのまま実行され、コピー＆ペーストするだけで完了します。

CPU使用率（コンテナレベル） ポッドごとにグループ化された、コンテナ全体の1秒あたりのCPU使用率。インシデント発生時に、CPUを大量に消費しているポッドを特定するのに役立ちます。

PROMQL sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

メモリワーキングセット（コンテナレベル） コンテナごとに現在アクティブに使用されているメモリ。 割り当てられた合計メモリではなく、OOMリスクにおいて重要な数値です。

PROMQL sum by (container) (avg_over_time(container_memory_working_set_bytes[5m]))

HTTPリクエストレート（アプリケーションレベル） インスタンスごとにグループ化された、1秒あたりのリクエストスループット。レイテンシーまたはエラーのスパイクを調査する際の標準的な最初のシグナル。

PROMQL sum by (instance) (rate(http_requests_total[5m]))

3つすべてが標準のPromQL構文に従います。Elasticsearchをバックエンドとして使用する場合、変更なしで実行されます。完全な構文リファレンスおよびサポート対象の詳細については、PromQLサポートドキュメントをご覧ください。

ネイティブのPrometheus APIにより、Elasticsearchは完全にPrometheus互換のバックエンドになります。Prometheus互換のフロントエンド（Grafanaを含む）は、Elasticsearchに直接クエリを実行できます。そのため、Elasticsearchに統合しながら可視化レイヤーとしてGrafanaを維持したいチームは、既存のダッシュボードやアラートルールを変更することなく、そのように運用できます。

SREがPromQLで可能な範囲を超えて詳細な分析を行う必要がある場合、ES|QL は単一のインターフェースで、メトリクス、ログ、トレース全体に対応します。TSコマンドは、時系列固有の処理、すなわちカウンターレート、ゲージ平均、ウィンドウ関数、高カーディナリティディメンション全体にわたるマルチレベルアグリゲーションを処理します。CPUカウンターレートを取得する同じクエリは、同じホストのログと結合し、スパイクに先行した導入イベントを明らかにできます。ツールの切り替えも、新しいクエリ言語も不要です。クエリ言語、ダッシュボード、アラートルール、可視化レイヤーなど、すべてそのまま引き継がれます。唯一の変更点は、Elasticsearchがすべてを支える単一のバックエンドになることです。

Elastic Observability：すぐに使えるダッシュボード、アラート、インフラコンテンツ

ほとんどのオブザーバビリティベンダーは、すべてをゼロから構築することを要求します。Elastic Observabilityは、3つの領域でこの必要性を低減しています。

Discoverでのメトリクス探索。Elasticsearchの新しいメトリック探索機能により、SREはログに使用するのと同じインターフェースでメトリックを探索できます。タブを切り替える必要も、クエリを重複して作成する必要もありません。OTelパイプラインまたはPrometheusスクレイピング設定を接続し、Streamsを開くと、データストリーム内のすべてのメトリックが即座に時系列チャートとして表示されます。ダッシュボードを作成する必要も、クエリを記述する必要もありません。ここでは、チームがデータの検証やパターンの特定を行ったり、流れているデータのライブビューからアラートやSLOの作成を開始したり、Elasticsearch内のログ、トレース、その他のインデックスされたデータと相互に関連付けたりすることができます。

**ダッシュボード。**Kibanaのダッシュボードに遅延読み込み対応の折りたたみ可能なパネルが追加され、すぐには表示されないパネルは必要になるまでクエリを生成しなくなりました。また、SREが新しいクエリを作成することなくドロップダウンを介して可視化を操作できるようにするES|QLコントロール変数も導入されました。コードとしてのダッシュボードも提供開始され、環境間でプログラムによってテンプレート化、共有、デプロイできる、バージョン管理されたダッシュボード定義が可能になります。

**設定不要のインフラコンテンツ。**Elasticでは、設定不要の新しいインフラ機能を2つ提供しています。

• 新しいKubernetes統合 には、階層型ダッシュボード、アラートルールテンプレート、ML異常検知ジョブ、AIを活用した根本原因分析に必要なコンテキストとプロンプトが標準で搭載されています。これらはすべて事前設定済みで、データの送信が開始された瞬間からすぐに使用できます。 

• AWSインフラストラクチャーの監視も同様のパターンに従います。主要なAWSサービス向けのOOTB（標準搭載）コンテンツがデータ投入時に有効化されるため、新しいサービスやアカウントがオンラインになるたびにチームがゼロから構築し直す必要はありません。同様のアプローチはデータベースやその他のコアインフラストラクチャーにも適用され、プラットフォームは白紙の状態ではなく、あらかじめ最適化された構成が組み込まれた状態で提供されます。

Elastic Observabilityによるインフラ全体のエージェント調査

Elasticsearchは、単一のバックエンドでメトリクス、ログ、トレースを相関付けるため、エンジニアにページ通知が送信される前に調査コンテキストが構築されます。

一番大変なのは午前2時です。RDSインスタンスが接続制限に達し、上流のサービスへの接続が阻害され、アプリケーションログに埋もれた原因によって、Auto Scalingグループがヘルスチェックに失敗します。名前空間全体に連鎖的にポッドの再起動が発生します。

Grafana LGTMスタックでは、仮説を立てるのに十分なコンテキストを得る前に、3つのタブを開くことになります。

Datadogでは、コンテキストは統合されていますが、AIはブラックボックスで、BYO-LLMはなく、データレジデンシーの選択肢もありません。

Elasticでは、メトリクス、ログ、トレースが単一のバックエンドと共通スキーマを共有しているため、アラートが発生した時点で調査のコンテキストがすでに揃っています。ツール間で手動で相関付ける必要も、クエリ言語間の変換でコンテキストが失われることもありません。ML異常検知はインフラメトリクス（Kubernetes、AWS、データベース）に対して自動的に実行されるため、調査は単なる生のしきい値超過ではなく、通常の状態、変化した内容、逸脱の重大度に関するコンテキストを含むスコア付けされた異常から開始されます。

アラートが発生すると、Elasticの調査ワークフローがシグナルを関連付け、根本原因のコンテキストを構築し、関係者に通知する前に推奨される次のステップを提示します。エージェント型のKubernetesオブザーバビリティに関するブログ記事 では、エンドツーエンドの完全な例を紹介しています。EKSトラブルシューティングのウォークスルーでは、EC2、EKS、および関連するAWSサービス全体で根本原因究明の完全なループを実現するために、Agent BuilderとMCPがどのように連携するかを示しています。

Elastic Observabilityで問題を調査するだけでなく、Claude、Cursor、VS Code、またはお好みのツールを使用して、ElasticのMCPアプリとエージェントスキルを活用し、問題を分析できます。Observability MCPアプリは、チームがすでに作業しているあらゆる場所に分析機能を拡張します。チームがClaude、Cursor、またはVS Codeで調査を行う場合、同じ調査機能（インフラの健全性ロールアップ、サービス依存関係グラフ、異常の詳細、影響範囲分析）が、会話内で直接インタラクティブビューとして表示されます。GrafanaもDatadogも、これを提供していません。

• Observability MCPアプリ — Claude、Cursor、VS Code、その他あらゆるMCP互換ツールをElasticsearchデータに直接接続し、お好みのツールを離れることなく、インフラの健全性、サービス依存関係、異常のコンテキストを会話内のインタラクティブなビューとして表示します。Kubernetesでの動作をご覧ください。

• Agent Skills — Kubernetes、AWS、およびその他のコアインフラ向けの事前構築済みスキルにより、Elastic内でも独自のエージェントでも、カスタムプロンプトエンジニアリングを行わずに、あらゆるエージェントがオブザーバビリティデータに対して構造化された調査を実行できます。Claude、Cursor、または独自のエージェントパイプラインにドロップするだけで、すぐに使用できます。オブザーバビリティスキルの詳細を確認する か、GitHubでスキルライブラリをご覧ください。

DatadogやGrafanaからElastic Observabilityへの移行

SREチームがオブザーバビリティプラットフォームを切り替えない最も一般的な理由は、移行作業です。長年にわたるアラートルールや、数百ものダッシュボード、ランブックに埋め込まれたPromQLクエリを移行することは非常に困難な運用タスクであり、移行作業中に並行するスタックを保守するコストは日々増大していきます。

Observability Migration Platformは、自動的に変換を処理します。CLIまたはClaude/Cursor（Elasticのエージェントスキルを搭載）をDatadog組織やGrafanaインスタンスに向けるだけで、サポートされているダッシュボード、アラートルール、PromQLクエリがKibanaネイティブの出力に変換されます。このツールを使用すると、完全に移行されたもの、微調整が必要だったもの、すべてを移行するために必要な作業を確認できます。すでに構築したものをそのまま移行できます。

取り込み側では、Prometheus Remote Writeを利用することでパイプラインを変更する必要がなくなります。スクレイピングの設定では、他のPrometheus互換バックエンドではなくElasticsearchを指しており、データは同じカラム型ストアに格納されます。ワークフロー、クエリ、アラート設定は変更することなくそのまま引き継がれます。移行中または移行後も可視化レイヤーとしてGrafanaを引き続き使用したいチームにとって、KibanaのネイティブPrometheus APIおよびPromQLサポートにより、一括切り替えではなく段階的な移行が可能になります。

GrafanaのバックエンドとしてのElasticsearch

Grafanaから移行する準備が整っていないチームにとって、バックエンドの置き換えはそれ自体が1つの移行パスであり、ワークフローに応じて2つの方法があります。

チームで現在Prometheusを運用している場合、最も手軽な方法はGrafanaのPrometheusデータソースを利用することです。ElasticsearchがネイティブのPrometheus互換APIを公開するようになったため、Grafanaの既存のPrometheusプラグインの接続先を直接Elasticsearchに向けることができます。サイドカーやアダプターは不要で、パイプラインの変更も必要ありません。既存のPromQLダッシュボード、アラートルール、変数のドロップダウンは、GrafanaのMetrics Drilldownエクスプローラーを含め、変更なしでそのまま機能します。Prometheus設定でElasticsearchをremote_writeターゲットとして追加し、データソースのURLを切り替えます。ほとんどのチームにとって、これで移行は完了です。エンドツーエンドのセットアップガイドをご覧ください。

単一のGrafanaクエリエディターからログ、メトリクス、トレースをまとめてクエリし、さらに一歩進んだ活用を目指すチーム向けに、Grafana ElasticsearchオフィシャルプラグインでES|QLサポートが提供されるようになりました。これにより、Grafana内で直接シグナル間の相関分析を行うことが可能になり、Elasticsearchが統一された列指向バックエンドで3つのデータタイプすべてを処理します。設定方法をご覧ください。

どちらの方法でも、Grafanaを使い続けながらMimirとLokiを置き換えることで、基盤となるElasticsearchの列指向ストレージとクエリパフォーマンスのメリットをフルに活用できます。長年の運用の取り組みも、そのまま保持されます。チームが先送りにしてきた移行作業も、バックエンドの置き換えだけで完了します。

一般提供機能とテクニカルプレビュー機能

全体にリンクされている各投稿では、一般提供とプレビューの詳細、既知の制限事項について説明しています。

これらすべて（カラム型メトリクスエンジン、ネイティブPromQL、エージェント型調査、移行ツール）は、Elasticの3つの導入モード（サーバーレス、Elastic Cloud、セルフマネージド）で実行されます。Datadogにはオンプレミスの選択肢がなく、Grafana Cloudは最も価値の高い機能をマネージド導入に限定しています。Elasticなら、データの保存場所を自由に選択できます。

Elastic Observability：データを失わずにコストを削減

最新のクラウドインフラにより、シグナルごとに個別のツールを使用する従来のオブザーバビリティモデルは通用しなくなりました。その影響は、ツールの重複請求、インシデント発生時の手動での関連付け、予算内に抑えるためだけに破棄されるデータなど現実のコストとなって現れます。

あらゆるシグナルを効率的に格納する単一のバックエンドにより、通常発生するような多額の請求を伴うことなく、必要なデータを維持できます。これにより、財務部門との会話も変わります。「予算内に収めるためにデータを破棄しなければならなかった」ではなく、「このような分析結果が得られました」と話せるようになるのです。全体像が1つしかないため、AIは全体像を完全に把握できます。また、プラットフォームには初日からすぐに活用できる構築済みコンテンツが十分に備わっており、ダッシュボードの作成に何週間も苦労する必要はありません。

これが可能なのは、Elasticsearchが、置き換え対象となりそうなプラットフォームとは異なる方法で構築されているためです。

• カラム型メトリクスストレージは、TSDSインデックスモードでメトリクスデータを非常に効率的に格納します。 

• ネイティブなPrometheus互換性により、既存のスクレイピング設定、PromQLクエリ、ダッシュボードは書き換えることなく動作します。

• 統合されたメトリクス、ログ、トレースを単一のバックエンドに集約することで、調査コンテキストはタブをまたいで手動で確認するのではなく、クエリ実行時に組み立てられます。

• 同一エンジンでの検索と分析 — ログ用の転置インデックス、メトリクス用のカラム型インデックスをES|QLでまとめてクエリできます。

• エージェント調査：誰かが呼び出される前にシグナルを相関させ、異常を浮き彫りにし、修復を提案します。

• サーバーレス、Elastic Cloud、またはセルフマネージド — データの保存場所を自由に選択できます。これはDatadogでは提供していません。

財務部門とのコストに関する話し合いは、いくら費やしたかではなく、何を発見したかについてのものになります。

利用を開始

• 無料トライアルを開始

• Elastic Observabilityドキュメント

• Elastic Observability Labs

よくあるご質問

**Elasticsearchは本番環境で使用可能なメトリクスプラットフォームになったと言えるでしょうか？

はい。2026年6月現在、Elasticsearchには、時系列データ専用に再構築されたカラム型ストレージエンジン、ネイティブのPrometheus Remote Write取り込み、KibanaでのPromQLサポート、ES|QLによる時系列クエリ、KubernetesおよびAWS向けのすぐに使えるインフラダッシュボードが搭載されています。カラム型メトリクスエンジン、ES|QL時系列サポート、PromQL、Prometheusのデータ取り込みはすべてElastic Serverlessで一般提供開始されており、Elastic Cloud Hostedでもまもなく一般提供となる予定です。

ElasticsearchのメトリクスコストはDatadogと比べてどうですか？

同等のメトリクスワークロードでは、Elastic Observability ServerlessのコストはDatadogより大幅に低くなります。公表されている定価に基づく例では、50％以上低く、多くの場合は3分の2近く低くなります。この差は構造的なものです。Datadogは主にホスト単位で課金し、計測が増えるにつれてカスタムメトリクスとコンテナの料金が加算されます。コスト差が最も大きくなるのは、Datadogが最も多く課金するワークロード、つまりKubernetesやOTelのようにカーディナリティが高く、計測が密に行われる環境です。

ElasticsearchのメトリクスパフォーマンスはPrometheusやGrafana Mimirと比べてどうですか？

ElasticsearchでのES|QLクエリは、高カーディナリティワークロードを含め、ゲージ平均やカウンターレートにおいてPrometheusおよびMimirよりも最大30倍高速に実行されます。ElasticsearchはOTelメトリクスをデータポイントあたり3.75バイトで格納します。Prometheusよりも最大2.5倍、ClickHouseよりも2倍効率的です。

チームはDatadogやGrafanaからElasticsearchへ、すべてを一から作り直すことなく移行できますか？

はい。ElasticのObservability Migration Platformは、DatadogやGrafanaのダッシュボード、アラートルールを変換し、PromQLクエリをそのままKibanaに移行します。チームは、ネイティブPrometheus APIとKibanaのPromQLサポートを使用して、バックエンドをElasticsearchに置き換えながら、Grafanaを可視化レイヤーとして維持することもできます。

メトリックのオブザーバビリティにおいて、ElasticsearchとGrafanaにはどのような違いがありますか？

Elasticsearchはメトリクス、ログ、トレースを1つのクエリ言語（ES|QL）と共に単一の統合バックエンドに格納しますが、GrafanaのLGTMスタックはメトリクス（Mimir/Prometheus）とログ（Loki）を別々のバックエンドに分割するため、個別のクエリ言語が必要になります。Elasticsearchは、AI Agent、Workflows、MCP App、エージェントスキルを含むエージェント調査機能も提供しており、Grafanaよりも包括的な機能セットを備えています。 

ElasticsearchはPrometheusとPromQLをネイティブでサポートしていますか？

はい、2つの方法でサポートしています。まず、ElasticsearchはPrometheus Remote Write経由でPrometheusメトリクスを受け入れ、ネイティブのPrometheus互換APIを公開しているため、Grafanaを含む任意のPrometheus互換フロントエンドのバックエンドとして機能します。次に、KibanaはネイティブでPromQLをサポートしているため、既存のクエリ、ダッシュボード、アラートルールは変換レイヤーや変更なしにKibanaで直接実行できます。

Elastic Observabilityには、標準でどのようなインフラ監視コンテンツが提供されていますか？

Elasticは、ホスト、コンテナ、クラウドサービス、データベース、ネットワークデバイスなどを網羅する数百種類ものインフラ統合において、事前構築済みのダッシュボード、アラートテンプレート、ML異常検知ジョブを提供しています。特にKubernetesとAWS向けには、エージェントスキルなどのエージェント調査コンテンツや、チームがClaude、Cursor、VS Codeから直接調査を実行できるようにするObservability MCPアプリもこのプラットフォームに含まれています。これらはすべて、設定不要で取り込み時に利用可能です。