observability-sre-triage

SRE サービスのトリアージ

サービスが正常、劣化、または異常のどの状態かを判断し、その理由を示します。トリアージはチェックリストではなく、階層構造です。SLO とアラートによって、サービスが契約を満たせているかを判断し、トレースから導出したゴールデンシグナルによって、どのように問題が発生しているかを把握します。依存関係とインフラストラクチャによって障害の発生元を特定し、ログからインシデントチャンネルに投稿する文面を作成します。根拠が判断を裏付けるまで階層をたどり、裏付けられたらそこで終了します。

SLO 定義、バーンレートルール、アラートしきい値の作成と調整には、observability-service-reliability スキルを使用してください。このスキルはその状態を読み取るだけです。Kubernetes ワークロード、ノード、またはコントロールプレーンの診断（再起動ループ、OOM キルの確認、ノードのプレッシャー、アドミッションによる拒否、ロールアウトの停滞）については、observability-k8s-investigation スキルに引き継いでください。このスキルでは、Kubernetes 上のサービスが飽和しているかを確認しますが、そのサービスを実行しているポッドやノードが失敗している理由は診断しません。

環境設定

このスキルは elastic CLI を通じて Elasticsearch の操作を実行します。 elastic CLI がインストールされていない場合は、何に必要なのかをユーザーに伝えてください。認証情報を推測したり、HTTP API を直接呼び出したり、ほかの回避策を試したりしないでください。

このスキルでは、HTTP 簡略形式の操作を参照します（例：GET /、GET /_cat/indices、GET /{index}/_mapping、GET /{index}/_settings/index.mode、POST /_query）。このドキュメント末尾の操作テーブルでは、各簡略形式に対応する elastic CLI コマンドを示しています。HTTP API を直接呼び出すのではなく、必ず CLI を使用してください。

クラスターにアクセスできない場合の分析

上記の CLI の確認が必要なのは「クラスターへのクエリ」です。分析には必要ありません。ユーザーが質問内ですでに根拠（メトリック値、件数、ステータスの理由、ログ行、アラートペイロード、設定）を提示している場合は、その根拠から判断し、結論を示してください。

ユーザーから提示されていないデータが本当に必要な場合は、何をどのように確認するかを伝えてください。判断に必要な具体的なクエリ、インデックス、フィールドを挙げたうえで、CLI のセットアップを依頼します。確認内容を示す回答はクラスターにアクセスできなくても役に立ちますが、セットアップだけを依頼する回答では不十分です。

ここに記載する内容はすべて、ES|QL（POST /_query）または Kibana Observability API で表現します。Query DSL は使用しないでください。また、ES|QL の KQL 検索関数も使用せず、述語をネイティブに記述してください（WHERE service.name == "checkout"）。

対応するタスク

• 「サービス X は正常ですか？」に、判定とその根拠を添えて答える
• 「サービス X が遅い／エラーが発生している／データがないのはなぜですか？」に、サービス、依存関係、またはインフラストラクチャのどこに変化があるかを特定して答える
• インシデント中に SLO のステータス、バーンレート、残りのエラーバジェットを確認する
• 全サービスを対象とするルールも含め、現在サービスに適用されるアラートルールを特定する
• ノイズの多いログストリームを、劣化の原因を説明する障害ログに絞り込む
• 失敗または低速なサブ集団を区別する属性（バージョン、ホスト、ポッド、リージョン、ルート）を特定する
• 正常なサービスと、テレメトリーがないサービスを区別する

出力に関する規律

このスキルで生成されるすべての応答に適用されます。

