signoz-reducing-telemetry-cost

前提条件

このスキルでは、SigNoz MCP サーバーのツール（signoz_list_metrics、 signoz_get_field_keys、signoz_execute_builder_query、 signoz_get_top_metrics、signoz_check_metric_usage、signoz_check_metric_cardinality、 signoz_aggregate_logs、signoz_aggregate_traces、signoz_search_logs、 signoz_list_alert_rules、signoz_get_alert、signoz_get_service_top_operations）を多用します。ワークフローを実行する前に、signoz_* ツールが利用可能であることを確認してください。利用できない場合は、SigNoz MCP サーバーがインストールまたは設定されていません。先に signoz-mcp-setup を実行してください。調査全体はこれらのクエリに基づいています。サーバーがなければ、分析するものはありません。

結論を出す前に、両方の参照ファイルを読んでください。

• references/otel-attribute-cardinality.md：確認したメトリクスラベルを分類します。
• references/infra-do-not-drop.md：組み込みのインフラストラクチャページ および APM／サービスページ を支えるメトリクス（スパン由来の signoz_* RED メトリクス）を記載しています。使用状況で未使用と表示されても、これらを「安全に削除できる」として提示してはいけません。

ワークフロー

常にコストメーターのスナップショット（ステップ 1）から始めます。コストを完全に調査する場合は、データのあるすべてのシグナルについて、現在のコスト寄与度が高い順（第一位、第二位、第三位）に、メトリクス、ログ、トレースの各ステップを実行します。最後にレポートを作成します（ステップ 5）。

ステップ 1：コストメーターのスナップショット

まず、シグナルを横断したコストの全体像を把握します。必ず source: "meter" を指定して signoz_list_metrics を呼び出してください。返されたメトリクス名、種類、テンポラリティ、単位は、メーターのセットが変化するため、最新の信頼できる情報として扱います。次に、該当する各メトリクスに対して signoz_execute_builder_query を実行します（source: "meter"、requestType: "time_series"、stepInterval: 3600、検出された temporality、timeAggregation: "sum"）。ツール引数の完全なテンプレートについては references/cost-meter-queries.md を参照してください。完全な時間単位のバケットを合計し、partial: true とマークされたデータポイントはすべて除外します。コストメーターの合計値やグループ化された合計値の内訳には、signoz_query_metrics を使用しないでください。

成功したクエリから返された値のみを報告してください。クエリが失敗した場合、または MCP ツールが利用可能になった後も使用可能な値が返されない場合は、実行予定のクエリを示し、合計を計算できなかったことを伝えてください。合計値を決して捏造しないでください。ツールが利用できない場合は、前提条件に従ってください。

直近 7 日間（end = 現在、start = end − 7 日間）のシグナルごとの合計（スパンサイズ、ログサイズ、メトリクスのデータポイント数）を取得し、次の値を計算して報告します。

• 主要なコスト要因。 金額ベースの比重が最も高いシグナルです。トレース／ログは $0.30/GB、メトリクスは $0.10/M サンプルです（目安としてのみ使用し、削減額を引用してはいけません）。これは生のボリュームではなく、コストに基づいて選定します。
• レコードあたりのバイト数。 span.size ÷ span.count および log.size ÷ log.count です。これにより、シグナルの問題がペイロードサイズによるものか、ボリュームによるものかが分かります。

次に、主要なシグナルを環境別、サービス別に分類します。まず signal: "metrics" および source: "meter" を指定して signoz_get_field_keys を呼び出してください。返されたキーのみを使用し、各キーの name、fieldDataType、fieldContext、signal を翻訳したり削除したりせず、生のビルダーの groupBy にコピーします。完全な groupBy を指定して同じメータークエリを実行し、グループごとの上位約 10 件とその割合を報告します。非本番環境（staging、dev、test、qa、sandbox、preview、uat、…）がボリュームの 40% を超える場合は、シグナルレベルの変更を行う前に、そのキーに対して Ingestion Limits を推奨します：https://signoz.io/docs/ingestion/signoz-cloud/keys/

ステップ 2：メトリクス

