GitLabで実現する本格的なアプリケーション監視とインシデント管理

Last updated at 2025-11-23Posted at 2025-11-23

GitLabで実現する本格的なアプリケーション監視とインシデント管理

アプリケーションの監視と運用は、DevOpsワークフローにおいて欠かせない要素です。GitLabは、エラートラッキングからインシデント管理、オンコール対応まで、包括的な監視機能を提供しています。本記事では、GitLabの監視機能を活用して、効率的な運用体制を構築する方法を解説します。

1. 監視プロジェクトの設計

まず、監視データを集約するプロジェクトの設計から始めます。小規模なアプリケーションであれば、ソースコードと同じプロジェクトで監視機能を利用できます。しかし、複数のサービスやリポジトリを持つ大規模なアプリケーションでは、専用の監視プロジェクトを作成することを推奨します。

専用プロジェクトを作成するメリットは以下の通りです。

すべての開発チームと運用チームがデータにアクセスでき、コラボレーションが促進されます
異なるソースからのデータを一箇所でクエリおよび関連付けることができ、調査が加速します
すべての観測データの単一の情報源となり、メンテナンスと更新が容易になります
管理者にとって、単一のプロジェクトでユーザー権限を一元管理できるため、アクセス管理が簡素化されます

監視機能を有効にするには、プロジェクトに対してAdministratorまたはOwnerロールが必要です。

2. エラートラッキングの実装

GitLabのエラートラッキング機能は、アプリケーションで発生したエラーを特定、優先順位付け、デバッグするための強力なツールです。エラー情報はSentry SDKによって収集され、バックエンドに送信されます。バックエンドとして、GitLab統合型とSentryベースの2つの選択肢があります。

2.1. バックエンドの選択

バックエンド	提供環境	データ収集	データ保存	データクエリ
GitLab統合型	GitLab.com	Sentry SDK	GitLab.com	GitLab.com
Sentryベース	GitLab.com、GitLab Dedicated、GitLab Self-Managed	Sentry SDK	Sentryインスタンス（Cloud Sentry.ioまたはセルフホスト）	GitLab.comまたはSentryインスタンス

2.2. GitLab統合型エラートラッキングの設定

GitLab.comでは、GitLab統合型エラートラッキングが利用できます。この機能は、Sentry SDKを使用してエラー情報を収集し、GitLab.com上に保存します。

設定手順は以下の通りです。

プロジェクトの Settings > Monitor に移動します
Error Tracking セクションを展開します
Enable error tracking で Active を選択します
Error tracking backend で GitLab を選択します
Save changes を選択します
表示される Data Source Name (DSN) をコピーします

2.3. Sentryベースエラートラッキングの設定

すべてのGitLab環境（GitLab.com、GitLab Dedicated、GitLab Self-Managed）でSentryベースのエラートラッキングを利用できます。

前提条件:

プロジェクトに対してMaintainerロール以上が必要です

設定手順は以下の通りです。

Sentry.ioにサインアップするか、セルフホストSentryインスタンスをデプロイします
Sentryで新しいプロジェクトを作成します（GitLabプロジェクトごとに1つのSentryプロジェクトを作成）
Sentry認証トークンを生成します（最低限 project:read、event:read、event:write スコープが必要）
GitLabでエラートラッキングを有効化および設定します:
- Settings > Monitor > Error Tracking に移動
- Enable error tracking で Active を選択
- Error tracking backend で Sentry を選択
- Sentry API URL にSentryホスト名を入力（例: https://sentry.io）
- Auth Token に生成したトークンを入力
- Connect を選択してSentryへの接続をテストし、Project ドロップダウンリストを表示
- Project リストからSentryプロジェクトを選択
- Save changes を選択

2.4. アプリケーションへのSDK組み込み

GitLabは、以下の言語とSDKをサポートしています。

言語	テスト済みSDKクライアント	エンドポイント	サポートされるイベントタイプ
Go	`sentry-go/0.20.0`	`store`	`exception`, `message`
Java	`sentry.java:6.18.1`	`envelope`	`exception`, `message`
NodeJS	`sentry.javascript.node:7.38.0`	`envelope`	`exception`, `message`
PHP	`sentry.php/3.18.0`	`store`	`exception`, `message`
Python	`sentry.python/1.21.0`	`envelope`	`exception`, `message`, `session`
Ruby	`sentry.ruby:5.9.0`	`envelope`	`exception`, `message`
Rust	`sentry.rust/0.31.0`	`envelope`	`exception`, `message`, `session`

Pythonアプリケーションでのユーザー追跡の例です。

sentry_sdk.set_user({ email: "tanaka.taro@example.com" })

2.5. エラーの確認と対応

エラーは Monitor > Error Tracking で確認できます。エラーリストには、重要度、発生回数、影響を受けたユーザー数などが表示されます。

エラー詳細ページでは、以下の情報が表示されます。

発生回数の合計
影響を受けたユーザー数
初回検出日時とコミット
最終検出日時
時間ごとのエラー発生頻度を示す棒グラフ
スタックトレース

エラーから直接イシューを作成することも可能です。Create issue ボタンを選択すると、エラーのスタックトレースを含むイシューが自動的に作成されます。

2.6. DSNのローテーション

セキュリティ上の理由でDSNをローテーションする必要がある場合、エラートラッキングAPIを使用して新しいDSNを生成し、古いDSNを削除できます。

前提条件:

プロジェクトの数値IDが必要です
api スコープを持つパーソナルアクセストークンが必要です