• 最も根拠のある結論を明言してください。 根拠が一つの結論を示している場合は、そう述べてください。慎重に聞こえるように確信度を下げてはいけません。明白な根拠に対して曖昧な表現を使うのは、謙虚さではなく欠点です。
• 判定を明言してください：正常、劣化、または異常のいずれかを、その理由とともに述べてください。この3つのいずれも示さないトリアージ回答は、役割を果たしていません。
• 確信度は結論で一度だけ示してください。 箇条書きごとに繰り返してはいけません。
• 根拠を超えて推測してはいけません。 テレメトリで原因が確認できなかった場合、回答に含めてはいけません。不明な点を示し、そこで止めてください。どのシグナルでも測定されていないメカニズム（「おそらくGCの一時停止」「ノイジーネイバーの可能性が高い」など）を決して提示してはいけません。
• 存在しないものは、存在しないと報告してください。 行が0件なら、データが欠落しているか収集されていません。基盤となる状態が正常という意味ではありません。「依存関係のメトリクスがない」は「依存関係に問題がない」ことを意味しません。
• 水増ししないでください。 質問を言い直したり、結果に関係しないクエリの実行内容を説明したり、要約をさらに要約したりしてはいけません。
• 所見で締めくくってください。 「さらに詳しく調べましょうか？」のように、最後に申し出を付け加えてはいけません。実行可能なフォローアップは、質問ではなく推奨事項として、推奨事項のリストに記載してください。

シグナルの優先順位

シグナルは常に食い違います。この順序に従って、どのシグナルを優先するかを判断してください。

順位	シグナル	権威の根拠
1	SLO のステータスとバーンレート	SLO が存在する場合に権威を持ちます。サービスにとっての「正常」の合意済み定義を示します
2	有効なアラートルール	SLO で症状がカバーされていない場合に権威を持ちます。Alerting API から取得します
3	エラー率、レイテンシ、スループット	劣化の状態を示します。これより上位のシグナルがない場合に限り、決定的な根拠となります
4	依存関係の健全性	上流または下流の原因を特定します。単独で判定を決めるものではありません
5	ML 異常	目標値ではなく、学習済みベースラインからの逸脱を示します。裏付けと時間範囲の特定に使います
6	インフラストラクチャ（CPU、メモリ、OOM）	メカニズムを説明します。ゴールデンシグナルが正常な状態でポッドが飽和している場合、障害ではなくリスクです
7	ログ	説明には使いますが、判定には使いません。ログ量は健全性を示しません

競合時のルール：

• SLO は正常、レイテンシは上昇 → エラーバジェット内の劣化です。判定は SLO に従い、バーンレートとともに傾向をリスクとして報告してください。
• SLO 違反中だが、現在のウィンドウのメトリクスは正常に見える → SLO を信頼し、評価ウィンドウを確認してください。SLO は数時間から数日にわたって評価されます。15分間の ES|QL ウィンドウが問題なしに見えても、すでにエラーバジェットを使い切っている場合があります。
• SLO が定義されておらず、アラートが発火中 → アラートが判定となります。帰属を判断する前に、各ルールの params を解決し、実際にこのサービスを対象としていることを確認してください。
• ログが多いが、ゴールデンシグナルは横ばい → 劣化ではありません。エラー率やレイテンシの変化を伴わないログ量の増加は、健全性の問題ではなく、ログ設定に関する所見です。
• スループットが急落し、エラー率は横ばい → 呼び出し元が呼び出しを停止しています。このサービスを責める前に、上流を調べてください。
• いずれかのクエリが0件を返す → データが欠落しています。利用できないシグナルを明示し、それに応じて判定の範囲を限定してください。沈黙を健全性とみなしてはいけません。

ルーティング：症状から最初に確認するシグナルへ