コストメーターにメトリクスデータがある場合は、コスト寄与度の高い順に実行します。または、ユーザーがメトリクスのコストやカーディナリティについて明示的に質問した場合に実行します。 2a. signoz_get_top_metrics でボリューム順にランク付けします。 取り込まれたサンプル数に基づく上位 100 件のメトリクスを、計算済みの割合と totalValue のサンプル数とともに返します（start／end を渡します）。これがボリューム順の作業リストになります。ヒストグラムメトリクス（.bucket サフィックス）は、スクレイプごとに各バケット境界が個別のサンプルになるため、通常は上位を占めます。

2b. signoz_check_metric_usage で使用状況を確認します。 上位のメトリクス名を渡します（1 回の呼び出しにつき最大 50 件）。メトリクスごとに { dashboards, alerts, error } が返されます。メトリクスを削除候補とできるのは、error が空で、かつ dashboards と alerts の両方が空の場合に限ります。error が空でない場合、検索は不完全です（タイムアウト、またはこのエンドポイントがない古い SigNoz が原因です）。返されたリストは信頼できないため、そのメトリクスを未使用として扱わないでください。最初に要確認としてマークし、使用状況を手動で確認してください。両方のリストが空の正常な検索結果は削除候補ですが、以下のガード条件が適用されます。

削除禁止ガード（必須）。 使用状況が空のメトリクスを「安全に削除できる」とする前に、必ず references/infra-do-not-drop.md と照合してください。Infrastructure ページ（Hosts / Kubernetes）は、ダッシュボードではなく組み込みクエリを通じて system.* や多くの k8s.*／container.* メトリクスを参照するため、これらを削除するとページが壊れる場合でも、使用状況チェックでは空と報告されます。候補が削除禁止リストに該当する場合は、決して「安全に削除できる」とせず、**「インフラページの依存関係：Hosts／Kubernetes ビューが壊れます。削除する前に、このビューを使用していないことを確認してください」**と提示してください。この条件は、使用状況が空という結果よりも優先されます。また、顧客が制御するものではなく APM ページを動作させる自動生成 RED メトリクスである、内部の signoz_／signoz. メトリクスも除外してください。

2c. signoz_check_metric_cardinality でカーディナリティを調べます。 削除候補ではないメトリクスと、削除候補でもユーザーが保持を選んだメトリクスに対して実行してください。ユーザーが削除に同意したメトリクスでは、カーディナリティ分析を行っても意味がありません。このツールは、カーディナリティの高い順に属性キーを返し、それぞれに valueCount とサンプルの values が含まれます。references/otel-attribute-cardinality.md に従って分類してください。

• UNBOUNDED（url.full、http.target、db.query.text、client.port、trace.id、exception.stacktrace など）：上限なく増加するため、現在の件数に関係なく警告してください。
• ACCUMULATING（container.id、k8s.pod.uid、k8s.pod.name、k8s.pod.start_time）：valueCount は稼働中の系列数ではなく、過去の Pod の入れ替わりを反映します。この違いを説明してください。
• HIGH but bounded（valueCount が約 100 以上）：集約を推奨する前に、ダッシュボードやアラートで実際にそのラベルをフィルターに使用しているか確認してください。

インフラ ID の優先ルール（必須）。 references/infra-do-not-drop.md で保護されているメトリクスでは、そのメトリクスの Infra エンティティ／ビューで使用される ID 属性とページメタデータを保持してください。エンティティの特定に使われるエンティティ UID／名前属性を集約または削除しないでください。Pods ページで Pod Age の表示に使用されるため、Pod メトリクスでは k8s.pod.start_time を保持してください。このルールは、カーディナリティのリファレンスに記載された一般的な ACCUMULATING 対策よりも優先されます。