2.7. データ保持期間

GitLabでは、すべてのエラーに対して90日間の保持期間が設定されています。

3. アラートとインシデント管理

GitLabのインシデント管理機能は、問題のトラブルシューティングとインシデントの協調的な解決を支援します。

3.1. アラート統合の設定

GitLabは、Webhookレシーバーを介して任意のソースからアラートを受け付けることができます。アラート通知は、オンコールローテーションのページングをトリガーしたり、インシデントの作成に使用したりできます。

3.1.1. 単一アラートエンドポイント

基本的なアラート統合の設定手順です。

前提条件:

プロジェクトに対してMaintainerロール以上が必要です

設定手順:

Settings > Monitor に移動します
Alerts セクションを展開します
Select integration type ドロップダウンリストで、Prometheusからのアラートの場合は Prometheus を、その他の監視ツールの場合は HTTP Endpoint を選択します
Active トグルをオンにします
統合を保存すると、View credentials タブでWebhook設定用のURLと認証キーが利用可能になります。これらを外部サービスに入力する必要があります

3.1.2. 複数のアラートエンドポイント（Premium/Ultimate）

Premium以上のティアでは、複数の独自のアラートエンドポイントを作成できます。各エンドポイントは、JSON形式でアラートを受信し、ペイロードをカスタマイズできます。

設定手順:

Settings > Monitor > Alerts に移動します
Add new integration を選択します
Select integration type ドロップダウンリストから統合タイプを選択し、名前を付けます
Active トグルをオンにします
オプション: 監視ツールのアラートをGitLabフィールドにマッピングするには、サンプルペイロードを入力し、Parse payload for custom mapping を選択します（有効なJSONが必要）。Prometheus統合の場合、ペイロード全体ではなく、alerts キーから単一のアラートを入力します
オプション: 有効なサンプルペイロードを提供した場合、Payload alert key の各値を選択して GitLab alert key にマッピングします
Save Integration を選択します。統合作成後、Send test alert タブからテストアラートを送信できます

3.2. アラートペイロードのカスタマイズ

カスタムマッピングを使用しないHTTPエンドポイントの場合、以下のパラメータを送信できます。すべてのフィールドはオプションです。Title フィールドの値が含まれていない場合、デフォルト値 New: Alert が適用されます。

パラメータ	型	説明
`title`	String	アラートのタイトル
`description`	String	問題の概要
`start_time`	DateTime	アラートの時刻。指定されない場合は現在時刻が使用されます
`end_time`	DateTime	アラートの解決時刻。指定された場合、アラートは解決されます
`service`	String	影響を受けたサービス
`monitoring_tool`	String	関連する監視ツールの名前
`hosts`	String or Array	インシデントが発生した1つ以上のホスト
`severity`	String	アラートの重要度。大文字小文字を区別しません。`critical`、`high`、`medium`、`low`、`info`、`unknown` のいずれか。欠落している場合またはこのリストにない値の場合、デフォルトは `critical`
`fingerprint`	String or Array	アラートの一意の識別子。同じアラートの発生をグループ化するために使用できます。`generic_alert_fingerprinting` 機能が有効な場合、フィンガープリントはペイロードに基づいて自動的に生成されます（`start_time`、`end_time`、`hosts` パラメータを除く）
`gitlab_environment_name`	String	関連するGitLab環境の名前。ダッシュボードにアラートを表示するために必要

ペイロード例:

{
  "title": "インシデントタイトル",
  "description": "インシデントの簡潔な説明",
  "start_time": "2019-09-12T06:00:55Z",
  "service": "影響を受けたサービス",
  "monitoring_tool": "監視ツール名",
  "hosts": "ホスト名",
  "severity": "high",
  "fingerprint": "d19381d4e8ebca87b55cda6e8eee7385",
  "gitlab_environment_name": "production"
}

3.3. Prometheus統合

Prometheusアラートの場合、Alertmanager設定の webhook_configs セクションに認証情報を追加します。

receivers:
  - name: gitlab
    webhook_configs:
      - http_config:
          authorization:
            type: Bearer
            credentials: 1234567890abdcdefg
        send_resolved: true
        url: http://IP_ADDRESS:PORT/root/manual_prometheus/prometheus/alerts/notify.json

Prometheusからのアラートには、以下の重要度オプションを指定できます（大文字小文字を区別しません）。

Critical: critical, s1, p1, emergency, fatal
High: high, s2, p2, major, page
Medium: medium, s3, p3, error, alert
Low: low, s4, p4, warn, warning
Info: info, s5, p5, debug, information, notice

3.4. アラートの管理

アラートリストには、Developerロール以上でアクセスできます。Monitor > Alerts から確認できます。

アラートリストでは、以下の情報が表示されます。

検索: タイトル、説明、監視ツール、サービスフィールドでの簡易テキスト検索をサポート
重要度: アラートの現在の重要性（Critical、High、Medium、Low、Info、Unknown）
開始時刻: アラートが発火してからの経過時間
アラート説明: アラートの説明
イベント数: アラートが発火した回数
イシュー: アラートに対して作成されたインシデントイシューへのリンク
ステータス: Triggered（調査未開始）、Acknowledged（調査中）、Resolved（解決済み）、Ignored（対応不要）

3.5. アラートステータスの変更

前提条件:

Developerロール以上が必要です

アラートのステータスは、以下の方法で変更できます。

アラートリストから: Status 列のドロップダウンリストから選択します
アラート詳細ページから: 右サイドバーの Edit を選択し、ステータスを選択します