現れている症状	最初に取得する情報	参考資料
「X は正常ですか？」／不明確	SLO のステータス、次にアクティブなルール、次にゴールデンシグナル	slo-and-alerts.md
「X が遅い」	レイテンシのパーセンタイルと前の期間との比較、次に依存先のレイテンシ	apm-signals.md
「X でエラーが発生している」／5xx	ルートごとのエラー率、次に失敗したトランザクションの相関	apm-signals.md
「X がダウンしている」／トラフィックがない	スループット、次にサービスがデータを取り込んでいるか確認	apm-signals.md
「一部のリクエストだけに問題がある」	候補属性を使ったサブポピュレーションの相関	apm-signals.md
「アラートが発火した」／「SLO のバーンが進んでいる」	ルールの params と SLO のバーンレート、次にルールが監視するメトリクス	slo-and-alerts.md
「ログには何がありますか？」／ノイズの多いログ	ログファネル — NOT 除外を使って繰り返し調査	log-investigation.md
OOM、スロットリング、再起動の疑い	コンテナの CPU およびメモリ制限の使用率	apm-signals.md
Kubernetes 以外のホストで「飽和していますか？」	hostmetrics レシーバーから取得するホストの CPU、メモリ、ロードアベレージ	apm-signals.md
「どの下流サービスが X に影響していますか？」	宛先ごとの呼び出し量、レイテンシ、失敗率	apm-signals.md

データソース

OTel ネイティブのデータストリーム。Elasticsearch 9.6.0 で検証済みです。

データ	インデックスパターン
トレース（スパン、トランザクション）	traces-*.otel-*。従来の Elastic APM エージェントによる取り込みデータは traces*apm* にも格納されます。
ログ	logs-*.otel-*
生メトリクス	metrics-*.otel-*。従来の APM エージェントによる取り込みデータは metrics*apm* にも格納されます。
サービスインベントリ（1 分ロールアップ）	metrics-service_summary.1m.otel-*
トランザクションのロールアップ（1 分）	metrics-service_transaction.1m.otel-*、metrics-transaction.1m.otel-*
依存関係のロールアップ（1 分）	metrics-service_destination.1m.otel-*
Kubernetes	metrics-kubeletstatsreceiver.otel-*、metrics-k8sclusterreceiver.otel-*、logs-k8seventsreceiver.otel-*
ホスト（VM、ベアメタル）	metrics-hostmetricsreceiver.otel-*。Elastic Agent のシステムインテグレーションによるデータは metrics-system.* に格納されます。

service.name はトレース、メトリクス、ログに設定されるため、これらすべてを結合するキーです。ES|QL ではフラットな OTel フィールドパス（resource.attributes.k8s.pod.name ではなく k8s.pod.name）を使用してください。OTel アプリケーションメトリクスの分析では、ES|QL の TS（時系列）コマンドを使うと、より効率的にメトリクスをクエリできます。Serverless では GA です。Stack では 9.2 でプレビュー、9.4 で GA のため、9.4 より前のバージョンでは代わりに BUCKET とともに FROM を使用してください。また、TS では COUNT(*) が拒否されるため、フィールドをカウントしてください。

このスキルとそのリファレンスにあるレシピは、上記の OTel ネイティブのデータストリームを対象にしています。従来の Elastic APM エージェントで計装されたサービスは、異なるフィールド名（transaction.duration.us、event.outcome）を使用して traces-apm* と metrics-apm* にデータを送信するため、これらのレシピでは結果が返りません。明らかに稼働しているサービスで結果が空の場合、それは障害の証拠ではなく、対象範囲の境界を示しています。サービスが実際に書き込んでいるインデックスファミリー（GET /_cat/indices）を確認し、結果がないことだけで結論を出さず、データの取り込み経路を報告してください。

ES|QL 機能の利用可否

このスキルで使用する 3 つの機能は、8.11 の最低対応バージョンより新しいものです。これらの機能を利用する前に GET / を確認してください。 build_flavor: "serverless" の場合は 3 つすべてを利用できます。それ以外の場合は、version.number を Stack 列と比較してください。 クエリが実行されなかったことが本当の原因なのに、「データなし」と報告してはいけません。利用できなかった機能を明示し、 代替手段を使用してください。