カーディナリティを減らすには、metricstransform プロセッサの aggregate_labels アクションを使って系列を統合してください（課金対象コストはサンプル数なので、実際にコストを削減するには統合が必要です）。サンプル数を変えず、系列の衝突を招く transform プロセッサの delete_key は使わないでください。ラベルがメトリクスの ID に不可欠な場合は、メトリクス全体を削除するか、SDK 側で修正してください。ヒストグラムでは、バケット境界を減らすと P99 への影響を抑えながらサンプル数を削減できます。ドキュメント： https://signoz.io/docs/userguide/drop-metrics/ · https://signoz.io/docs/metrics-management/dropping-metric-labels/ 2d. 収集間隔を見直します。 維持する必要がある高ボリュームのメトリクスについて、変更を推奨する前に、その生成方法と現在の間隔を特定します。間隔を長くすると取り込まれるデータポイントは減りますが、時間解像度も低下するため、ダッシュボードとアラートに必要な解像度は維持してください。生成元に応じた制御を使用します。Collector が生成するメトリクスにはレシーバーの collection_interval、Prometheus がスクレイプするメトリクスにはスクレイプ間隔、SDK のプッシュメトリクスには、その SDK がサポートしている場合に OTEL_METRIC_EXPORT_INTERVAL を使用します。メトリクスをデルタと累積のテンポラリティ間で切り替えることは、決して推奨しないでください。同じメトリクスのテンポラリティを変更すると、SigNoz のクエリが壊れる可能性があります。

ステップ 3：ログ

Cost Meter にログデータが表示された場合は、コストへの寄与が大きい順に実行します。また、ユーザーがログコストについて明示的に質問した場合にも実行します。

3a. 合計値と内訳で進む経路を決定します。

• ログの合計 GB（絶対的なコスト値）：ライブの単位と意味がログのバイト数を表すと確認したメーター指標を使用し、ステップ 1 と同様に合計する signoz_execute_builder_query を使います。
• 内訳：同じメータークエリを service.name でグループ化して実行します。これにより、サービスごとに 1 つのグループと、帰属情報がないログの未設定／空の service.name グループが返されます。グループ化した結果だけを使って比率を計算し、分子と分母の基準を一致させます。グループ化した合計はグループ化していない合計と異なることがあるため、帰属済みのグループ合計をグループ化していない合計で割ってはいけません。
  • 帰属済み GB ＝ service.name が空でないグループの合計。
  • グループ化した合計 ＝ 空のグループを含む、すべてのグループの合計。
  • 帰属率 ＝ 帰属済み ÷ グループ化した合計。
• これは明確な分岐です。
  • 10％以上 → 経路 A（サービスモード）。
  • 10％未満 → 経路 B（名前空間モード）。 ログの送信元は OTel SDK ではなく、インフラのフォワーダー（Fluent Bit／Fluentd／Vector）であるため、service.name は設定されません。経路 B は一般的ではない構成なので、数値が妥当か確認してください。

3b. 選択した帰属経路を分析し、修正候補を特定します。 このステップで挙げる修正は候補にすぎません。ログ量の削減（送信元のログレベル変更も含む）を推奨する前に、ステップ 3c のアラート確認を完了してください。

経路 A、サービスモード（10％以上）。 signoz_aggregate_logs を使用し、aggregation: count、groupBy: "service.name,severity_text" を指定して重大度の内訳を取得します。重大度を次のように分類します。削減可能＝INFO、INFORMATION、DEBUG、TRACE、VERBOSE、高シグナル＝ERROR、FATAL、CRITICAL、WARN、WARNING。GB 数の多いサービスごとに、次を確認します。

• 削減可能なログが大半で、サービス独自のコードが出力元 → 候補：LOG_LEVEL=WARN を設定します（送信元での生成を停止します）。
• 削減可能なログが大半で、サードパーティライブラリが出力元 → 候補：instrumentation_scope.name に基づく Collector フィルターを使います（signoz_search_logs のサンプルにある scope_name を確認します）。
• 送信元にアクセスできない → 候補：severity_text が削減可能な重大度（INFO／DEBUG／TRACE）のみと一致する Collector フィルターを使います。WARN 以上も対象になる範囲指定は決して使用しないでください。
• 高シグナルが大半（WARN／ERROR が 50％超）→ ログは維持する価値があります。高いエラー率は実際の問題を示している可能性があるため、別途指摘し、フィルタリングして取り除くことは推奨しないでください。

