signoz-generating-queries

クエリ生成

前提条件

このスキルでは、SigNoz MCP サーバーのツール（signoz_execute_builder_query、 signoz_query_metrics、signoz_search_logs、signoz_search_traces、 signoz_aggregate_logs、signoz_aggregate_traces、signoz_get_field_keys、 signoz_get_field_values、signoz_list_metrics、signoz_list_services、 signoz_get_service_top_operations、signoz_get_trace_details）を多用します。 ワークフローを実行する前に、signoz_* ツールが利用可能であることを確認してください。 利用できない場合は、まず signoz-mcp-setup を実行して MCP 接続を初期化または修復してください。 MCP ツールを使わずに、生の HTTP 呼び出しにフォールバックしたり、クエリ結果を捏造したりしないでください。

使用する場面

ユーザーから次の依頼があった場合に、このスキルを使用します。

• 可観測性データ（トレース、ログ、メトリクス）をクエリ、検索、または参照する
• 集計値（エラー率、p99 レイテンシ、リクエスト数、スループット）を計算する
• 特定のログエントリ、トレース、またはメトリクス値を見つける
• パターン（スパイク、低下、時間経過に伴う傾向）を調査する

次の場合は使用しないでください。

• ユーザーがダッシュボードパネル用の生の ClickHouse SQL（カスタム結合、ウィンドウ関数、ログ本文の正規表現など）を求めている場合。これは別のダッシュボードパネル用 SQL ワークフローであり、このスキルの対象ではありません。
• ユーザーが例外固有のシグナルとして Exceptions Explorer を必要としている場合。現在の MCP コントラクトには例外クエリ用のツールがありません。この制限を説明し、ユーザーの根本的な質問に答えられる場合に限り、同等のエラートレースまたはエラーログのクエリを提案してください。

手順

ステップ 1：シグナルの種類を判断する

ユーザーの意図に適したシグナルを選びます。

ユーザーの意図	シグナル	理由
エラー率、レイテンシ、スループット、リクエスト数	metrics（優先）または traces	メトリクスは事前に集計されているため、最も高速です。リクエストごとの詳細が必要な場合、または一致するメトリクスがない場合は、トレースを使用します。
p50/p75/p90/p95/p99 レイテンシ	metrics（ヒストグラム）または traces（duration_nano で集計）	ヒストグラムメトリクス（例：signoz_latency_bucket）があればメトリクスを優先します。ない場合はトレースの集計にフォールバックします。
特定のログエントリ、エラーメッセージ、スタックトレースを見つける	logs	テキスト検索、パターンマッチング、重大度によるフィルタリングができます。
特定のトレース、遅いリクエスト、エラースパンを見つける	traces	リクエストごとの詳細、スパン属性、期間によるフィルタリングができます。
インフラストラクチャメトリクス（CPU、メモリ、ディスク、ネットワーク）	metrics	リソース使用率には必ずメトリクスを使用します。
取り込み量（バイト数または件数）、コスト、または請求使用量	source=meter（Cost Meter）を指定した metrics	signoz.meter.* の取り込みメトリクス（ログ／スパン／データポイントの件数およびバイト数）はメーターストアにのみ存在します。バイト数は生のシグナルでは取得できません。ドル建てのコストはメトリクスではありません。使用量 × 単価から算出します（ステップ 2 を参照）。groupBy／フィルターは通常のメトリクスと同様に機能しますが、メーターが保持する限られた属性セットのみを対象とし、任意のログ／トレースフィールドは対象外です。メーターが保持していない属性ごとの件数を求める場合は、ログ／トレースを直接集計してください。
「Y ごとの X の数」（ディメンション別の件数／レート）	traces または logs（集計）	グループ化した件数には、signoz_aggregate_traces または signoz_aggregate_logs を使用します。

トレースには、修飾なしの全文検索機能はありません。検出した構造化トレースフィールドに対して CONTAINS を使用してください。searchText による簡易検索はログ専用です。

シグナルが本当に曖昧な場合は、先にユーザーに確認してください。質問をどのように提示するかはホストアプリケーションが決定します（例：構造化された確認ツールやインラインの <assistant_question> タグ）。ホストの UI 表示ルールに従ってください。