機能	Serverless	Stack	ライセンス	使用箇所	代替手段
FORK	GA	preview 9.1-9.3, GA 9.4+	any	ログファネル、サブポピュレーションの比較	各ブランチを個別のクエリとして実行し、自分で結果を組み合わせる
CATEGORIZE	GA	preview 9.0, GA 9.1	Platinum	ログファネル内のメッセージ分類	メッセージの切り詰めたプレフィックスでグループ化するか、構造化されたエラーフィールドでファネルを実行する
TS	GA	preview 9.2, GA 9.4	any	OTel アプリケーションメトリクスのクエリ	同じデータストリームに対して BUCKET を使った FROM を実行する

CATEGORIZE の Platinum 要件は、バージョンの確認ではありません。Basic または Gold ライセンスの 9.6 Stack クラスターでは、8.11 クラスターで FORK が失敗するのと同様にこの機能が失敗し、エラーには構文ではなくライセンスが示されます。Serverless では、この関数は個別のライセンス要件なしで GA です。

手順：劣化したサービスをトリアージする

1. サービスと時間範囲を確定します。 リクエストからサービス名と時間範囲を特定します。ユーザーが指定した時間範囲を使い、過去の事象についての問い合わせで、直近 1 時間を黙って仮定してはいけません。時間範囲が指定されていない場合は、直近 1 時間を使い、その旨を伝えます。POST /_query を使い、traces-*.otel-* に対して COUNT(*) BY service.name を実行して、そのサービスがテレメトリに実際に存在することを確認します。名前が見つからない場合は、さらにクエリを実行する前に曖昧さを解消してください。

   判断事項：以降のすべてのクエリで対象とするサービスと時間範囲。データ：範囲内の一意な service.name 値。

2. SLO の状態とバーンレートを確認します。 GET kbn:/api/observability/slos で SLO を一覧表示し、対象サービスに関連付けられた SLO について GET kbn:/api/observability/slos/{id} で詳細を取得します。状態、現在の SLI、バーンレート、残りのエラーバジェットを確認します。

   判断事項：合意された契約が存在し、違反されているかどうか。違反されている場合、判定はすでに確定しており、以降の手順ではその理由を説明するだけです。このサービスを対象とする SLO がない場合は、そのことを一度だけ述べ、手順 3 に進みます。

3. このサービスに適用されるアラートルールと、そのうち発報中のものを特定します。 GET kbn:/api/alerting/rules/_find を per_page=100&filter=alert.attributes.enabled:true で呼び出します。total が受信した件数を超える場合は、page を使ってページングします。その後、レスポンスをクライアント側でフィルタリングします。アクティブ状態の判定に .alerts* インデックスをクエリしてはいけません。アラート API のレスポンスが信頼できる情報源です。params が必要な場合は、GET kbn:/api/alerting/rule/{id} でルールの完全な定義を取得します。

   この呼び出しをサーバー側で絞り込んではいけません。 _find の filter パラメーターは、保存オブジェクトの attributes に対する KQL であり、params はその対象ではありません。そのため、ルールが存在するクラスターでも filter=alert.attributes.params.serviceName:<name> はルールを 0 件返します。search=apm&search_fields=tags、alertTypeId、または consumer による絞り込みは、命名規則やルールタイプの許可リストに基づいてルールを除外するため、さらに悪影響があります。除外されるルールは、すべてのサービスを対象とするものに偏っています。実測された失敗については、references/slo-and-alerts.md を参照してください。 取得したルールの中から、params.serviceName がサービス名と一致するルールと、params.serviceName がないルールの両方を評価します。後者はすべてのサービスに適用されるルールだからです。それぞれの execution_status.status を確認します。active はルールの直近の実行でアラートが発生したことを、ok は実行されてアラートが発生しなかったことを、error はルールがまったく評価されていないことを意味します。これは問題なしではなく、監視の死角です。

   判断：このサービスをカバーするルールは何で、そのうち現在発火しているものはありますか？データ：ルールの params.serviceName、ルールの種類、実行ステータス。