サービスの重大度ガード。 上記の修正候補（LOG_LEVEL=WARN、または INFO／DEBUG のみに対象を限定した Collector フィルター）は、仕様上 WARN 以上を維持するため、重大度の内訳によって妨げられることはありません。ただし、ステップ 3c ではアラートが対象レコードに依存しているか引き続き確認します。このガードが適用されるのは、高シグナルのログも同時に破棄する操作、つまりサービス全体の一括破棄、または WARN／ERROR／FATAL／CRITICAL を含む範囲の severity_text フィルターのみです。そのいずれかを推奨する前に、高シグナル率 ＝（ERROR、FATAL、CRITICAL、WARN、および WARNING を含むすべての高シグナル重大度の合計。大文字・小文字を区別せず照合）÷ サービスの合計を計算します。これが 1％超（または絶対数が無視できない程度）の場合、一括操作は行わないでください。削減対象を INFO／DEBUG に限定し、エラーは実際のシグナルとして指摘してください。 パス B、名前空間モード（< 10%）。

• 上位の名前空間：signoz_aggregate_logs、count、 groupBy: "k8s.namespace.name,deployment.environment"、count の降順、件数上限は約10件。24h の期間を使用します（大規模なテナントでは7日間の名前空間スキャンがタイムアウトします。Cost Meter に名前空間のディメンションがないため、count を代替指標として使用します）。
• 名前空間ごとの重大度：signoz_aggregate_logs、count、 groupBy: "k8s.namespace.name,severity_text"。
• サンプル：signoz_search_logs、filter: "k8s.namespace.name = '<ns>'"、小さな件数上限を指定します。body、severity_text、scope_name を確認します。

名前空間の重大度に関するガード。 高シグナルの割合 ＝ 名前空間の総数に占める、ERROR、FATAL、CRITICAL、WARN、および WARNING を含むすべての高シグナル重大度の割合（一致判定では大文字と小文字を区別しません）。1%を超える場合（または絶対数が無視できない場合）、名前空間全体の削除やフィルタリングを検討してはいけません。 フィルタは、特定のノイズの多いパターン（ログカテゴリ、severity_text の一致条件、またはコンポーネント）に限定します。アクティブなエラーを含む名前空間は削除しないでください。全体としてほぼ INFO/DEBUG のみの名前空間に限り、ステップ3cに従って一括削除の候補となります。

• サンプルの severity_text が空の場合 → フォワーダーが未解析の生ログ行を送信しています。解決するには、OTel Collector のログパイプラインに json/regex パーサーを設定します（これがないと重大度によるフィルタリングはできません）。
• k8s.event.* ログはボリュームが大きく価値が低いことが多いため、アラートの対象でなければ削除できます。

3c. ログアラート：ログ削減を推奨する前に必ず確認します。 signoz_list_alert_rules を使い、すべてのページをページネーションで取得します（pagination.hasMore が false になるまで pagination.nextOffset をたどります。最初のページで止めると、後続ページのアラートを見落とし、実際には安全でないフィルタを安全だと判断してしまいます）。alertType == "LOGS_BASED_ALERT" を保持します。それぞれについて signoz_get_alert(id) を実行し、condition.compositeQuery.queries[].spec.filter.expression と groupBy を確認して、どのサービス／重大度／名前空間を監視しているかを把握します。フィルタによってアラートを見落とす場合は アラートのカバー範囲に影響します と記載し、アラート名を明記します。ドキュメント：https://signoz.io/docs/logs-management/guides/drop-logs/

ステップ 4：トレース

Cost Meter にスパンデータが表示された場合、またはユーザーがスパンのコストについて明示的に尋ねた場合に実行します。

4a. グローバルな操作名ビュー。最初に確認します。 signoz_aggregate_traces を使用し、aggregation: count、groupBy: "name"、orderBy: "count() desc"、上限 20 を指定します。サービスフィルターは指定しません。 これにより、すべてのサービスにわたる自動計装のノイズ（ヘルスチェック、SQL、キャッシュ、サイドカー）を一度に確認できます。