メール通知が有効なプロジェクトでアラート再発のメール通知を停止するには、アラートのステータスを Triggered 以外に変更します。

3.6. アラートの自動グループ化（Premium/Ultimate）

GitLabは、ペイロードに基づいてアラートをグループ化します。受信アラートが別のアラートと同じペイロードを含む場合（start_time と hosts 属性を除く）、GitLabはこれらのアラートをグループ化し、アラート管理リストと詳細ページにカウンターを表示します。

既存のアラートがすでに resolved の場合、GitLabは代わりに新しいアラートを作成します。

3.7. リカバリーアラート

HTTPエンドポイントがアラートの終了時刻が設定されたペイロードを受信すると、GitLabのアラートは自動的に解決されます。カスタムマッピングを使用しないHTTPエンドポイントの場合、期待されるフィールドは end_time です。カスタムマッピングを使用する場合、期待されるフィールドを選択できます。

GitLabは、ペイロードの一部として提供できる fingerprint 値に基づいて、解決するアラートを決定します。

アラートが解決されたときに、関連するインシデントを自動的にクローズするように設定することもできます。

3.8. アラートからのアクション実行（Ultimate）

前提条件:

プロジェクトに対してMaintainerロール以上が必要です

アラートがトリガーされたときに自動的にインシデントを作成するように設定できます。

設定手順:

Settings > Monitor に移動します
Alerts セクションを展開し、Alert settings タブを選択します
Create an incident チェックボックスを選択します
オプション: インシデントをカスタマイズするには、Incident template からインシデントサマリーに追加するテンプレートを選択します。ドロップダウンリストが空の場合は、最初にイシューテンプレートを作成します
オプション: メール通知を送信するには、Send a single email notification to Owners and Maintainers for new alerts チェックボックスを選択します
Save changes を選択します

3.9. テストアラートのトリガー

プロジェクトのMaintainerまたはOwnerが統合を設定した後、テストアラートをトリガーして統合が正しく機能することを確認できます。

前提条件:

Developerロール以上が必要です

手順:

Settings > Monitor > Alerts に移動します
統合リストの右側にある設定アイコンを選択します
Send test alert タブを開きます
ペイロードフィールドにテストペイロードを入力します（有効なJSONが必要）
Send を選択します

GitLabは、テストの結果に応じてエラーまたは成功メッセージを表示します。

4. オンコールスケジュール管理（Premium/Ultimate）

オンコールスケジュール管理機能を使用すると、レスポンダーがオンコール責任を交代するスケジュールを作成できます。エスカレーションポリシーとオンコールスケジュールにより、問題が発生したときにチームに即座に通知され、サービスの停止や中断に迅速に対応できます。

4.1. スケジュールの作成

前提条件:

Maintainerロール以上が必要です

手順:

Monitor > On-call Schedules に移動します
Add a schedule を選択します
スケジュール名、説明、タイムゾーンを入力します
Add schedule を選択します

これで、ローテーションのない空のスケジュールが作成されます。

4.2. ローテーションの追加

スケジュールにローテーションを追加します。

手順:

Monitor > On-call Schedules に移動します
Add a rotation リンクを選択します
以下の情報を入力します:
- Name: ローテーション名
- Participants: ローテーションに参加するメンバー
- Rotation length: ローテーションの期間
- Starts on: ローテーション開始日時
- Enable end date: オンにすると終了日時を設定可能
- Restrict to time intervals: オンにすると特定の時間帯に制限可能
Save changes を選択します

スケジュールのタイムゾーンを変更すると、GitLabは自動的にローテーションの制限時間間隔（設定されている場合）を新しいタイムゾーンの対応する時刻に更新します。

4.3. スケジュールローテーションの表示

1日または2週間のオンコールスケジュールを表示できます。これらの期間を切り替えるには、スケジュールの 1 day または 2 weeks ボタンを選択します。デフォルトは2週間表示です。

スケジュール内の任意のローテーションシフト参加者にカーソルを合わせると、個々のシフトの詳細が表示されます。

5. ページングと通知

インシデントやアラートが発生した際、レスポンダーに即座に通知することが重要です。レスポンダーは、このページで説明する方法を使用して通知を受け取ることができます。

5.1. Slack通知

GitLab for Slackアプリを使用して、重要なインシデント通知を受け取ることができます。

GitLab for Slackアプリが設定されている場合、新しいインシデントが宣言されるたびに、インシデントレスポンダーにSlackで通知されます。モバイルデバイスで重要なインシデント通知を見逃さないようにするには、スマートフォンでSlackの通知を有効にします。

5.2. メール通知

プロジェクトのOwnerまたはMaintainerロールを持つメンバーは、新しいアラートに対する単一のメール通知を受け取るオプションがあります。

設定手順:

Settings > Monitor に移動します
Alerts を展開します
Alert settings タブで、Send a single email notification to Owners and Maintainers for new alerts チェックボックスを選択します
Save changes を選択します

アラートのステータスを更新して、アラートのメール通知を管理します。

5.3. ページング（Premium/Ultimate）

エスカレーションポリシーが設定されているプロジェクトでは、オンコールレスポンダーにメールで自動的にページングできます。

5.3.1. アラートのエスカレーション

アラートがトリガーされると、オンコールレスポンダーへのエスカレーションが即座に開始されます。プロジェクトのエスカレーションポリシーの各エスカレーションルールに対して、指定されたオンコールレスポンダーがルールが発火したときに1通のメールを受信します。