ステップ 2：利用可能なデータを確認する

クエリを実行する前に、必ず確認してください。 ツールが返した名前だけを使用し、学習データの知識から推測しないでください。

可能な場合は、確認の呼び出しを並行して実行します。

• メトリクスの場合：ユーザーの意図に一致する部分文字列を searchText に指定して、signoz_list_metrics を呼び出します（例：searchText: "http"、searchText: "latency"）。レスポンスにはメトリクスのタイプ、テンポラリティ、isMonotonic が含まれます。追加の検索を避けるため、これらを signoz_query_metrics に渡してください。フィルタリングやグループ化の前に、signoz_get_field_keys(signal: "metrics", metricName: <discovered-name>) でラベルを確認します。メトリクスのラベルはトレース／ログの属性ではありません（たとえば db.system は、確認によってメトリクスにも含まれていると判明しない限り、スパン属性です）。

  確認したメトリクスのメタデータに基づいて timeAggregation を選択します。

  メトリクスのタイプ	有効な timeAggregation
  ゲージ	latest、sum、avg、min、max、count、count_distinct
  単調増加カウンター／合計	rate、increase
  非単調増加の合計	avg、sum、min、max、count、count_distinct。latest と rate は使用しないでください
  ヒストグラム／指数ヒストグラム	省略してください。集計は自動で行われます

• Cost Meter の場合（取り込み量、コスト、請求）：source=meter を signoz_list_metrics に渡して、メトリクス（signoz.meter.*）を確認します。これらはデフォルトのストアでは参照できず、対象も変化するため、ハードコードしないでください。その後の groupBy／フィルタ／集計は、通常のメトリクスと同様に機能します。ただし、次の 3 点に注意してください。
  バイト数を取得できるのはここだけです（カウントは signoz_aggregate_logs／_traces を直接呼び出しても取得できます）。メーターに保持される属性は限られているため、グループ化できるキーは signoz_get_field_keys(signal: "metrics", source: "meter") で確認してください。必要な属性がなければ、直接カウント（バイト数なし）に切り替えてください。また、ドル建てのコストはメーターのメトリクスではありません。ストアに保持されるのは量だけなので、searchText: "cost" で検索しても見つかりません。コストについて質問された場合は、量のメトリクス（ログ／トレースはバイト数、メトリクスのデータポイントはカウント）を取得し、Settings → Billing にある単位価格を掛けてください。価格が分からない場合は、ユーザーに尋ねてください。

• トレースの場合：サービス名が存在することを確認するため、signoz_list_services を呼び出します。見つからないと判断する前に、pagination.hasMore が true の間は pagination.nextOffset に従ってページを取得してください。必要に応じて、そのサービスの操作名を確認するために signoz_get_service_top_operations を呼び出します。属性のフィルタリングやグループ化の前に、signoz_get_field_keys(signal: "traces") を呼び出してください。

• ログの場合：属性のフィルタリングやグループ化の前に、signoz_get_field_keys(signal: "logs") を呼び出してください。値の検証には、確認後にのみ signoz_get_field_values を使用します。

フィールドキーはシグナルごとに異なります。ログに service.name がない場合もあり、body はログ専用です。別のシグナルで確認したキーを使い回さないでください。同じシグナルについて、この会話内のツール出力でキーが返されている場合に限り、キーの確認を省略できます。ユーザーの入力や記憶に基づいて省略してはいけません。traceID や hostname のような camelCase を推測せず、返されたドット表記をそのまま使用してください。テナントキー（org.id、orgId、organization_id など）を決めつけず、シグナルごとに実際のキーを確認してください。signoz_get_field_values より先に signoz_get_field_keys を呼び出してください。どちらにも signal が必要で、値の取得にはさらに、確認済みの空でない name が必要です。

ステップ 3：適切なツールを選ぶ

質問に答えられる、最も簡単なツールを使用してください。

