GitLabアプリケーションのサービスレベル指標(SLI)
GitLab 14.4 で導入されました。
Rubyのコードベースで直接Service Level Indicator(SLI)を定義することができます。これにより、オペレーションとその成功の定義が実装に近く保たれ、機能を構築する人がその機能をどのように監視すべきかを簡単に定義できるようになります。
既存の SLI
rails_requestglobal_search_apdexglobal_search_error_rateglobal_search_indexing_apdexsidekiq_execution
新しいSLIの定義
SLIはGitlab::Metrics::Sli::Apdex またはGitlab::Metrics::Sli::ErrorRate クラスで定義できます。SLIを定義すると、Railsアプリケーションから2つのPrometheusカウンタが出力されます。どちらのカウンタもほぼ同じように動作し、合計オペレーションカウントを含みます。Apdex は成功率を使用して成功率を計算し、ErrorRate はエラー率を使用してエラー率を計算します。
以下のメトリクスが定義されています:
-
Gitlab::Metrics::Sli::Apdex.new('foo')定義されています:-
gitlab_sli_foo_apdex_totalを定義します。 -
gitlab_sli_foo_apdex_success_total成功した測定回数。
-
-
Gitlab::Metrics::Sli::ErrorRate.new('foo')定義されています:-
gitlab_sli_foo_totalを定義します。 -
gitlab_sli_foo_error_totalエラーの測定数。このメトリクスはエラー率であるため、エラーは合計数で割られます。
-
この例に示されているように、これらはベース名を共有することができます ( この例ではfoo )。同じオペレーションを参照する場合は、この方法をお勧めします。
成功したオペレーションのパフォーマンスを測定するためにApdex を使うべきです。失敗したリクエストのパフォーマンスはErrorRate で追跡されるので、測定する必要はありません。例えば、リクエストが指定された待ち時間のしきい値内で実行されているか どうかを測定することができます。
失敗したオペレーション率を測定するにはErrorRate を使うべきです。たとえば、失敗したリクエストが500 以上の HTTP ステータスを返すかどうかを測定できます。
最初のスクレイピングの前に、可能な全てのラベルの組み合わせで SLI を初期化しておくことが重要です。これにより、これらのカウンタを計算で使用する際に結果が混乱するのを避けることができます。
SLIを初期化するには、.initialize_sli クラスメソッドを使用します:
Gitlab::Metrics::Sli::Apdex.initialize_sli(:received_email, [
{
feature_category: :team_planning,
email_type: :create_issue
},
{
feature_category: :service_desk,
email_type: :service_desk
},
{
feature_category: :code_review_workflow,
email_type: :create_merge_request
}
])
メトリクスは、初めてスクレイピングされる前に初期化する必要があります。これは現在、on_master_start ライフサイクル・イベント中に行われます。これはメトリクスの初期化が戻るまでアプリケーションの準備完了を遅らせるので、このために追加されるオーバーヘッドが理解され、許容できるものであることを確認してください。
SLI のオペレーション追跡
新しく定義されたSLIでオペレーションを追跡するには次のようにします:
Gitlab::Metrics::Sli::Apdex[:received_email].increment(
labels: {
feature_category: :service_desk,
email_type: :service_desk
},
success: issue_created?
)
このSLIで#increment を呼び出すと、Prometheusの合計カウンタがインクリメントされます。
gitlab_sli:received_email_apdex:total{ feature_category='service_desk', email_type='service_desk' }
渡された引数success: が真であれば、成功カウンタもインクリメントされます:
gitlab_sli:received_email_apdex:success_total{ feature_category='service_desk', email_type='service_desk' }
エラー率SLIの場合、同等の引数はerror: と呼ばれます:
Gitlab::Metrics::Sli::ErrorRate[:merge].increment(
labels: {
merge_type: :fast_forward
},
error: !merge_success?
)
サービスモニタリングとアラートにおけるSLIの使用
アプリケーションが新しいSLIのメトリクスを出力している場合、それらはアラートにつながるようにメトリクスカタログから消費され、ステージグループとGitLab.com全体の可用性のエラーバジェットに含まれる必要があります。
新しいSLIをApplication-SLIライブラリに追加することから始めます。その後、以下の情報を追加します:
-
nameコードで定義されているSLIの名前。例えば、received_email。 -
significantLabelsメトリクスに属する Prometheus ラベルの配列。例:["email_type"].SLI の重要なラベルにfeature_categoryが含まれている場合、メトリクスはステージ・グループのエラー・バジェットにも反映されます。 -
featureCategorySLI が単一の機能カテゴリに適用される場合は、このフィールドを通して静的に指定することで、SLI をステージ・グループのエラー・バジェットに反映させることができます。 -
description: SLIを説明するMarkdown文字列。ダッシュボードやアラートに表示されます。 -
kindインジケーターの種類。例えばsliDefinition.apdexKind。
完了したら、make generate を実行して、新しい SLI の記録ルールを生成します。このコマンドは、significantLabels に集約されたメトリクスを発するすべてのサービスの記録を作成します。
これらの変更を含むマージ・リクエストを作成し、スケーラビリティ・チーム・メンバーにレビューを依頼してください。
これらの変更がマージされ、Thanosでアグリゲーションが記録されたら、Thanos にクエリを実行して、新しいアグリゲーション メトリクスの成功率を確認します。たとえば、次のようになります:
sum by (environment, stage, type)(application_sli_aggregation:rails_request:apdex:success:rate_1h)
/
sum by (environment, stage, type)(application_sli_aggregation:rails_request:apdex:weight:score_1h)
この成功率は、この SLI をサービスに追加するときに適切な SLO を設定するための指針になります。
次に、適切なサービスカタログファイルに SLI を追加します。たとえば、web サービス:
rails_requests:
sliLibrary.get('rails_request_apdex')
.generateServiceLevelIndicator({ job: 'gitlab-rails' })
追加のセレクタを渡したり、SLIのプロパティをオーバーライドするには、サービス・モニタリングのドキュメントを参照してください。
静的に定義された機能カテゴリを持つSLIは、すでに指定されたSlackチャンネルでSLIに関するアラートを受け取ることができます。詳細については、アラートルーティングのドキュメントを参照してください。このプロジェクトでは、これを拡張して、ソース・メトリクスにfeature_category ラベルを持つ SLI のアラートもルーティングできるようにしています。
何か質問があれば、遠慮なくScalability issue trackerにイシューを作成するか、Slackの#g_scalabilityに私たちを探しに来てください。