すべてのプロダクト
Search

このプロダクト

    Simple Log Service:メトリックストレージに関する FAQ

    ドキュメントセンター

    Simple Log Service:メトリックストレージに関する FAQ

    最終更新日:Jun 10, 2025

    rateとincrease関数の結果が異常に大きな値を生み出すことがあるのはなぜですか?

    これらの関数は、値が経時的に増加する、増加するメトリックデータにのみ適用できます。この異常は、Prometheus Engine ソースコードで説明されています。

    以下のスクリーンショットは、rate 関数と increase 関数がタイムウィンドウで結果を計算する方法を示しています。最初に、最初の 2 つの値の差が resultFloat に代入されます。後続の値が減少した場合、前の値 (prevValue) が resultFloat に追加され、最終的な値が異常に大きくなります。

    image.png

    トラブルシューティング

    1. PromQL を使用して、値の減少を確認します。最初に、タイムフィルターを異常が発生した期間に絞り込み、次の PromQL クエリを実行します (xxxx_metric を実際のメトリック名に置き換えます)。結果セットにデータポイントが含まれている場合、これは「値の減少」を示します。

      クエリ：(xxxx_metric{} - xxxx_metric{} offset 1s) < 0
ステップ：1s

    2. 異常値のタイムフレームについて、次のような SQL を使用して元のデータポイントを取得します。

      * | select *, from_unixtime(__time_nano__/1000000.0)  from "metricstore_name.prom" where __name__='metric_name' and element_at(__labels__, 'filter_labelKey')='filter_labelValue' order by __time_nano__
      説明

      SQL で複数の element_at 関数を使用して、タイムフレームをさらに絞り込むことをお勧めします。

    3. SQL の結果セットはタイムスタンプでソートされているため、生の誤ったデータポイントを簡単に観察できます。

    メトリックが特定のメトリックストアに既に書き込まれているときに、PromQL ステートメントを実行してもデータがクエリされない場合はどうすればよいですか?

    次のシナリオで対応する問題が存在するかどうかを確認します。

    • シナリオ 1：構文解析ステータスがメトリックストアの検索ボックスに自動的に表示され、指定された PromQL ステートメントの構文が有効かどうかが示されます。構文が無効な場合は、プロンプトに従って変更します。

      image

    • シナリオ 2：次の図に示すように、メトリックストアの [カスタム分析] ページに移動します。検索ボックスで、次の SQL ステートメントを実行して、指定された期間内にデータが存在するかどうかを確認します。

      SQL ステートメントの __name__ フィールドは、メトリック名を指定します。

      * | select * from "<メトリックストア名>.prom" where __name__ = 'demo_api_request_duration_seconds_bucket'

      image.png

      image.png

    上記の 2 つのシナリオで問題が発生しない場合は、Prometheus クエリ コンピュートエンジンの ベクトル選択 ロジックと lookback-delta メカニズムが原因でこのエラーが発生します。

    Prometheus クエリ コンピュートエンジンは、PromQL という名前のクエリ言語を提供します。 PromQL を使用してデータをクエリする場合、すべてのデータポイントが計算されるわけではありません。各クエリ操作が実行される前に、ベクトル選択 操作が実行されます。 PromQL 構文でサポートされているすべての演算子と関数は、ベクトル選択 プロセスに基づいて次のカテゴリに分類できます。[1m] や [1h] などの角かっこで囲まれた時間間隔で終わる範囲ベクトルセレクタと、インスタントベクトルセレクタ。詳細については、「範囲ベクトルセレクタ」および「インスタントベクトルセレクタ」をご参照ください。

    次のサンプルコードは、ベクトルセレクタの使用方法の例を示しています。

    RangeVectorSelector:
rate(http_requests_total[5m])
delta(http_requests_total[5m])
count_over_time(http_requests_total[5m])