質問の種類	ツール	使用する場合
メトリクスの時系列、スカラー、比率、または数式	signoz_query_metrics	通常のメトリクスクエリ、Cost Meter の傾向／レート、formula と formulaQueries を使ったメトリクスの比率に使用します。
Cost Meter の合計またはグループ別合計の帰属	signoz_execute_builder_query	検出したメーターのメトリクスを、生の timeAggregation: "sum" とともに使用し、完了した時間単位のバケットを合計します。合計には signoz_query_metrics を使用しないでください。
ログ検索（一致するエントリの検索）	signoz_search_logs	特定のログ行の検索に使用します。リテラルテキストには searchText を使用します（searchScope で一致対象を選択します。デフォルトはログ本文です）。フィールドフィルターには filter、レベルのフィルタリングには severity を使用します。
トレース検索（一致するスパンの検索）	signoz_search_traces	特定のトレース／スパンの検索に使用します。ショートカットの service、operation、error、minDuration／maxDuration と、フィールドフィルター用の filter を使用します。
ログの集計（件数、平均、パーセンタイル）	signoz_aggregate_logs	単純な合計、グループ別の件数、1つの集計による上位N件に使用します。
トレースの集計（件数、平均、パーセンタイル）	signoz_aggregate_traces	単純な合計、グループ別の件数、1つの集計による上位N件に使用します。
複雑なログ／トレースの数式または整形	signoz_execute_builder_query	比率、整形、並べ替え、またはカーディナリティの制御が簡易ツールの範囲を超える場合に使用します。単純なグループ別件数を手作業で組み立てることは避けてください。

ログ検索の標準仕様：

• signoz_search_logs は filter を受け付けます。以前の query エイリアスは 拒否されます。
• searchText は検索するリテラルテキストで、自動的にエスケープされます。 searchScope で一致対象を選択します。デフォルトはログ本文です。filter とは AND 条件で結合されます。searchText を指定せずに searchScope を指定すると、 検証エラーになります。
• searchScope の値：メッセージテキストには body（デフォルト）、キーと値には attribute または resource、すべてのフィールドには all を指定します。 body 以外のスコープは低速で、広い時間範囲では SigNoz に拒否される場合が あります。テキストを保持するキーが不明な場合にのみ使用してください。キーが わかっている場合は、代わりに attribute.<key> CONTAINS 'text' のような 述語を filter に指定します。
• 明示的な複数フィールド検索には、filter: "search('timeout')" を使用します。 signoz://logs/query-builder-guide に記載された search() のスコープでは、 body、attribute、resource、log、またはそれらの許可された組み合わせが サポートされています。スコープを指定しない search() は、サポート対象の すべてのログフィールドを検索します。ユーザーが一部のスコープのみを指定した 場合は、そのスコープを列挙してください。
• フィールドがわかっている場合は、service.name = 'payments' のような既知の フィールドに対する直接的な述語を優先するか、service ショートカットを 使用してください。サーバーはそのショートカットを同じ AND 条件の service.name 述語に組み立てます。未知のフィールドは、まず検出してください。
• 検索リテラルを作成する際は、バックスラッシュを先に、アポストロフィを後に エスケープします。呼び出し元が作成した生の filter は変更せず、再度 エスケープしないでください。

signoz_aggregate_logs／signoz_aggregate_traces では、aggregation は count、count_distinct、avg、sum、min、max、p50、p75、p90、 p95、p99、rate のいずれかの単独のトークンです。括弧や列を含めないで ください。列は aggregateOn に指定します（count と rate には不要です）。 デフォルトの集計式の降順で並べ替える場合は orderBy を省略します。明示的に 並べ替える場合は、groupBy キーまたは集計式を使用してください。カスタム エイリアスや数式には signoz_execute_builder_query が必要です。 すべての signoz_execute_builder_query ペイロードでは、各 builder_query と builder_formula の仕様に、正の値の limit と空でない Query Builder v5 の order を指定してください。Raw リクエストとトレースシグナルの requestType: trace は、デフォルトで100行を返します。トレースは timestamp の降順、 raw ログは timestamp の降順、次に id の降順で並べます。スカラー／時系列リクエストは デフォルトで100グループを返し、メトリクス／数式では __result の降順、 ログ／トレースでは主集計値の降順で並べます。数式の結果は100件のままですが、 数式から参照される各 builder_query には10000を指定してください。各コンポーネントの limit は数式の評価前に適用されるためです。上位100件だけの入力を個別に取得すると、 比率の高いグループが除外される場合があります。これらの入力上限を計算する際は、 disabled: true の数式も含め、すべての数式式を調べ、すべての builder_query のリーフが見つかるまで数式参照をたどってください。この依存関係の走査は 上限の設定にのみ使用します。数式間の決定的な評価順序が保証されるわけではないため、 複合ペイロード全体を検証してください。入力のカーディナリティが10000を超える可能性が ある場合は、フィルターやグループ化の範囲を絞ってください。このワイヤーフィールドは order であり、ダッシュボードエディターの orderBy ではありません。時系列の上位N件は ウィンドウ全体でグループをランク付けするため、短時間の局所的な急増が返される セットから外れる場合があります。