4. ML の異常を確認します（ジョブがある場合）。 GET /_ml/anomaly_detectors でジョブを一覧表示し、GET /_ml/anomaly_detectors/_stats で実行中であることを確認します。停止中のジョブは異常を検出しません。これは異常がないこととは異なります。スコアリング済みレコードは GET /_ml/anomaly_detectors/{id}/results/records で取得します。

   判断：レイテンシ、スループット、エラー率は、学習済みのベースラインから逸脱しましたか？いつ発生しましたか？異常の時間帯を使って、手順 5 と 6 の対象を絞り込みます。

5. ゴールデンシグナルを測定します。 traces-*.otel-* に対して ES|QL を実行し、スループット、レイテンシ（平均、p95、p99）、エラー率を、対象時間帯ごとに集計します。その値を、直前の同じ長さの時間帯と比較します。references/apm-signals.md を参照してください。

   判断：サービスの状態は、サービス自体の通常時と比べて実際に変化していますか？変化したのはどの指標ですか？データ：現在と直前の時間帯におけるリクエスト数、レイテンシのパーセンタイル、失敗率。

6. 原因を絞り込みます。依存関係、サブポピュレーション、インフラストラクチャの順に確認します。

   • 依存関係 — metrics-service_destination.1m.otel-* を span.destination.service.resource で集計し、呼び出し量、平均レイテンシ、失敗率を確認します。このクエリでサービスの結果が 0 行の場合、そのサービスは依存関係について APM 計測されていません。依存関係のデータ不足を報告し、上流のサービスが正常だとは判断しないでください。
   • サブポピュレーション — トラフィックの一部だけに問題がある場合は、候補となる属性ごとに失敗率または遅延率を全体の率と比較し、どの属性の割合が過剰なのかを特定します。references/apm-signals.md を参照してください。
   • インフラストラクチャ — まずサービスのスパンに付与されたリソース属性（k8s.pod.name、container.id、host.name）を確認し、その値に応じて調査を分岐します。Pod と名前空間の属性がある場合、サービスは Kubernetes 上でホストされています。metrics-kubeletstatsreceiver.otel-* の k8s.container.cpu_limit_utilization と k8s.container.memory_limit_utilization を確認してください。host.name があり Pod 属性がない場合、サービスは VM またはベアメタルホスト上で実行されており、すべての k8s.* フィールドは空です。その場合は代わりに、metrics-hostmetricsreceiver.otel-* の system.cpu.utilization、system.memory.utilization、system.cpu.load_average.1m を確認してください。OOM キル、CPU スロットリング、ホストの飽和は、APM の健全性を直接損ないます。references/apm-signals.md を参照してください。
   • 直近の変更 — 急激な変化の最も一般的な原因はデプロイです。インシデントの時間帯を対象に GET kbn:/api/apm/services/{serviceName}/annotation/search でサービスのデプロイアノテーションを検索し、サブポピュレーションのクエリで service.version ごとの失敗率またはレイテンシを比較します。発生開始の時間帯にあるアノテーションは強い相関を示しますが、原因とみなす前に、症状を妥当に説明できることを確認してください。

   判断：原因はこのサービス内、このサービスが呼び出す先、そのインスタンスの一部、その下のインフラストラクチャ、または直近の変更にありますか？

   Kubernetes の調査で飽和、再起動、または OOM キルが確認された場合、発生の仕組みは特定できています。Pod がキルされる理由、ノードに負荷がかかっているか、ロールアウトが停止しているかといった残りの診断は、observability-k8s-investigation スキルの担当です。ここで調査を続けず、引き継いでください。

7. ログで説明します。 service.name でログを絞り込み、特定の失敗トレースが手元にある場合は trace.id で絞り込み、残った件数が十分に少なくなって読み取れるまでファネルを実行します。references/log-investigation.md を参照してください。ログは原因を裏付けて明確にしますが、手順 2 と 3 の結論を覆すものではありません。

8. 判定を示します。 健全、劣化、または異常のいずれかを、理由と確信度についての一文とともに示し、その後に推奨事項を述べます。利用できなかったシグナルがあれば明記してください。

例