InstantVector:
http_requests_total
absent(http_requests_total)
count(http_requests_total)

    範囲ベクトルセレクタは、次の図に示すように、[xx] 演算子で指定された時間範囲内のすべてのデータポイントを計算することにより、サンプルの範囲を選択します。演算子 count_over_time ( up [30s] ) は、過去 30 秒以内のすべてのデータポイントが計算されることを示します。

    image.png

    PromQL の lookback-delta メカニズムは、インスタントベクトルセレクタに対してのみ有効です。インスタントベクトルセレクタは、lookback-delta パラメータの値に基づいて特定の時間間隔内のデータをバックトラックし、最も近い時点のデータポイントを現在の時点の値として使用します。ほとんどの場合、生データの書き込み時間とクエリ時間は一致しません。特定の時点のデータ値をクエリする場合、選択した時点の n 分前のデータポイントがバックトラックされ、最も近い時点のデータポイントが現在の時点の値として使用されます。デフォルトでは、Simple Log Service は、選択した時点の 3 分前のデータポイントをバックトラックします。関連パラメータの変更方法については、「メトリッククエリの API 操作」をご参照ください。

    この例では、クエリの startTime は 00:09:28 です。この時点で生データポイントが存在しない場合、システムは 00:09:28 の 3 分前のデータをバックトラックします。 00:06:28 から 00:09:28 の間にデータが書き込まれていない場合、00:09:28 のデータポイントは選択されません。同様に、00:09:40 のデータポイントはクエリ時間 00:09:43 に選択され、00:09:55 のデータポイントはクエリ時間 00:09:58 に選択されます。

    image.png

    ただし、メカニズムに基づいて、次の特別なシナリオが存在します。期間内にデータポイントが存在しない場合でも、PromQL ステートメントを使用して特定の期間内のデータがクエリされます。この例では、00:10:00 以降はデータが存在しません。 00:10:13、00:10:28、00:10:43、および 00:12:58 にデータをクエリすると、システムは lookback-delta メカニズムに基づいてクエリ時間の 3 分前のデータをバックトラックし、上記のクエリに対して 00:10:00 のデータポイントを返します。

    image.png

    インスタントベクトルセレクタと範囲ベクトルセレクタは、異なるベクトル選択ロジックを使用します。データがクエリされない場合は、次のシナリオに基づいてエラーのトラブルシューティングを行うことができます。

    • RangeVectorSelector

      演算子 [xx] で指定された時間間隔が小さく、step パラメータで指定されたステップサイズが大きい。この場合、各計算操作の前にセレクタでデータポイントが選択されない可能性があります。

      たとえば、up メトリックの生データは、毎時 0 分に書き込まれます。次のクエリパラメータを構成します。

      startTime: 10:30:00
endTime  : 18:30:00
step     : 1h
query    : count_over_time(up[10m])

      この例では、7 つのデータポイントを含む応答が期待されますが、実際のクエリ結果は空です。原因：startTime からステップごとに計算操作が 1 回実行されます。データは 11:30:00、12:30:00、13:30:00、14:30:00、15:30:00、16:30:00、17:30:00、および 18:30:00 に計算されます。各計算操作の前に、セレクタは各クエリ時間の 10 分前のデータをバックトラックします。ただし、指定された時間間隔内にデータポイントは存在しません。

    • InstantVectorSelector

      lookback-delta パラメータの値が小さく、step パラメータで指定されたステップサイズが大きい。この場合、各計算操作の前にセレクタで最も近いデータポイントが選択されない可能性があります。

      たとえば、up メトリックの生データは、毎時 0 分に書き込まれます。次のクエリパラメータを構成します。

      startTime: 10:30:00