集計における requestType の選択：

• scalar（デフォルト）：「件数はいくつですか？」「p99はいくつですか？」「最も多いサービスはどれですか？」
• time_series：「エラーが急増したのはいつですか？」「レイテンシはどのように変化しましたか？」「傾向を表示」
• 質問に時間的な要素（急増、傾向、変化）が少しでも含まれる場合は、time_series を使用してください

集計ツールが受け付けるのは scalar または time_series のみです。 signoz_execute_builder_query に渡す builder-query エンベロープでは、次の値のみを使用してください。

シグナル	有効な requestType
メトリクス	time_series、scalar
トレース	raw、trace、scalar、time_series
ログ	raw、scalar、time_series

aggregate、table、timeseries、series を決して作り出さないでください。この表は PromQL または ClickHouse SQL のエンベロープには適用されません。

ステップ 4：クエリを実行する

• 結果の関連性を高めるため、必ずユーザーの元の質問を searchContext に含めてください。
• 指定された期間を使用してください。指定がない場合は 1h を使用します。検索／集計のログおよびトレースツールでは、相対的な timeRange 文字列（"1h"、"24h"。デフォルトは 1h）を受け付けます。これらを優先してください。有効な Unix ミリ秒の start／end が指定されている場合は timeRange より優先されます。明示的なタイムスタンプの形式が不正な場合は、timeRange を指定するよう案内する検証メッセージが返されます。 signoz_execute_builder_query には相対指定のオプションがありません。外側の query には JSON 整数の Unix ミリ秒で絶対時刻の start と end を指定する必要があります。指定しないと missing start or end timestamp エラーになります。
• ユーザーのフィルターに合致する場合は、ショートカットパラメーター（service、severity、operation、error）を使用してください。filter 式を作成するよりシンプルで、誤りも起きにくくなります。
• 追加の条件を指定する場合は、ショートカットパラメーターと filter を組み合わせてください。これらは AND 条件として適用されます。
• 余分な自動取得のラウンドトリップを避けるため、signoz_query_metrics では signoz_list_metrics の応答に含まれる metricType、temporality、isMonotonic を渡してください。
• Cost Meter の合計またはグループ別の合計の帰属を求める場合は、signoz_query_metrics ではなく signoz_execute_builder_query を使用してください。外側に query オブジェクトを含む完全なツール引数と、Unix ミリ秒の start／end、requestType: "time_series"、formatOptions、variables を渡してください。ビルダーの仕様では、signal: "metrics"、source: "meter"、検出した metricName と temporality、stepInterval: 3600、および生の timeAggregation: "sum" と spaceAggregation: "sum" を指定します。グループ別の合計では、signoz_get_field_keys でメーターのフィールドを検出し、その name、fieldDataType、fieldContext、signal を groupBy にそのままコピーしてください。フィールドを削除したり翻訳したりしないでください。partial: true とマークされたデータポイントを除外し、返された各グループについて完全な時間単位のバケットを合計してください。
• 合計の帰属ではない Cost Meter の傾向またはレートには、引き続き signoz_query_metrics を使用できます。source=meter を指定し、stepInterval: 3600 を使用してください。ボリュームの傾向には timeAggregation: increase を使用し、秒あたりのレートの場合に限り rate を使用してください。

ステップ 5：結果を処理する

