緑の状態なのに指標から77件が消えた

目標

サンプル制限、ラベル削除、メトリクスの除外、ソースの計装の変更を、実際のPrometheusで比較し、情報が保存されたかを説明します。

なぜ重要なのか

業務は正常なのに収集が失敗することもあれば、up=1なのに必要なデータが消えることもあります。個人用VMの中のPrometheus 3.14.0、合成エクスポーター、独立した対照ターゲットだけを使います。最大13サンプルの小さな実験であり、大規模な負荷・OOM・パフォーマンスのテストではありません。実際の個人情報は入れないでください。サービスはloopbackでのみ待ち受け、nobodyで実行します。本番のLabHubや外部のPrometheusは変更しません。従来のPCAのKubernetesラボとは違い、このラボでは、実際のローカルプロセスのスクレイパーとTSDBを使います。 55分のラボで、有効期限が切れる前に必要なら延長してください。セッションが終了すると、VM・TSDB・学習者のファイルは回収されます。

用意されている環境

Prometheusはhttp://127.0.0.1:9098, エクスポーターはhttp://127.0.0.1:9911, 対照ターゲットは9912です。設定は/etc/pca-cardinality/prometheus.jsonで、Prometheusが読むYAMLのJSON表現です。エクスポーターのモードは/etc/pca-cardinality/exporter.json、学習者の答案と観測は/root/pca-cardinalityにあります。最初の観測はinitial.jsonです。システムサービスを再起動したり、TSDBを消したりしないでください。観測したMainPIDとInvocationIDを基準線と比較して、再起動で問題を隠していないことを確認します。

python3 /opt/fixtures/pca_cardinality_lab.py observeは、現在の設定・元のレスポンス・クエリを読みます。 complete Nは、作成した答案を確認し、限定された変更と実際の観測を保存します。 2は合成ユーザーの増加、3は上限を上げる、4は区別するラベルの削除、5はリクエストのメトリクスの除外、6はソースの集計と上限の復帰です。 1・7・8は観測のステップです。指示文のkey=valueは説明であり、JSON形式の例に合わせてファイルを作成してください。観測には、実際にロードされた設定と、configの宣言が一緒に入っています。原文と、現在適用されている結果を、並べて読んでください。 solve Nは、正解を見ることと同じで、ない答案だけを作ります。既存の誤答・部分的な答案は、自分で直す必要があります。 prepare Nは、前のステップだけを準備します。現在の答案は作りません。grade Nは読み取りだけを行います。

ステップ

initial.jsonの実際の基準線で、元のレスポンス5サンプル、リクエストの時系列4個、業務のHTTP 200を確認してください。baseline.jsonに、job=pca-cardinalityの文字列と、raw_samples=5、current_series=4、business_http=200の整数を書き、complete 1を実行します。独立したpca-sentinelターゲットの値は7、upは1でなければなりません。
overflow.jsonに、sample_limit=8、raw_samples=13の整数と、whole_scrape_failed=true、business_failed=falseのブール値を書き、complete 2を実行してください。ヘルパーが、合成ユーザーを4人から12人に増やします。元のHTTPは200なのに、該当jobのup=0とsample limitのエラーが生じる新しいスクレイプを観測します。一部の8個だけ成功したと報告しないでください。
budget.jsonに、sample_limit=16、current_series=12、total=78の整数と、fixes_instrumentation=falseのブール値を書き、complete 3を実行してください。ヘルパーが、sample_limitを一時的に上げて、promtoolのチェックとreloadを行います。実際に適用された設定と、元のサンプル13個、現在のリクエストの時系列12個、合計78を比較してください。
collision.jsonに、dropped_label=user_idの文字列、aggregates_values=falseのブール値、reported_total=1とup=1の整数を書き、complete 4を実行してください。metric relabelingで、区別するラベルだけを消したときの、3つのサンプルを見ます。今回の固定入力では、元の合計は78なのに、現在のクエリは1です。labeldropを合算とみなしたり、必ずup=0になると推測したりしないでください。
drop.jsonに、dropped_metric=pca_checkout_requests_totalの文字列と、requests_missing=true、up_implies_complete=falseのブール値を書き、complete 5を実行してください。リクエストのメトリクスfamilyを除外した、実際の設定を読みます。元のレスポンス13個のうち、業務のgaugeが1つだけ残り、up=1ですが、リクエストのクエリは空のベクトルです。これを値0と区別してください。
instrument.jsonに、mode=aggregateの文字列と、sample_limit=8、current_series=1、total=78の整数、user_id_removed_at_source=trueのブール値を書き、complete 6を実行してください。エクスポーターがrouteの合計78をソースで公開し、一時的なフィルターを外します。元のサンプルから2個で、合計が保存される3つのサンプルを確認します。2つのサービスの実行識別子は、最初と同じでなければなりません。
observation-3.jsonのresult.snapshot.atの数字を、そのまま読んでください。history.jsonに、historical_time=その数字、historical_series=12、current_series=1の整数と、deletes_history=falseのブール値を書き、complete 7を実行します。過去の時刻の実際のクエリのcount=12、sum=78と、現在のcount=1を比較してください。seriesのメタデータの一覧だけで、過去のサンプルを証明することはしません。
report.jsonに、sample_limit=8、semantic_total=78の整数と、unsafe_identifiers=false、zero_loss_from_up=falseのブール値を書き、complete 8を実行してください。現在の情報の保存、独立した対照群、サービスの再起動がないこと、過去のサンプルの照会を確認します。8というラボの上限を、すべてのサービスの推奨値に一般化したり、個人情報が自動で削除されたと主張したりしないでください。