アラートのステータスを更新することで、ページに応答したり、アラートのエスカレーションを停止したりできます。

オンコールレスポンダーとして、アラートステータスを変更することでアラートページに応答できます。

ステータス変更の効果:

Acknowledged に変更: プロジェクトのエスカレーションポリシーに基づいてオンコールページを制限します
Resolved に変更: アラートのすべてのオンコールページをサイレンスします
Resolved から Triggered に変更: アラートのエスカレーションを再開します

5.3.2. インシデントのエスカレーション

インシデントの場合、オンコールレスポンダーへのページングは各インシデントごとにオプションです。

インシデントのエスカレーションを開始するには、インシデントのエスカレーションポリシーを設定します。

各エスカレーションルールに対して、指定されたオンコールレスポンダーがルールが発火したときに1通のメールを受信します。インシデントのステータスを変更するか、インシデントのエスカレーションポリシーを No escalation policy に戻すことで、ページに応答したり、インシデントのエスカレーションを停止したりできます。

6. インシデント管理

インシデントは、緊急に復旧する必要があるサービスの中断または停止です。GitLabを使用して、インシデントのトリアージ、対応、修復を行います。

6.1. インシデントリスト

インシデントリストには、Developerロール以上でアクセスできます。Monitor > Incidents から確認できます。

インシデントリストには、以下の情報が表示されます。

状態: Open、Closed、またはAllでフィルタリング可能
検索: タイトルと説明で検索、またはフィルタリング
重要度: Critical (S1)、High (S2)、Medium (S3)、Low (S4)、Unknown
インシデント: インシデントのタイトル
ステータス: Triggered、Acknowledged、Resolved（Premium/Ultimateティアでは、このフィールドはインシデントのオンコールエスカレーションにもリンクされています）
作成日: インシデントが作成されてからの経過時間
担当者: インシデントに割り当てられたユーザー
公開: ステータスページに公開されているかどうか

インシデントリストは、デフォルトでインシデント作成日でソートされ、最新のものが最初に表示されます。別の列でソートするか、ソート順を変更するには、列を選択します。

ソート可能な列: 重要度、ステータス、Time to SLA、公開

6.2. インシデント詳細

インシデント詳細ページには、以下のセクションがあります。

6.2.1. サマリー

サマリーセクションには、インシデントに関する重要な詳細とイシューテンプレートの内容（選択されている場合）が表示されます。

上部のハイライトバーには、左から右に以下が表示されます。

元のアラートへのリンク
アラート開始時刻
イベント数

ハイライトバーの下のサマリーには、以下のフィールドが含まれます。

開始時刻
重要度
full_query
監視ツール

インシデントサマリーは、GitLab Flavored Markdownを使用してさらにカスタマイズできます。

アラートから作成されたインシデントがインシデント用のMarkdownを提供した場合、そのMarkdownがサマリーに追加されます。プロジェクトにインシデントテンプレートが設定されている場合、テンプレートの内容が最後に追加されます。

コメントはスレッドで表示されますが、最近の更新ビューをオンにすることで時系列で表示できます。

インシデントに変更を加えると、GitLabはシステムノートを作成し、サマリーの下に表示します。

6.2.2. メトリクス（Premium/Ultimate）

多くの場合、インシデントはメトリクスに関連付けられています。Metrics タブでメトリクスチャートのスクリーンショットをアップロードできます。

画像をアップロードする方法:

upload を選択してファイルブラウザから画像を選択します
ファイルブラウザからファイルをドラッグしてドロップゾーンにドロップします

画像をアップロードする際、画像にテキストを追加し、元のグラフにリンクできます。リンクを追加すると、アップロードされた画像の上に表示されます。

6.2.3. アラート詳細

インシデントは、リンクされたアラートの詳細を別のタブに表示します。このタブを表示するには、インシデントがリンクされたアラートとともに作成されている必要があります。アラートから自動的に作成されたインシデントには、このフィールドが入力されています。

6.2.4. タイムラインイベント

インシデントタイムラインは、インシデント中に何が起こったか、そして解決のためにどのような手順が取られたかの概要を提供します。

6.2.5. 最近の更新ビュー（Premium/Ultimate）

インシデントの最新の更新を確認するには、コメントバーの Turn recent updates view on を選択します。コメントはスレッド化されず、時系列で新しいものから古いものへと表示されます。

6.3. SLAカウントダウンタイマー（Premium/Ultimate）

顧客と締結しているSLAを追跡するために、インシデントにSLAカウントダウンタイマーを有効にできます。タイマーはインシデントが作成されると自動的に開始され、SLA期間が終了するまでの残り時間を表示します。タイマーは15分ごとに動的に更新されるため、ページを更新して残り時間を確認する必要はありません。

前提条件:

プロジェクトに対してMaintainerロール以上が必要です

設定手順:

Settings > Monitor に移動します
Incidents セクションを展開し、Incident settings タブを選択します
Activate "time to SLA" countdown timer を選択します
15分単位で制限時間を設定します
Save changes を選択します

SLAカウントダウンタイマーを有効にすると、インシデントリストに Time to SLA 列が利用可能になり、新しいインシデントのフィールドとして表示されます。SLA期間が終了する前にインシデントがクローズされない場合、GitLabはインシデントに missed::SLA ラベルを追加します。

6.4. インシデントの作成と管理

インシデントは、以下の方法で作成できます。