すべての主張を、読み取りで返された内容の範囲内に限定してください。 報告する前に、各結果を分類します。

1. 読み取り失敗：ツールがエラーを返したか、タイムアウトしました。これは、データが存在しない証拠にはなりません。読み取りに失敗したことを伝え、エラーを引用し、ゼロ、「なし」、または合計値を決して報告しないでください。
2. 部分的な結果：注記で hasMore=true と報告された生の検索、nextCursor を含むレスポンス、またはさらに結果がある、あるいは存在する可能性があるという注記があるレスポンス、もしくはちょうど limit 件のグループを返した groupBy 集計（集計ツールはこの状態を示さないため、切り捨てられたものとして扱います）。主張は返された行のみに適用されます（「直近の一致ログ 100 件はすべて pod-a からのものです」など）。返された行数を合計として提示してはいけません。また、部分的な結果から、対象範囲全体または期間全体について「なし」や「すべて」と主張してはいけません。
3. 完全な結果：指定した対象範囲と期間全体に対する正常な集計、または注記で hasMore=false と報告された生の検索（limit 未満の行数で、0 件の場合も含みます）。これだけが、対象範囲全体について「なし」、「すべて」、または合計を示す根拠になります。合計が 1 ページを超える場合は、aggregation: count を指定して signoz_aggregate_logs または signoz_aggregate_traces を使用してください。

返されたデータ：

• 調査結果は、タイムスタンプと値を含む中立的な観察事項として提示してください。
• 回答には期間を含めてください。
• groupBy による集計では、上位の項目を強調してください。グループ数がちょうど limit 件の場合は、さらにグループが存在する可能性があることを伝えてください。グループの総数は報告されません。
• 検索結果では、すべての項目を列挙するのではなく、傾向を要約してください。

データが返されない場合。 何がどの範囲で空だったのかを報告し、それ以上のことは主張しないでください。

1. 指定した対象範囲でゼロ件：正常に完了したクエリで、一致するものがありませんでした。フィルターと期間を示して、次のように伝えてください：「過去 1 時間に service.name = 'checkout-service' に一致するエラースパンはありませんでした。」エラーやトレースがないことは、サービスが正常であること、稼働したことがないこと、またはデータが欠落している理由の証明にはなりません。そのような説明を提示する場合は、可能性として明示してください。
2. 期間内にデータなし：検出でフィールドまたはメトリクスが確認されたものの、指定期間内にデータポイントがありませんでした。データのない期間を報告し、より広い期間を指定するよう提案してください。より広い期間で確認された古いデータは、指定期間内のデータではなく、最近のアクティビティではありません。
3. 検出で見つからない：メトリクス、フィールド、またはサービスが検出結果にありません。検出には対象範囲と上限があり、結果が切り捨てられている場合、一覧にないことからは何も分かりません。
   • signoz_list_services は、トレースがあるサービスのみを一覧表示します（デフォルトは 6h）。hasMore=false になるまで pagination.nextOffset をたどってください。ここに表示されないサービスでも、ログやメトリクスを送信している可能性があります。
   • signoz_list_metrics は、期間内にアクティブなメトリクスを一覧表示します（デフォルトは 1h）。ページングには対応していません。注記で hasMore=true と報告された場合は、searchText で絞り込んでください。
   • signoz_get_field_keys と signoz_get_field_values は、結果を切り捨てると data.complete=false を設定します。searchText で絞り込んでください。

完全な一覧に基づく場合は、「<期間> の <シグナル> では確認されませんでした」と報告し、「存在しない」や「計装されていない」とは表現しないでください。確認すべき可能性として、より広い期間や別の名前とともに、計装の欠落も挙げられます。

詳細調査：

• 集計で興味深い傾向（急増、外れ値のサービスなど）が明らかになった場合は、その範囲の個別のトレースまたはログをさらに調査することを提案してください。
• トレース検索で興味深いスパンが見つかった場合は、signoz_get_trace_details でトレースの詳細全体を取得することを提案してください。

ガードレール