4b. サービスごとのコストと、サービスごとの操作。 サービスごとのスパン GB 数を確認するには、ライブの単位と意味がスパンバイト数を表すことが確認できたメーターのメトリクスを使用して、ステップ 1 と同様に合計し、signoz_get_field_keys が返す service.name フィールドでグループ化して、signoz_execute_builder_query を使用します（返された name、fieldDataType、fieldContext、signal をそのままコピーします）。各サービスの割合は、別途取得したグループ化されていない合計や上位 N 件の合計ではなく、グループ化された合計（同じクエリの全サービスグループの合計）を基準に計算します。分子と分母は同じグループ化の基準にしてください。GB 数の上位 3 サービスそれぞれについて、signoz_get_service_top_operations（または service: "<svc>" と groupBy: "name" を指定した signoz_aggregate_traces）で主要な操作を確認します。操作の内訳は簡潔にするため上位 3 件のみとしますが、エラー率チェック（4c）と以下の APM ガードは、削減を検討するすべてのサービスに適用されます。

4c. サービスごとのエラー率。 signoz_aggregate_traces を使用して、まず count、groupBy: "service.name"（合計）で確認し、次に error: true を指定して再度確認します。サービスごとのエラー率は、エラー数 ÷ 合計数です。

4d. トレースアラート。 signoz_list_alert_rules を使い、すべてのページをページネーションで取得します（pagination.hasMore が false になるまで pagination.nextOffset に従います）。alertType == "TRACES_BASED_ALERT" を保持し、各アラートが何を監視しているかを signoz_get_alert(id) で確認します。

主要な操作を分類します。

• よくあるノイズ候補：ヘルスチェック／生存確認（/health、/ping、/ready、grpc.health.v1.Health/Check）、プロキシ／サイドカー（envoy.*、istio.*、linkerd.*）。これらは候補として扱い、自動的に削除して安全だと判断しないでください。以下の APM ガードは引き続き適用されます。
• 結論を出す前に調査し、決めつけないでください。SQL の断片（使用言語によってライブラリが異なります。Java → JDBC、Python → SQLAlchemy、Node → pg/mysql2/sequelize、.NET → EF/Dapper）、キャッシュコマンド（HMGET/GET/SET… → ioredis、redis-py、Jedis、go-redis…）、見慣れない gRPC メソッドについては、まず検索してください。検索しても特定できない場合は、その旨を伝えてください。

修正レイヤー。 ノイズであることが確認された操作については、生成をソースで止めるため、デプロイ済みの SDK または計装ライブラリで文書化されている無効化／除外設定を優先してください。設定を提示する前に、言語とライブラリを特定してください。Java、Python、Node.js、.NET では設定方法が異なります。SDK に設定がない場合は、操作名に対する Collector フィルターを使用してください。

スパン → APM ガード（必須）。 コスト削減の手段として、ヘッドサンプリング、確率的サンプリング、テールサンプリング、その他いかなるトレースサンプリングも推奨または設定してはいけません。ユーザーがサンプリングを求めた場合は、その両方の影響を伝えてください。組み込みの APM／Services メトリクスは保持されたトレースのみを対象とするため、実際のトラフィックに対する絶対リクエスト数とレートは過少計上されます。レイテンシの傾向やエラーの急増は引き続き参考になる場合がありますが、APM ページはすべてのリクエストを表さなくなります。この有用性の制限があっても、サンプリングを許可された手段にするものではなく、プロセッサーの配置も例外ではありません。

ノイズであることが確認されたものには、SDK の除外設定と Collector フィルターを使用してください。設定を提示する前に、削除された操作は APM に表示されなくなることを明記してください。 Docs: https://signoz.io/docs/traces-management/guides/drop-spans/

ステップ 5：調査結果を報告する

まずTL;DRを示します。見出しは付けず、次の 2 つの要素を簡潔にまとめます。

1. コストの概要：主な要因となっているシグナル、その規模、発生源（サービス、環境、メトリクス名）を示します。複数の要因が合わさって大部分を占める場合は、それぞれの割合と合計への影響を示します。
2. 優先順位付きの対応リスト：実行可能な調査結果をすべて優先順に並べ、それぞれのステータスを併記します。ステータスは、安全に実施可能／事前確認が必要（確認事項を記載）／ダッシュボードに影響（対象を記載）／アラートのカバレッジに影響（対象アラートを記載）／インフラページに依存（Hosts／K8s ビューに影響）とします。メトリクスの削減については、コストへの影響が分かるよう、ボリュームの削減率も記載します。