endTime  : 18:30:00
step     : 1h
query    : count(up)

      Prometheus では、lookback-delta パラメータのデフォルト値は 5 分です。 Simple Log Service メトリックストアでは、デフォルト値は 3 分です。この例では、データは 11:30:00、12:30:00、13:30:00、14:30:00、15:30:00、16:30:00、17:30:00、および 18:30:00 に計算されます。各計算操作の前に、セレクタは各クエリ時間の 3 分前のデータをバックトラックし、最も近い時点のデータポイントを指定されたクエリ時間の値として選択します。生データポイントの分布がまばらであるため、指定された時間間隔ではデータポイントが見つかりません。その結果、クエリ結果も空になります。

    ソリューション

    1. クエリパラメータの startTime、endTime、および step パラメータを変更し、パラメータ設定をデータ書き込み時間と一致させます。その後、指定されたデータ書き込み時間のデータポイントを選択できます。

      この例では、クエリに対して 7 つのデータポイントが返されます。実際のシナリオでは、メトリックポイントの書き込み時間は不規則です。その結果、クエリパラメータ設定を書き込み時間と常に一致させることはできません。このソリューションを採用しないことをお勧めします。

      startTime: 10:00:00
endTime  : 18:00:00
step     : 1h
query    : count(up)

    2. step パラメータに小さい値を指定します。たとえば、前の InstantVectorSelector シナリオで step パラメータを 3 分に設定します。その後、選択操作がより高い頻度で実行されます。このソリューションは、生データポイントの分布がまばらであってもデータポイントを選択できるように、選択操作の数を増やします。

    3. lookback-delta パラメーターまたは [xx] オペレーターにより大きな値を指定します。このようにして、選択の時間間隔を大きくして、未加工データポイントの書き込み時間をより多く含めることができます。

    特定の時点より後にはデータが書き込まれていないにもかかわらず、PromQL 文を使用して特定の時点より後のデータがまだクエリされる場合はどうすればよいですか?

    このエラーは、Prometheus の ルックバックデルタメカニズム が原因で発生します。

    特定の時点以降にデータが書き込まれていない場合でも、PromQL ステートメントを使用して特定の時点以降のデータが引き続きクエリされるのはなぜですか?

    このエラーは、Prometheus の ルックバックデルタメカニズム が原因で発生します。

    同じ時間範囲の最新の結果が履歴の結果と異なるのはなぜですか?

    2 つの可能性があります。

    1. 時間フィルターが「相対時間」に設定されている場合、開始パラメーターと終了パラメーターの変更により、「lookback-delta」操作中に選択されるデータポイントが異なる可能性があり、結果に一貫性がなくなります。この動作は Prometheus の標準であり、正常と見なされます。

    2. 2 回の実行の間隔が大きく、同じ時間範囲を共有している場合、履歴クエリ中に（書き込み遅延のために）Simple Logs サービス側にすべての必要なデータポイントが到着していなかった可能性があります。計算で使用されるデータの違いにより、結果に一貫性がなくなる可能性があります。この場合、PromQL で offset 構文を使用してクエリウィンドウを前にシフトすることで、書き込み遅延によるエラーを修正できます。

    クエリ リクエストが、クエリごとの消費計算リソースが上限を超えているために拒否された場合はどうすればよいですか?

    クエリ応答に「time Seriesまたは項目が多すぎます、xxxxxx」や「parallel Masterノードのtime Seriesまたは項目が多すぎます、xxxxx」などのエラーメッセージが含まれている場合、クエリは大量のデータを読み取っており、コンピューティング レイヤーでメモリ制限をトリガーしています。

    image.png

    解決策

    1. より短いクエリ時間範囲を指定します。

    2. 実行時間が指定された時間枠に大きく依存する場合は、同時コンピューティングを有効にすることをお勧めします。

    「ベクターに同じラベルセットを持つメトリックを含めることはできません」というエラーメッセージが表示された場合はどうすればよいですか?

    • 原因 1：__labels__ フィールドの値にあるラベル名がアルファベット順にソートされていません。

      Metricstore に書き込まれる __labels__ フィールドの値は、複数のラベルで構成されています。各ラベルには、<ラベル名>#$#<ラベル値> 形式のラベル名とラベル値が含まれています。複数のラベルは、縦棒（|）で区切られます。メトリック識別子内のラベルは、ラベル名でアルファベット順にソートする必要があります。詳細については、「メトリック識別子」をご参照ください。

      __labels__ フィールドの値にあるラベル名がアルファベット順にソートされていない場合、このエラーが発生します。__labels__ フィールドの値にあるラベル名がアルファベット順にソートされているかどうかを確認するには、次の SQL 文を実行します。

      * | select * from (
select __labels__, array_join(array_sort(split(__labels__, '|')), '|') as rightLabels from "<Metricstore 名>.prom" where __name__!=''
) where __labels__ != rightLabels

    • 原因 2：__labels__ フィールドの値に空のラベル値が存在します。

      Prometheus エンジンは、値が空のラベルを無効と見なします。Prometheus エンジンは、計算中に無効なラベルを削除します。__labels__ フィールドの値に空のラベル値が存在するかどうかを確認するには、次の手順を実行します。

      1. より小さいクエリ時間範囲を指定して、このエラーが発生するおおよその時間間隔を見つけます。

      2. 次の SQL 文を実行します。

        * | select __labels__ from "<Metricstore 名>.prom" where __name__!='' and regexp_like(__labels__, '.*#\$#\|.*|.*#\$#$')

        結果が返された場合は、空のラベル値が存在します。データ レポートを実装するために使用されるコードを修正して、無効なラベルを削除することをお勧めします。

    生データに存在するラベル情報が PromQL 文を実行してもクエリできない場合はどうすればよいですか?

    __labels__ フィールドの値にあるラベル名がアルファベット順にソートされていない場合、このエラーが発生します。__labels__ フィールドの値にあるラベル名がアルファベット順にソートされているかどうかを確認するには、次の SQL 文を実行できます。

    * | select * from (
select __labels__, array_join(array_sort(split(__labels__, '|')), '|') as rightLabels from "<メトリックストア名>.prom" where __name__!=''
) where __labels__ != rightLabels

    by 句または without 句を含む PromQL 文によって予期しない結果が返された場合はどうすればよいですか?

    __labels__ フィールドの値にあるラベル名がアルファベット順にソートされていない場合、このエラーが発生します。__labels__ フィールドの値にあるラベル名がアルファベット順にソートされているかどうかを確認するには、次の SQL 文を実行できます。

    * | select * from (
select __labels__, array_join(array_sort(split(__labels__, '|')), '|') as rightLabels from "<メトリックストア名>.prom" where __name__!=''
) where __labels__ != rightLabels

    メトリック探索でデータが使用できない場合はどうすればよいですか?

    考えられる原因は、デフォルトのクエリ時間範囲内にデータが存在しないことです。

    指定した時間範囲内にデータが存在することを確認します。

    説明

    探索の応答速度を上げるため、探索のクエリ時間範囲はデフォルトで過去 5 分です。

    image.png

    クエリ対象のメトリックデータに多数の時系列データが欠落している場合はどうすればよいですか?

    Simple Log Service コンソールの Metricstore のクエリおよび分析ページでクエリ操作を実行すると、[limit] パラメーターを使用して、SQL または PromQL 文で返されるデータ量を制御します。このパラメーターの値を増やすことをお勧めします。

    image.png

    PromQL 計算結果に Warning キーワードが存在する場合はどうすればよいですか?

    考えられる原因は、データのプル中にシャードの最大読み取りキャパシティに達したため、指定されたクエリ時間範囲内のデータの読み取りに失敗したことです。 より小さいクエリ時間範囲を指定するか、シャードを分割して全体のスループットを向上させることをお勧めします。

    image.png

    「1 つの時系列につき 11,000 ポイントの最大解像度を超えました。クエリの解像度を下げてみてください (?step=XX)」というエラーメッセージが表示された場合はどうすればよいですか?

    Prometheus では、各時系列に最大 11,000 個のサンプルを含めることができます。(endTime - startTime)/step の最大値は 11000 です。より短いクエリ時間範囲を指定するか、[ステップ] パラメーターに大きい値を指定することをお勧めします。

    image.png