Secret Detection サービス: モニタリング
このランブックを使用するタイミング
このランブックは、Secret Detection サービスを監視する際に使用することを意図しています。Gitlab.com や Dedicated で有効化された際に発生する可能性がある信頼性の問題やパフォーマンスの低下を特定・軽減するためのものです。
何を監視するか？
主にシステムメトリクスとサービス内で発生する繰り返しエラーを監視する必要があります。以下は絞り込まれた監視対象のリストです。
- リソース飽和度: 飽和度は現在利用されている有限リソースの比率の指標です。
- 集約されたサービスレベル指標（SLI）
- Apdex スコア: Apdex はサービスの許容可能な時間内に完了するリクエストの指標です。
- エラー比率: エラーレートは1秒あたりの未処理サービス例外の指標です。可能な場合はクライアントエラーを除外します。
- リクエストレート: 操作レートは、このサービス内のすべてのコンポーネントで処理されているすべてのリクエストの合計です。単一のユーザーリクエストが複数のコンポーネントへのリクエストにつながる場合があることに注意してください。
- サービスによって発生する繰り返しのアプリケーションエラー。
サービスをどのように監視するか？
上記の監視対象のほとんど（リソース飽和度と集約 SLI）は、サービス概要ダッシュボードで確認できます。
繰り返しのアプリケーションエラーは通常、GitLab エラーモニタリング/Sentry ツールで確認できます。ただし、まだサービスとエラーモニタリングツールを統合していません。統合の進捗を追跡するには、この Issue を参照してください。
それまでの間、アプリケーション関連のエラーを探すために ERROR レベルのログメッセージをログで確認してください。ログはこちらで確認できます。
サービスの SLO 違反があるかどうかはどうすれば分かりますか？
サービスは SLO 違反が発生した場合に Slack アラートを受信します。現在、alertmanager によって複数のメトリクスを追跡する6つのアラートが設定されています。
SLO 違反が発生した場合、alertmanager は #feed_alerts-general と #g_secure-secret-detection Slack チャンネルにアラートを送信します。
注意: alertmanager はこのサービスの SLO 違反が発生した場合、オンコール SRE チームメンバーにページを送信しません。サービスは Runway のデフォルト SLI を継承しており、それがアラートの深刻度を S4 に設定します。S1 または S2 としてマークされたアラートのみがオンコールにページが送られます。つまり、Secure::Secret Detection チームが Slack アラートに目を向けることでサービス中断インシデントへの対応に責任を持ちます。
alertmanager が Slack アラートのトリガーに失敗した場合、alerts ダッシュボードでサービスに対して_アクティブに_発動しているアラートを常に確認できます。
サービスが発行するログはどのように確認するか？
Runway は GCP Cloud Logs を使用してサービスが発行するログを管理しています。サービスのログはこちらで確認できます。
