ステージングモニタリング
ステージング環境は本番環境と同じサービスレベルモニタリングルールを採用しています:
サービスは以下の条件が満たされたときに利用可能とみなされます:
ステージングモニタリングの目標は、進行中のデプロイを停止するために使用できる SLO アラートを持つことです。これにより、問題のあるデプロイが本番環境に到達する前に早期に検出・停止できます。これを実現するには、環境に十分なベースロードトラフィックがあり、SLO 障害のシグナルが十分に強い必要があります。
ステージング環境は、実際のユーザーが本番環境ほど多くないため、本番環境ほどのユーザーアクティビティがありません。この環境は主に GitLab QA パイプラインなどのテスト自動化や、コードを手動でテストするエンジニアによって使用されます。これらのアクティビティは十分なトラフィックを生成しないため、実際のユーザーからのシグナル不足を補うために人工的なトラフィックを生成するカスタムの負荷エミュレーションツールが設計されました。
負荷エミュレーション
CMBR は、対象の GitLab インスタンスにトラフィックを生成する Web クローラーです。Web、API、Git、Registry、Pages のサービスに対してトラフィックを生成できます。
既知の制限事項:
- クローラーは
GETリクエストのみを実行し、データを作成しません。ただし、ステージングに対して実行される既存の E2E テストが GitLab の基本機能をカバーしているため、この問題はそれほど深刻ではありません。 - 負荷は合成的なものであり、特定のデータに依存するエッジケースなど、すべてのユースケースをカバーしているわけではありません。
- 既存のステージングテストデータは本番環境のものと異なります。
- IP やユーザーのレート制限などのレート制限がトラフィック生成に影響する場合があります。
- ステージング環境は本番環境と比較してスペックが低いです。環境を壊さないように負荷を調整する必要があります。
- Git トラフィックは現時点では HTTP のみです。
ステージング上のクローラー設定
CMBR は gstg と cny-gstg に対してスケジュールパイプラインを使用してステージングのトラフィックを生成しています。このツールは、負荷を生成してレート制限をバイパスするために、監査者ロールを持つ専用ユーザーを使用します（ステージングクローラーの認証情報は 1Password の Engineering ボールトに保存されています）。
スループットは環境変数によって制御され、サービスごとに異なる値に調整されています。負荷を増やす必要がある場合は、ステージング環境のパフォーマンスを考慮し、既存の GitLab QA パイプラインに影響を与えないことを確認する必要があります。そうしないと、テスト実行に断続的なエラーが発生し、デプロイに影響を与える可能性があります。
ステージングサービスモニタリング
Alertmanager は、特定のサービスで Apdex スコアまたはエラーレートが違反した場合に #feed_alerts_staging Slack チャンネルに SLO アラートを送信します。その後、インフラチームがアラートをさらに調査します。
特定のサービスの健全性を確認するには、以下のダッシュボードを使用できます:
サービスモニタリングの詳細については、GitLab.com のモニタリングページをご覧ください。
現在のセットアップについてご質問がある場合は、#f_staging_service_level_monitoring Slack チャンネルにお問い合わせください。
