ドキュメントを調べ、他の人と話し合った結果、問題と解決策を見つけました。
ウィスパーファイル形式の設計方法では、ユーザー(またはアプリケーション)がファイルの最小間隔よりも速く更新を公開することを期待しstorage-schemas.conf
ます。このファイルは、さまざまな時間間隔の解像度で保持するデータの量を構成するために使用されます。
私のstorage-schemas.conf
ファイルは1分の最小保持時間で設定されました。デフォルトのStatsDデーモン(etsyから)は、10秒ごとにカーボン(グラファイトデーモン)に更新するように設計されています。これが問題になる理由は次のとおりです。60秒の期間にわたってStatsDは6回報告し、各書き込みは最後の書き込みを上書きします(1分に1回より速く更新しているため、その60秒間隔で)。これにより、グラフに非常に奇妙な結果が生成されます。これは、1分間の最後の10秒間が完全に停止し、その期間中のアクティビティが0になる可能性があるためです。その結果、その1分間に書き込んだすべてのデータが完全に無効になります。
これを修正するには、最大解像度10秒でデータを保存するようにファイルを再構成する必要storage-schemas.conf
がありました。そのため、StatsDからのすべての更新は、上書きされずにウィスパーデータベースに保存されます。
Etsyはstorage-schemas.conf
、カーボンのインストールに使用していた構成を公開しました。これは次のようになります。
[stats]
priority = 110
pattern = ^stats\..*
retentions = 10:2160,60:10080,600:262974
これには10秒の最小保持時間があり、6時間分の保存時間があります。しかし、次の問題のため、保存期間を大幅に延長しました。
このデータを数日間収集させたところ、まだ見送られていることに気づきました(そして報告中です)。これは2つの問題が原因でした。
StatsD(古いバージョン)は、10秒のレポート期間ごとに1秒あたりの平均イベント数のみをレポートしました。つまり、キーを1秒間に100回、次の9秒間に0回インクリメントした場合、10秒の終わりにstatsDは100ではなく10をグラファイトに報告します(100/10 = 10)。これは、10秒間のイベントの総数を報告できませんでした(明らかに)。
新しいバージョンのstatsDは、stats_counts
10秒ごとにメトリックごとのイベントの総数をログに記録するバケットを導入したため、この問題を修正します(したがって、前の例で10を報告する代わりに、100を報告します)。
StatsDをアップグレードした後、過去6時間のデータが素晴らしく見えることに気付きましたが、過去6時間を超えて見ると、状況が奇妙に見えました。次の理由は次のとおりです。
グラファイトはデータを保存するため、データを高精度の保持から低精度の保持に移動します。これは、etsyのstorage-schemas.conf
例を使用すると、10秒の精度で6時間後、データが60秒(1分)の精度に移動されたことを意味します。6つのデータポイントを10秒から60秒の精度に移動するために、グラファイトは6つのデータポイントの平均を実行します。したがって、最も古い6つのデータポイントの合計値を取得し、それを6で除算します。これにより、その60秒間の10秒あたりの平均イベント数が得られます(イベントの合計数ではなく、私たちが気にするものです)。具体的には)。
これがまさにグラファイトの設計方法であり、場合によっては有用かもしれませんが、私たちの場合、それは私たちが望んでいたものではありません。この問題を「修正」するために、10秒の精度保持時間を60日に延長しました。60日を超えると、1分と10分の精度を保存しますが、そのデータは私たちにとってそれほど有用ではないため、基本的に理由はありません。
これが誰かに役立つことを願っています、それが数日間私を悩ませていることを知っています-そして私はこの目的のためにこのソフトウェアのスタックを使用している人々の巨大なコミュニティがないことを知っています、それで本当に理解するのに少し研究が必要でした何が起こっていたのか、そして私が望む結果を得る方法。