• まず検出する：メトリクス名、フィールド名、サービス名を推測してはいけません。フィールドが確認済みとみなされるのは、この会話で同じシグナルに対するライブ出力が得られた場合のみです。
• 必須パラメーターを指定する：ツールが自動検出することを期待して呼び出してはいけません。signoz_aggregate_* には aggregation が必要です。signoz_query_metrics には signoz_list_metrics で取得した metricName が必要です。signoz_get_trace_details には traceId が必要です。signoz_get_service_top_operations には signoz_list_services で取得した service が必要です。先に検出してから呼び出してください。
• 根本原因を断定しない：データのパターンと相関関係を提示してください。「デプロイがエラーを引き起こしました」ではなく、「checkout のエラー率が14:05に0.2%から4.1%に上昇しました」と記述してください。
• 証拠の範囲を超えて不在を断定しない：読み取りに失敗した場合、タイムアウトした場合、または結果が不完全な場合、不在を示す証拠にはなりません。「なし」「すべて」や合計値を示すには、要求された範囲全体について完全な結果が必要です（ステップ5）。
• 質問ごとに焦点を絞ったクエリを1つ実行する：1つの正確なクエリで回答できる場合、手当たり次第に複数のクエリを実行してはいけません。検出時は並列呼び出しを使用できますが、実行時は正確さを重視してください。
• MCP サーバーのルールを守る：MCP サーバーは、リソース属性フィルター、フィルター演算子、冗長なクエリに関するルールを適用します。それらに従い、特にクエリを高速化するため、フィルターではリソース属性を優先してください。
• ClickHouse の生 SQL を使わない：必ず Query Builder ツールを使用してください。生 SQL を組み立ててはいけません。
• スコープの境界：このスキルでクエリできるのはデータです。ユーザーがクエリを定期的なアラートにしたい場合は、signoz-creating-alerts に案内してください。
• 最終メッセージで apply_filter を出力する。ユーザーがクエリの作成、構築、生成、表示を求めた場合、このターンで成功した signoz_execute_builder_query 呼び出しに渡した完全な v5 query オブジェクトを含む apply_filter アクションを、最終アシスタントメッセージに含めてください。このチップには、内部の compositeQuery だけでなく、クエリ範囲全体のエンベロープ（schemaVersion: "v1"、start、end、requestType、compositeQuery）が含まれます。再構築せず、そのオブジェクトをそのままコピーしてください。簡易ツール（signoz_search_logs、signoz_search_traces、signoz_aggregate_*、signoz_query_metrics）で回答した場合は、小さな limit を指定して検証用の signoz_execute_builder_query を1回実行し、そのクエリオブジェクトをコピーしてください。それができない場合は、チップを省略してください。適切な signal フィールド（metrics、logs、traces）を使用してください。これにより、SigNoz UI はユーザーがエクスプローラーページにクエリを適用したいことを認識できます。apply_filter を出力するのは、ユーザーの主な意図が実行可能なクエリを得ることである場合に限ります。分析結果のテキストですでに回答できる、一度限りのデータに関する質問では出力しないでください。Cost Meter のクエリでは signal: metrics を指定し、コピーしたクエリ仕様に source: meter が含まれていることを確認してください。

例

ユーザー：「過去1時間のcheckoutサービスのエラー率を表示してください」

エージェント：

1. signoz_list_metrics(searchText: "calls", timeRange: "1h") を呼び出し、返されたリクエスト数メトリクスのうち該当するものを選択します。この例では、メトリクスの探索結果として metricType: "sum"、temporality: "cumulative"、isMonotonic: true を持つ signoz_calls_total が返されます。

2. signoz_get_field_keys(signal: "metrics", metricName: "signoz_calls_total") を呼び出してサービスとエラーの両方のラベルを特定し、返された各 name / fieldContext について、同じメトリクスを指定して signoz_get_field_values を呼び出し、checkout-service と STATUS_CODE_ERROR を確認します。この例で返される名前は service.name と status_code です。実際の探索で返される名前を使用してください。