「チェックアウトは健全ですか？」 — 対象時間帯を決定し、その SLO、次に全サービス対象のルールを含む有効なルールを確認してから、traces-*.otel-* を対象に、直前の時間帯と比較してスループット、レイテンシのパーセンタイル、エラー率を調べます。可用性 SLO が目標の 99.5% に対して 99.2% で、バーンレートが 1 を上回っている場合、SLO 違反により判定は異常です。ゴールデンシグナルは説明の根拠であり、判定そのものではありません。

「フロントエンドが遅いのはなぜですか？」 — 現在の時間帯の p95 と p99 を、同じ長さの直前の時間帯と比較します。サービスレベルのレイテンシが上昇している一方で、metrics-service_destination.1m.otel-* の宛先ごとのレイテンシが横ばいなら、サービス内部で時間が増えています。ある宛先の平均応答時間もそれに合わせて上昇しているなら、原因は依存先にあり、フロントエンドは影響を受けている側です。

「チェックアウトのリクエストの一部だけが失敗します」 — サブポピュレーションの比較を実行します。service.version、k8s.pod.name、host.name、cloud.region ごとの失敗率を、全体の失敗率とあわせて確認します。全体の失敗率の数倍に達し、かつ問題と見なすに足るボリュームがある属性値が、相関する属性です。ライブデータでは、フロントエンドのサーバースパンをルート別にグループ化したところ、POST の低速率は 3.8%、全体では 0.9% でした。4 倍の増加により、問題が書き込みパスにあると特定できます。

「カートサービスのログがひどい状態です」 — service.name == "cart" で絞り込んだ logs-*.otel-* に対してファネルを実行します。1 つの FORK で傾向、合計、サンプル、メッセージ分類を取得し、主要なパターンごとに NOT ... LIKE の除外条件を追加して、蓄積したフィルター全体を使ってパターンが 20 件未満になるまで再実行します。ログ量が多いだけでは健全性の判定にはなりません。サービスが劣化していると判定する前に、ゴールデンシグナルを確認してください。

「決済サービスの上流は健全ですか？」 — metrics-service_destination.1m.otel-* をクエリします。行数が 0 件なら、そのサービスは依存関係メトリクスを出力していません。このサービスでは依存先データを利用できないことを報告し、存在するシグナルに基づいて判定してください。上流が健全だと報告してはいけません。

「api-gateway でアラートが発火しました」 — サーバー側で絞り込まずに有効なルールを取得し、メモリ上で params.serviceName == "api-gateway" に一致するルールと、params.serviceName を持たないルールを照合してから、execution_status.status を読み、どのルールが発火中かを確認します。GET kbn:/api/alerting/rule/{id} で発火中のルールのしきい値を読み取り、同じ時間帯の同じメトリクスを ES|QL でクエリして、そのルールが実際の変化を示しているのか、しきい値の設定が厳しすぎるだけなのかを確認します。

ガイドライン