参考と限界

修正は、ヘルパーが確認した宣言の範囲でのみ行います。pendingのジャーナルが残っていても、同じリクエストを自動で繰り返しません。宣言の変更とreloadが完了して、観測だけが失敗した場合は、保存された変更と宣言が同じかを確認し、観測だけをリトライします。完了した答案・観測・ジャーナルを直接書き換えると、以降のステップも失敗します。ハッシュは、誤った上書きを検出するための仕組みであり、同じVMのrootによるすべての改ざんを防ぐセキュリティ上の保証ではありません。採点は60秒、前のステップの準備は90秒の予算です。ラベル削除で見えた合計1は、固定したバージョン・入力での観測です。常に最初の値が残るという一般的な契約ではありません。空のベクトルは、値0とは違います。現在の集計は、TSDBの過去のサンプルの削除ではありません。管理用のデータ削除APIは有効にしません。元のカウンターの値は、合成の累積回数であり、毎秒の処理率ではありません。メトリクスのディメンションを減らすと失う詳細な質問も、記録してください。 3回の短い観測が、長期間のパフォーマンスや損失率を保証するわけではありません。8・16はラボの値であり、本番の推奨上限ではありません。設定の公式ドキュメント・ HTTP API

元のサンプルと現在の時系列の基準線を読む

initial.jsonの実際の基準線で、元のレスポンス5サンプル、リクエストの時系列4個、業務のHTTP 200を確認してください。baseline.jsonに、job=pca-cardinalityの文字列と、raw_samples=5、current_series=4、business_http=200の整数を書き、complete 1を実行します。独立したpca-sentinelターゲットの値は7、upは1でなければなりません。

メトリクス名1つが、複数のラベルの集合を持つことがあります。

業務は正常なのに収集だけが失敗する状態を作る

overflow.jsonに、sample_limit=8、raw_samples=13の整数と、whole_scrape_failed=true、business_failed=falseのブール値を書き、complete 2を実行してください。ヘルパーが、合成ユーザーを4人から12人に増やします。元のHTTPは200なのに、該当jobのup=0とsample limitのエラーが生じる新しいスクレイプを観測します。一部の8個だけ成功したと報告しないでください。

業務のHTTPと、該当jobのスクレイプの結果を分けてください。

上限を上げることと、計装の改善を区別する

budget.jsonに、sample_limit=16、current_series=12、total=78の整数と、fixes_instrumentation=falseのブール値を書き、complete 3を実行してください。ヘルパーが、sample_limitを一時的に上げて、promtoolのチェックとreloadを行います。実際に適用された設定と、元のサンプル13個、現在のリクエストの時系列12個、合計78を比較してください。

制限を増やしても、現在の時系列数も減ったかを見てください。

区別するラベルを消したときの合計を検証する

collision.jsonに、dropped_label=user_idの文字列、aggregates_values=falseのブール値、reported_total=1とup=1の整数を書き、complete 4を実行してください。metric relabelingで、区別するラベルだけを消したときの、3つのサンプルを見ます。今回の固定入力では、元の合計は78なのに、現在のクエリは1です。labeldropを合算とみなしたり、必ずup=0になると推測したりしないでください。

ラベルを消すことと、値を足すことは、別の演算です。

メトリクスを捨てて得た緑のランプを診断する

drop.jsonに、dropped_metric=pca_checkout_requests_totalの文字列と、requests_missing=true、up_implies_complete=falseのブール値を書き、complete 5を実行してください。リクエストのメトリクスfamilyを除外した、実際の設定を読みます。元のレスポンス13個のうち、業務のgaugeが1つだけ残り、up=1ですが、リクエストのクエリは空のベクトルです。これを値0と区別してください。

空のベクトルと、値が0のサンプルを区別してください。

ソースの計装で、意味を保存したまま減らす

instrument.jsonに、mode=aggregateの文字列と、sample_limit=8、current_series=1、total=78の整数、user_id_removed_at_source=trueのブール値を書き、complete 6を実行してください。エクスポーターがrouteの合計78をソースで公開し、一時的なフィルターを外します。元のサンプルから2個で、合計が保存される3つのサンプルを確認します。2つのサービスの実行識別子は、最初と同じでなければなりません。

フィルターのあとの数字だけでなく、元のエクスポーターのレスポンスから比較してください。

現在のクエリと過去のサンプルを区別する

observation-3.jsonのresult.snapshot.atの数字を、そのまま読んでください。history.jsonに、historical_time=その数字、historical_series=12、current_series=1の整数と、deletes_history=falseのブール値を書き、complete 7を実行します。過去の時刻の実際のクエリのcount=12、sum=78と、現在のcount=1を比較してください。seriesのメタデータの一覧だけで、過去のサンプルを証明することはしません。

timeパラメーターで、当時の評価時刻を指定したクエリが必要です。

収集予算と情報の保存の範囲を報告する

report.jsonに、sample_limit=8、semantic_total=78の整数と、unsafe_identifiers=false、zero_loss_from_up=falseのブール値を書き、complete 8を実行してください。現在の情報の保存、独立した対照群、サービスの再起動がないこと、過去のサンプルの照会を確認します。8というラボの上限を、すべてのサービスの推奨値に一般化したり、個人情報が自動で削除されたと主張したりしないでください。

upは、必要なすべてのメトリクスの意味が保存されることを保証しません。