手動でインシデントを作成
アラートから自動的にインシデントを作成（アラートがトリガーされたときに自動的にインシデントを作成するように設定）

インシデントに対して実行できるアクション:

ユーザーに割り当て
インシデントの重要度を変更
インシデントのステータスを変更
エスカレーションポリシーを変更
インシデントをクローズ
リカバリーアラート経由でインシデントを自動的にクローズ

リンクされたインシデントをクローズすると、GitLabはアラートのステータスを Resolved に変更します。

7. ステータスページ（Ultimate）

GitLabステータスページを使用すると、インシデント中にユーザーに効率的に情報を伝えるための静的Webサイトを作成およびデプロイできます。ステータスページのランディングページには、最近のインシデントの概要が表示されます。

インシデントを選択すると、特定のインシデントに関する詳細情報を含む詳細ページが表示されます。

インシデントのステータス（最終更新日時を含む）
インシデントのタイトル（絵文字を含む）
インシデントの説明（絵文字を含む）
インシデントの説明またはコメントに添付されたファイル（有効な画像拡張子を持つもの）
インシデントの更新の時系列リスト

7.1. ステータスページのセットアップ

ステータスページを設定するには、以下を実行する必要があります。

クラウドプロバイダー情報でGitLabを設定
AWSアカウントを設定
GitLabでステータスページプロジェクトを作成
ステータスページにインシデントを同期

7.1.1. クラウドプロバイダー情報でGitLabを設定

現在、デプロイターゲットとしてサポートされているのはAWS S3のみです。

前提条件:

Maintainerロール以上が必要です

ステータスページにコンテンツをプッシュするために必要なAWSアカウント情報をGitLabに提供します。

手順:

Settings > Monitor に移動します
Status page を展開します
Active チェックボックスを選択します
Status Page URL ボックスに、外部ステータスページのURLを入力します
S3 Bucket name ボックスに、S3バケットの名前を入力します
AWS region ボックスに、バケットのリージョンを入力します
AWS access key ID と AWS Secret access key を入力します
Save changes を選択します

7.1.2. AWSアカウントの設定

AWSアカウント内で、以下のファイルを例として使用して2つの新しいIAMポリシーを作成します:
- バケット作成ポリシー
- バケットコンテンツ更新ポリシー（S3_BUCKET_NAME をバケット名に置き換えることを忘れないでください）
最初のステップで作成した権限ポリシーを持つ新しいAWSアクセスキーを作成します

7.1.3. ステータスページプロジェクトの作成

AWSアカウントを設定した後、ステータスページプロジェクトを追加し、ステータスページをAWS S3にデプロイするために必要なCI/CD変数を設定する必要があります。

手順:

ステータスページプロジェクトをフォークします（リポジトリミラーリングを使用して、最新のステータスページ機能を確実に取得できます）
Settings > CI/CD に移動します
Variables を展開します
Amazon Consoleから以下の変数を追加します:
- S3_BUCKET_NAME: Amazon S3バケットの名前。指定された名前のバケットが存在しない場合、最初のパイプライン実行時に作成され、静的Webサイトホスティング用に設定されます
- AWS_DEFAULT_REGION: AWSリージョン
- AWS_ACCESS_KEY_ID: AWSアクセスキーID
- AWS_SECRET_ACCESS_KEY: AWSシークレット
Build > Pipelines に移動します
ステータスページをS3にデプロイするには、New pipeline を選択します

注意: このプロジェクトのイシューにアクセスできるユーザーを制限することを検討してください。インシデントを表示できるユーザーは、GitLabステータスページにコメントを公開できる可能性があります。

7.1.4. ステータスページへのインシデント同期

CI/CD変数を作成した後、インシデントに使用するプロジェクトを設定します。

手順:

Settings > Monitor に移動します
Status page を展開します
クラウドプロバイダーの認証情報を入力し、Active チェックボックスを選択します
Save changes を選択します

7.2. GitLabステータスページの使用方法

GitLabインスタンスを設定すると、関連する更新によってバックグラウンドジョブがトリガーされ、インシデントに関するJSON形式のデータが外部クラウドプロバイダーにプッシュされます。ステータスページWebサイトは定期的にこのJSON形式のデータを取得し、フォーマットしてユーザーに表示します。

7.2.1. インシデントの公開

インシデントを公開するには:

ステータスページ設定を有効にしたプロジェクトでインシデントを作成します
プロジェクトまたはグループのOwnerが /publish クイックアクションを使用してインシデントを公開します（機密インシデントは公開できません）

バックグラウンドワーカーが、設定時に提供した認証情報を使用してステータスページにインシデントを公開します。公開の一環として、GitLabは以下を実行します。

ユーザーとグループのメンションを Incident Responder で匿名化
非公開GitLab参照のタイトルを削除
インシデント説明に添付されたファイルを公開（インシデントあたり最大5000ファイル）

公開後、インシデントのタイトルの下に表示される Published on status page ボタンを選択して、インシデントの詳細ページにアクセスできます。

7.2.2. インシデントの更新

インシデントの更新を公開するには、インシデントの説明を更新します。

注意: 参照されたインシデントが変更された場合（タイトルや機密性など）、それらが参照されたインシデントは更新されません。

7.2.3. インシデントへのコメント公開

ステータスページインシデントにコメントを公開するには:

インシデントにコメントを作成します
コメントを公開する準備ができたら、マイク絵文字リアクション（:microphone: 🎤）をコメントに追加してコメントを公開用にマークします
コメントに添付されたファイル（インシデントあたり最大5000ファイル）も公開されます