• シグナルの優先順位に沿って確認し、証拠から判定を下せる時点で止めます。すべてのリクエストで、このドキュメント内のすべてのクエリを実行する必要はありません。
• SLO がある場合は、SLO のステータスとバーンレートを基準にします。ない場合は、アラート、ML の異常、スループット、レイテンシ、エラー率、依存関係、インフラストラクチャ、ログの順に確認し、そのサービスを対象とする SLO がないことを明記します。
• アクティブなアラートの状態には Alerting API を使います。その状態を確認するために .alerts* インデックスをクエリしてはいけません。サービスにスコープされたルールと、params.serviceName のないルールの両方を必ず評価します。
• アラートルールは絞り込まずに取得し、クライアント側でフィルターします。_find では params を使ったフィルターができず、タグ検索では命名規則に従わないルールが除外されます。また、executionStatus.status:active が返すのは現在発火中のルールのみです。これらはいずれも、上記の箇条書きで求められている全サービス対象のルールを、気づかないうちに隠してしまいます。
• ユーザーが指定した時間範囲を必ず使います。すべてのメトリックを、直前の同じ長さの時間枠と比較します。ベースラインのない絶対値だけでは、判定の根拠になりません。
• 行が 0 件の場合は、データが欠落しています。無反応を問題なしと見なすのではなく、どのシグナルを利用できないのかを明記します。
• すべてのクエリで service.name と範囲を限定した @timestamp を指定し、LIMIT で出力を制限します。傾向の把握だけが目的の場合は、粗いバケットを優先します。
• 失敗したスパンには event.outcome == "failure" を優先して使います。OTel のトレースでは status.code == "Error" も同等ですが、成功時は null になるため、そのまま直接カウントできません。
• サービス自体のスループットとレイテンシを測定する際は、クライアントのスパンが二重計上されないよう、サーバー側のトラフィックを kind == "Server" でフィルターします。
• log.level と severity_text は参考情報として扱い、フィルターの根拠には決して使いません。実際の OTel データでは、ほとんどのログレコードにレベルがなく、レベルがある場合も大文字小文字や表記が一致しません（INFO、Information、SEVERE、Normal）。特に、log.level == "error" は決して指定しないでください。小文字の ECS 表記は OTel SDK が出力する値ではないため、サービスがエラーをログに記録していてもエラーなしで 0 件を返し、サービスが正常であると誤って報告します。重大度の条件が必要な場合は、正規化された数値の severity_number >= 17 を使います。
• ログは原因の説明には使えますが、判定の根拠にはなりません。ログの内容だけを根拠に判定してはいけません。
• フィールド名を推測してはいけません。このデプロイメントにフィールドが存在しない可能性がある場合は、そのフィールドに基づくクエリを作成する前に、GET /_resolve/index/{pattern} でデータストリームの存在を確認します。
• 飽和状態を調べる前に、サービスの実行環境を特定します。Kubernetes とホストのテレメトリではフィールド名が共通していないため、VM で動作するサービスに対して Kubernetes のクエリを実行して 0 件になっても、飽和しているかどうかは分かりません。
• 結果の大部分が空の列である場合は、POST /_query に --drop-null-columns を指定します。インフラストラクチャのメトリックは本質的に疎であり、上限が宣言されていない箇所では使用率が存在しません。このフラグを使うとノイズがまとめて除去され、抑制された列名は all_columns の下に一覧表示されるため、情報が隠れることはありません。

操作

HTTP API（略式表記）	elastic CLI コマンド
GET /	elastic es info
POST /_query	elastic es esql query --format tsv --query '<esql>'
GET /_resolve/index/{pattern}	elastic es indices resolve-index --name '<pattern>'
GET /_ml/anomaly_detectors	elastic es ml get-jobs
GET /_ml/anomaly_detectors/_stats	elastic es ml get-job-stats
GET /_ml/anomaly_detectors/{id}/results/records	elastic es ml get-records --job-id '<id>'
GET kbn:/api/observability/slos	elastic kb slo find-slos-op --space-id '<space>' --kql-query '<kql>'
GET kbn:/api/observability/slos/{id}	elastic kb slo get-slo-op --space-id '<space>' --slo-id '<id>'
GET kbn:/api/alerting/rules/_find	elastic kb alerting get-alerting-rules-find --filter '<filter>'
GET kbn:/api/alerting/rule/{id}	elastic kb alerting get-alerting-rule-id --id '<id>'
GET kbn:/api/apm/services/{serviceName}/annotation/search	elastic kb apm-annotations get-annotation --service-name '<service>' --environment '<env>' --start '<iso8601>' --end '<iso8601>'

SLO 検索コマンドが KQL クエリ文字列を受け取るのは、API の仕様に基づいています。データクエリに対する ES|QL のルールの例外ではありません。

アノテーション検索ルートでは、environment を省略したリクエストは拒否されます。そのため、サービスの環境が不明な場合は ENVIRONMENT_ALL を渡してください。対象範囲は検索方向のみです。このスキルは読み取り専用のため、対となるアノテーション作成操作は意図的に割り当てていません。