3. これらの完全な引数を指定して signoz_query_metrics を呼び出します。主要な引数でクエリ A を定義します。formulaQueries では、分母にすべてのcheckoutリクエストが含まれるように、異なるフィルターを使ってクエリ B を明示的に定義します。どちらのフィルターでも、ステップ 2 で返されたラベル名をそのまま使用します。

   {
     "searchContext": "Show me the error rate for the checkout service in the last hour",
     "metricName": "signoz_calls_total",
     "metricType": "sum",
     "isMonotonic": true,
     "temporality": "cumulative",
     "timeAggregation": "increase",
     "spaceAggregation": "sum",
     "filter": "service.name = 'checkout-service' AND status_code = 'STATUS_CODE_ERROR'",
     "timeRange": "1h",
     "requestType": "scalar",
     "formula": "A / B * 100",
     "formulaQueries": [{
       "name": "B",
       "metricName": "signoz_calls_total",
       "metricType": "sum",
       "isMonotonic": true,
       "temporality": "cumulative",
       "timeAggregation": "increase",
       "spaceAggregation": "sum",
       "filter": "service.name = 'checkout-service'"
     }]
   }
   

   上記の具体的なメトリクス、メタデータ値、フィールド、フィールド値はすべてテナントの探索結果に置き換えてください。この例が実環境に存在すると決めつけないでください。

4. 次のように提示します：「checkout-serviceの過去1時間のエラー率は2.3％です（14:00～15:00 UTC）。エラーは47件、リクエストは合計2,041件です。」

5. 詳細分析を提案します：「エラー率が最も高いオペレーションを確認しますか？」

---

ユーザー：「ログ内のタイムアウトエラーを見つけてください」

エージェント：

1. signoz_search_logs(searchText: "timeout", severity: "ERROR", timeRange: "1h") を呼び出します。
2. 次のように提示します：「過去1時間にタイムアウトエラーが23件見つかりました。大半はpayment-service（18件）とgateway（5件）から発生しています。よく見られるパターンは、downstream-apiへのgRPC呼び出しにおける「context deadline exceeded」です。」
3. 次のように提案します：「タイムアウトの発生箇所を確認するため、これらのサービスのトレースを調べますか？」

---

ユーザー：「cartサービスのp99レイテンシはどれくらいですか？」

エージェント：

1. signoz_aggregate_traces(aggregation: "p99", aggregateOn: "duration_nano", service: "cart-service", requestType: "scalar", timeRange: "1h") を呼び出します。
2. 次のように提示します：「cart-serviceの過去1時間のp99レイテンシは1.2秒です。」
3. 次のように提案します：「オペレーション別に内訳を表示するか、時間経過に伴う傾向を表示しますか？」

---

ユーザー：「frontendでエラーが急増したのはいつですか？」

エージェント：

1. signoz_aggregate_traces(aggregation: "count", error: "true", service: "frontend", requestType: "time_series", timeRange: "6h") を呼び出します。
2. 次のように提示します：「過去6時間のfrontendのエラー数です。11:30 UTCに急増し、エラー数は約5件/分から約45件/分に跳ね上がり、12:15までに通常の水準に戻りました。」
3. 次のように提案します：「急増時にどのような種類のエラーが発生したか確認しますか？」

---

ユーザー：「各サービスが取り込んでいるログデータ量はどれくらいですか？」

エージェント：

1. サービス別のバイト数 → Cost Meter。signoz_list_metrics(searchText: "log", source: "meter") を呼び出し、実際の探索で返された名前と単位からログ量メトリクスを選択します。
2. signoz_execute_builder_query を呼び出します。外側の query ラッパー、schemaVersion: "v1"、整数のUnixミリ秒範囲、requestType: "time_series"、formatOptions、variables を指定し、ビルダー仕様には signal: "metrics"、source: "meter"、探索で見つかったメトリクス名とtemporality、stepInterval: 3600、生の timeAggregation: "sum"、spaceAggregation: "sum"、および signoz_get_field_keys が返す service.name フィールドを指定します。name、fieldDataType、fieldContext、signal を groupBy にコピーします。
3. partial: true のデータポイントを除外し、完全な時間単位のバケットをサービスごとに合計して、探索で判明した単位でサービスごとの取り込み量を提示します。（メーターに要求された属性がない場合は、直接カウントに切り替え、バイト数はメーターでのみ取得できることを伝えます。）