注意: インシデントを表示するアクセス権を持つユーザーは誰でもコメントに絵文字リアクションを追加できるため、イシューへのアクセスをチームメンバーのみに制限することを検討してください。

7.2.4. インシデントステータスの更新

インシデントのステータスを open から closed に変更するには、GitLab内でインシデントをクローズします。インシデントをクローズすると、バックグラウンドワーカーがトリガーされ、GitLabステータスページWebサイトが更新されます。

公開されたインシデントを機密にすると、GitLabはGitLabステータスページWebサイトから非公開にします。

8. Insightsダッシュボード（Ultimate）

Insightsは、月ごとのアイテム数（作成されたバグなど）を表示するインタラクティブな棒グラフです。

プロジェクトとグループのInsightsを設定して、以下のようなデータを探索するカスタムレポートを作成できます。

指定期間中に作成およびクローズされたイシュー
マージリクエストがマージされるまでの平均時間
トリアージの衛生状態

8.1. Insightsの表示

前提条件:

プロジェクトInsightsの場合、プロジェクトへのアクセス権と、マージリクエストとイシューに関する情報を表示する権限が必要です
グループInsightsの場合、グループを表示する権限が必要です

手順:

Analyze > Insights に移動します
Select report ドロップダウンリストから表示するレポートを選択します
注釈を表示するには、チャートの各バーにカーソルを合わせます
オプション: 結果をフィルタリングします:
- 90日間の範囲のサブセットのみからデータを表示するには、一時停止アイコンを選択して水平軸に沿ってスライドします
- チャートから次元を除外するには、チャートの下の凡例から次元名を選択します

8.1.1. チャートのドリルダウン

query.data_source が issuables であるすべてのチャートのデータにドリルダウンできます。

特定の月の特定の優先度または重要度のデータのドリルダウンレポートを表示するには、チャート上でドリルダウンするバースタックを選択します。

8.1.2. レポートディープリンクの作成

レポートキーをInsightsレポートURLの末尾に追加することで、ユーザーをInsightsの特定のレポートに誘導できます。

8.2. Insightsの設定

プロジェクトのルートディレクトリに .gitlab/insights.yml ファイルを作成します。プロジェクトに設定ファイルがない場合、グループ設定を使用します。

.gitlab/insights.yml ファイルは、以下を定義するYAMLファイルです。

レポート内のチャートの構造と順序
プロジェクトまたはグループのレポートに表示されるチャートのスタイル

.gitlab/insights.yml ファイルでは:

設定パラメータがチャートの動作を定義します
各レポートには一意のキーと、取得および表示するチャートのコレクションがあります
各チャート定義は、キーと値のペアで構成されるハッシュで構成されます

8.2.1. 設定例

単一の定義を示す例（1つのチャートを含むレポートを表示）:

bugsCharts:
  title: "バグのチャート"
  charts:
    - title: "月次作成バグ数"
      description: "月ごとに作成されたオープンバグ"
      type: bar
      query:
        data_source: issuables
        params:
          issuable_type: issue
          issuable_state: opened
          filter_labels:
            - bug
          group_by: month
          period_limit: 24

3つのチャートを表示する完全な設定例:

.projectsOnly: &projectsOnly
  projects:
    only:
      - 3
      - groupA/projectA
      - groupA/subgroupB/projectC

bugsCharts:
  title: "バグのチャート"
  charts:
    - title: "月次作成バグ数"
      description: "月ごとに作成されたオープンバグ"
      type: bar
      <<: *projectsOnly
      query:
        data_source: issuables
        params:
          issuable_type: issue
          issuable_state: opened
          filter_labels:
            - bug
          group_by: month
          period_limit: 24

    - title: "週次重要度別バグ"
      type: stacked-bar
      <<: *projectsOnly
      query:
        data_source: issuables
        params:
          issuable_type: issue
          issuable_state: opened
          filter_labels:
            - bug
          collection_labels:
            - S1
            - S2
            - S3
            - S4
          group_by: week
          period_limit: 104

    - title: "月次チーム別バグ"
      type: line
      <<: *projectsOnly
      query:
        data_source: issuables
        params:
          issuable_type: merge_request
          issuable_state: opened
          filter_labels:
            - bug
          collection_labels:
            - Manage
            - Plan
            - Create
          group_by: month
          period_limit: 24

8.2.2. 設定パラメータ

チャートパラメータ:

キーワード	説明
`title`	チャートのタイトル。Insightsページに表示されます
`description`	個々のチャートの説明。関連するチャートの上に表示されます
`type`	チャートのタイプ: `bar`、`line`、または `stacked-bar`
`query`	チャートのデータソースとフィルタリング条件を定義するハッシュ

query パラメータでは、data_source を定義してデータを公開するデータソースを指定します。

サポートされる値:

issuables: マージリクエストまたはイシューデータを公開
dora: DORAメトリクスを公開

8.3. DORAメトリクスの可視化

DORAメトリクスをInsightsで可視化することもできます。

dora:
  title: "DORAチャート"
  charts:
    - title: "DORAデプロイ頻度"
      type: bar
      query:
        data_source: dora
        params:
          metric: deployment_frequency
          group_by: day
          period_limit: 10
      projects:
        only:
          - 38
    - title: "DORA変更のリードタイム"
      description: "DORA変更のリードタイム"
      type: bar
      query:
        data_source: dora
        params:
          metric: lead_time_for_changes
          group_by: day
          environment_tiers:
            - staging
          period_limit: 30