TL;DR の後に記載するのは、まだ触れていない根拠や背景情報だけにします。ステップ 2～4 の判断順に沿って対応を優先順位付けしますが、対応リストやシグナルごとの手順を繰り返さず、各調査結果とガードレールはそれぞれ一度だけ述べます。

会話調を保ち、見出しや表を使った定型的なレポートではなく、優先順位付きのトリアージリストにします。Cost Meter データがあるシグナルは、すべてこの 1 つのリストで扱います。ワークフローですでに分析したシグナルを調査するかどうか、尋ねてはいけません。

ガードレール

• 部分的な確認だけで、削減やフィルターを「安全」と判断してはいけません。 アラートへの影響がないと判断する前に、signoz_list_alert_rules を pagination.hasMore がなくなるまでページネーションします。また、signoz_check_metric_usage の error が空でない場合、使用状況は「未使用」ではなく「不明」と扱い、手動確認が必要です。不完全な検索結果を安全の根拠にしてはいけません。
• ボリュームは、検出された Cost Meter メトリクスと、その実際の単位から算出します。スパン／ログのボリュームはバイト、メトリクスのボリュームはサンプル数を使います。スパン／ログのレコード数をボリュームとして示してはいけません。
• コストの合計とグループ別の合計内訳には、 signoz_query_metrics ではなく、 signoz_execute_builder_query を使います。 生の timeAggregation: sum、1 時間ごとの stepInterval: 3600、完全なデータポイントのみを使用します。
• この生クエリのエスケープハッチを通じて送信する Cost Meter の builder_query には、必ず limit: 100 と Query Builder v5 の order: [{key:{name:"__result"}, direction:"desc"}] を含めます。これはワイヤー形式の order であり、ダッシュボードの orderBy ではありません。グループ別クエリでもこれを維持します。上限は期間全体を通じたグループの順位付けに使われるため、短期間だけ存在したグループが上位 N 件から漏れる可能性があることを明記します。
• references/infra-do-not-drop.md に従い、インフラページまたは APM のメトリクスを削除しても安全だと示してはいけません。 使用状況の確認でダッシュボードやアラートがないと分かった場合も同様です。
• ログ： アクティブな ERROR／WARN を含むサービスやネームスペース全体を削除またはフィルタリングするよう勧めてはいけません（高シグナルのログが 1% を超える場合、または絶対数が無視できない場合）。フィルターはノイズの多いパターンに絞ります。修正の順序は、発生源での設定（LOG_LEVEL=WARN）→ Collector のスコープフィルター（instrumentation_scope.name）→ severity_text フィルターです。
• ログのアトリビューションには厳密な閾値があります。 10% 以上なら Path A、10% 未満なら Path B です。割合を計算します。
• トレース： ヘッド、確率的、テール、その他すべてのサンプリングを推奨または設定してはいけません。サンプリングを行うと、組み込みの APM／Services メトリクスは保持されたトレースのみを対象とするため、絶対リクエスト数やレートがすべてのトラフィックを表さなくなります。
• UNBOUNDED と IDENTIFIER のラベルは、必ず指摘します。 問題は現在の数だけでなく、その推移にあります。
• 保持期間の変更は提案してはいけません。コスト削減額を推定してはいけません。 ダッシュボードやアラートを「未使用」「ノイズが多い」「重複」と呼んではいけません。件数のみを報告します。
• 主張の根拠をクエリ結果に結び付けます。 あるシグナルの Cost Meter データがない場合は、その旨を述べ、件数ベースの代替指標を使ってはいけません。内訳にすでに示したメトリクスを再列挙してはいけません。ボリューム上位約 20 件以外のメトリクスは、個別には無視できる程度です。

追加リソース

• references/cost-meter-queries.md：Cost Meter の調査、完全な signoz_execute_builder_query テンプレート、単位変換、グループ化した場合としない場合の注意点。
• references/infra-do-not-drop.md：組み込みの Infrastructure ページと APM/Services ページを支える指標。削除を推奨してはなりません。
• references/otel-attribute-cardinality.md：メトリクスラベルの分類に関するリファレンス （UNBOUNDED / ACCUMULATING / BOUNDED / IDENTIFIER）。
• signoz-generating-queries スキル：この調査で案内しているアドホックな追加クエリ用です。