DORAクエリパラメータ:

query.metric: クエリするDORAメトリクスを定義（deployment_frequency、lead_time_for_changes、time_to_restore_service、change_failure_rate）
query.group_by: チャートのX軸を定義（day または month）
query.period_limit: メトリクスを過去にどれだけ遡ってクエリするかを定義（デフォルト: 15、最大: 180日または6ヶ月）
query.environment_tiers: 計算に含める環境の配列を定義（production、staging、testing、development、other）

8.4. プロジェクトとグループのInsights設定

8.4.1. プロジェクトのInsights設定

前提条件:

プロジェクトに対してDeveloperロール以上が必要です

プロジェクトInsightsを設定するには、プロジェクトのルートディレクトリに .gitlab/insights.yml ファイルを作成します。

ローカルで作成してプッシュ
UIから作成: Code > Repository > Files > + > New file を選択し、ファイル名に .gitlab/insights.yml を入力

8.4.2. グループのInsights設定

前提条件:

グループ内のプロジェクトに .gitlab/insights.yml ファイルが必要です

グループInsightsを設定するには:

Settings > Analytics に移動します
Insights セクションで、.gitlab/insights.yml 設定ファイルを含むプロジェクトを選択します
Save changes を選択します

注意: カスタム .gitlab/insights.yml ファイルはデフォルト設定を上書きします。元の設定を保持するには、デフォルト設定ファイルの内容をベースとしてコピーします。

9. 実行可能なRunbook

Runbookは、特定のプロセス（システムの起動、停止、デバッグ、トラブルシューティングなど）の実行方法を説明する文書化された手順の集合です。

Jupyter NotebooksとRubixライブラリを使用して、独自の実行可能なRunbookを作成できます。

従来、Runbookは条件やシステムに応じて決定木または詳細なステップバイステップガイドの形式を取っていました。

最近の実装では、「実行可能なRunbook」の概念が導入されています。明確に定義されたプロセスとともに、オペレーターは特定の環境に対して事前に記述されたコードブロックやデータベースクエリを実行できます。

9.1. 実行可能なRunbook

GitLab Kubernetes統合で提供されるJupyterHubアプリには、Nurtch社のRubixライブラリが同梱されており、DevOps Runbookを簡単に作成できます。サンプルRunbookが提供されており、一般的な操作を紹介しています。Rubixを使用すると、一般的なKubernetesおよびAWSワークフローを簡単に作成できますが、Rubixなしで手動で作成することもできます。

9.2. Runbookの要件

実行可能なRunbookを作成するには、以下が必要です。

Kubernetes: 残りのアプリケーションをデプロイするためにKubernetesクラスターが必要です。最も簡単に始める方法は、GitLab agent for Kubernetesを使用してクラスターを接続することです
Ingress: Ingressは、ロードバランシング、SSL終端、名前ベースの仮想ホスティングを提供できます。アプリケーションのWebプロキシとして機能します
JupyterHub: JupyterHubは、チーム全体でノートブックを管理するマルチユーザーサービスです。Jupyter Notebooksは、データ分析、可視化、機械学習に使用されるWebベースのインタラクティブプログラミング環境を提供します

9.3. Nurtch

Nurtch社は、Rubixライブラリの開発元です。Rubixは、Jupyter Notebooks内で一般的なDevOpsタスクを簡単に実行できるオープンソースのPythonライブラリです。Cloudwatchメトリクスのプロット、ECS/Kubernetesアプリのローリングなどのタスクが、数行のコードに簡素化されます。詳細については、Nurtchドキュメントを参照してください。

9.4. GitLabでの実行可能なRunbookの設定

前述のコンポーネントと事前ロードされたデモRunbookを使用して、GitLabで実行可能なRunbookを設定するステップバイステップガイドに従います。

JupyterHub用のOAuthアプリケーションを作成します
HelmでJupyterHubをインストールする際、以下の値を使用します:

hub:
  config:
    GitLabOAuthenticator:
      # 特定のプロジェクト、グループ、またはユーザーへのアクセスを制限:
      # allowedGitlabGroups: [ "my-group-1", "my-group-2" ]
      # allowedProjectIds: [ 12345, 6789 ]
      # allowed_users: ["user-1", "user-2"]
      client_id: <Your OAuth Application ID>
      client_secret: <Your OAuth Application Secret>
      enable_auth_state: true
      gitlab_url: https://gitlab.example.com
      oauth_callback_url: http://<Jupyter Hostname>/hub/oauth_callback
      scope:
        - read_user
        - read_api
        - openid
        - profile
        - email
    JupyterHub:
      authenticator_class: gitlab
  extraConfig:
    gitlab-config: |-
      c.KubeSpawner.cmd = ['jupyter-labhub']
      c.GitLabOAuthenticator.scope = ['api read_repository write_repository']

      async def add_auth_env(spawner):
         '''
         JupyterHubのリポジトリ統合を有効にするために、
         シングルユーザーイメージにユーザーのID、ログイン、アクセストークンを設定します。
         '''
         auth_state = await spawner.user.get_auth_state()

         if not auth_state:
            spawner.log.warning("No auth state for %s", spawner.user)
            return

         spawner.environment['GITLAB_ACCESS_TOKEN'] = auth_state['access_token']
         spawner.environment['GITLAB_USER_EMAIL'] = auth_state['gitlab_user']['email']
         spawner.environment['GITLAB_USER_ID'] = str(auth_state['gitlab_user']['id'])
         spawner.environment['GITLAB_USER_LOGIN'] = auth_state['gitlab_user']['username']
         spawner.environment['GITLAB_USER_NAME'] = auth_state['gitlab_user']['name']

      c.KubeSpawner.pre_spawn_hook = add_auth_env

singleuser:
  defaultUrl: "/lab"
  image:
    name: registry.gitlab.com/gitlab-org/jupyterhub-user-image
    tag: latest
  lifecycleHooks:
    postStart:
      exec:
        command:
          - "sh"
          - "-c"
          - >
            git clone https://gitlab.com/gitlab-org/nurtch-demo.git DevOps-Runbook-Demo || true;
            echo "https://oauth2:${GITLAB_ACCESS_TOKEN}@${GITLAB_HOST}" > ~/.git-credentials;
            git config --global credential.helper store;
            git config --global user.email "${GITLAB_USER_EMAIL}";
            git config --global user.name "${GITLAB_USER_NAME}";
            jupyter serverextension enable --py jupyterlab_git

proxy:
  service:
    type: ClusterIP

JupyterHubが正常にインストールされたら、ブラウザで Jupyter Hostname を開きます。Sign in with GitLab ボタンを選択してJupyterHubにサインインし、サーバーを起動します。GitLabインスタンスのすべてのユーザーに対してOAuth2で認証が有効になっています。このボタンをクリックすると、JupyterHubがGitLabアカウントを使用することを承認するよう求めるGitLabのページにリダイレクトされます
Authorize を選択すると、GitLabはJupyterHubアプリケーションにリダイレクトします
Start My Server を選択すると、数秒でサーバーが起動します
GitLabプロジェクトへのRunbookのアクセスを設定するには、デモRunbookの Setup セクションにGitLabアクセストークンとプロジェクトIDを入力する必要があります:
1. 左パネルにある DevOps-Runbook-Demo フォルダを選択します
2. Nurtch-DevOps-Demo.ipynb Runbookを選択します
3. Jupyterは画面の右側にRunbookの内容を表示します。Setup セクションに PRIVATE_TOKEN と PROJECT_ID が表示されます。これらの値を入力し、シングルクォートを維持します:
```
PRIVATE_TOKEN = '<your_access_token>'
PROJECT_ID = '1234567'
```
4. このセクションの最後の行の VARIABLE_NAME を、アクセストークンに使用している変数の名前と一致するように更新します。この例では、変数名は PRIVATE_TOKEN です:
```
VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value
```
Runbookの操作を設定するには、変数を作成および設定します。この例では、サンプルRunbookの Run SQL queries in Notebook セクションを使用してPostgreSQLデータベースをクエリします。次のコードブロックの最初の4行は、このクエリが機能するために必要な変数を定義します:
```
%env DB_USER={project.variables.get('DB_USER').value}
%env DB_PASSWORD={project.variables.get('DB_PASSWORD').value}
%env DB_ENDPOINT={project.variables.get('DB_ENDPOINT').value}
%env DB_NAME={project.variables.get('DB_NAME').value}
```
1. Settings > CI/CD > Variables に移動して、プロジェクトに変数を作成します
2. Save variables を選択します
3. Jupyterで、Run SQL queries in Notebook 見出しを選択し、Run を選択します。結果はインラインで表示されます

シェルスクリプトの実行やKubernetesクラスターとの対話など、他の操作を試すことができます。詳細については、Nurtchドキュメントを参照してください。

10. まとめ

GitLabの監視機能を活用することで、以下のような包括的な運用体制を構築できます。

エラートラッキング: Sentry SDKを使用してアプリケーションエラーを自動収集し、GitLab統合型（GitLab.com）またはSentryベース（すべての環境）で一元管理します。90日間のデータ保持により、エラーの傾向分析も可能です。
アラート管理: Webhookを介して任意の監視ツール（Prometheus、その他のHTTPエンドポイント）からアラートを受信し、重要度やステータスで管理します。Premium以上では複数のアラートエンドポイントを設定でき、カスタムフィールドマッピングも可能です。同一ペイロードのアラートは自動的にグループ化され、リカバリーアラートによる自動解決もサポートされています。
オンコール体制: スケジュールとローテーションを設定し、エスカレーションポリシーに基づいて自動的にオンコール担当者にメールで通知します。Slack通知も利用可能です。
インシデント対応: アラートから自動的にインシデントを作成し（Ultimate）、タイムラインイベントで対応履歴を記録します。SLAタイマー（Premium/Ultimate）で対応時間を追跡でき、SLA期間を超過すると自動的に missed::SLA ラベルが追加されます。
ステータスページ: インシデント情報を外部ユーザーに公開するための静的Webサイトを自動生成します（Ultimate）。AWS S3にデプロイされ、インシデントの公開、更新、コメントの公開が可能です。
分析とレポート: Insightsダッシュボード（Ultimate）でインシデントやエラーの傾向を可視化し、継続的な改善に活用します。DORAメトリクスの可視化もサポートされています。
自動化: Jupyter NotebooksとRubixライブラリを使用して実行可能なRunbookを作成し、オンコールエンジニアが自律的にインシデントを修復できるようにします。

これらの機能を組み合わせることで、コードの開発から運用まで、GitLab上で完結する効率的なDevOpsワークフローを実現できます。監視データがコードと同じ場所に集約されることで、開発者の効率と意識が向上し、より迅速な問題解決が可能になります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up