ステージングモニタリング
ステージング環境のモニタリング方法とトラフィック生成方法
GitLab.com のモニタリング
GitLab.com サービス可用性
GitLab.com の可用性は顧客ごとにモニタリングされています。顧客のダウンタイムを判定するための方法論は、サービスレベル契約に文書化されています。 このページに記録されている可用性は、選択されたサービスの指標を使用して測定されています。これはカバードエクスペリエンスだけでなく、エラーとレイテンシの両方を対象としています。これは SLA に記載されているものとは異なります。これらの数値は内部的に使用されます。
このページでは、GitLab.com を内部的にモニタリングするために使用しているツールについて説明します。 GitLab.com サービス可用性定義の計算方法論は、モニタリングポリシー にあります。
障害や劣化の定義に関する詳細は、インシデント管理ページ にあります。
サービス可用性の履歴
| 年月 | 可用性 | コメント |
|---|---|---|
| 2026年6月 | 99.91% | |
| 2026年5月 | 99.47% | |
| 2026年4月 | 99.31% | |
| 2026年3月 | 99.93% | |
| 2026年2月 | 99.95% | |
| 2026年1月 | 100.00% | |
| 2025年12月 | 99.99% | |
| 2025年11月 | 99.98% | |
| 2025年10月 | 99.95% | |
| 2025年9月 | 100.00% | |
| 2025年8月 | 100.00% | |
| 2025年7月 | 99.91% | |
| 2025年6月 | 99.84% | |
| 2025年5月 | 99.73% | |
| 2025年4月 | 99.97% | |
| 2025年3月 | 100.00% | |
| 2025年2月 | 99.99% | |
| 2025年1月 | 99.98% | |
| 2024年12月 | 99.95% | |
| 2024年11月 | 100.00% | |
| 2024年10月 | 99.66% | |
| 2024年9月 | 99.85% | |
| 2024年8月 | 100.00% | |
| 2024年7月 | 99.99% | |
| 2024年6月 | 99.99% | |
| 2024年5月 | 100.00% | |
| 2024年4月 | 99.96% | |
| 2024年3月 | 100% | |
| 2024年2月 | 99.86% | |
| 2024年1月 | 100% | |
| 2023年12月 | 99.99% | |
| 2023年11月 | 99.99% | |
| 2023年10月 | 99.89 | 10月30日 Sev 1 |
| 2023年9月 | 99.98% | |
| 2023年8月 | 100% | |
| 2023年7月 | 99.78% | 2件の Severity 1 インシデントがサービス障害の約94%を占めました。 2023-07-07, 2023-07-14 |
| 2023年6月 | 100% | |
| 2023年5月 | 99.92% | |
| 2023年4月 | 99.98% | |
| 2023年3月 | 99.99% | |
| 2023年2月 | 99.98% | |
| 2023年1月 | 99.80% | |
| 2022年12月 | 100% | |
| 2022年11月 | 99.86% | |
| 2022年10月 | 100% | |
| 2022年9月 | 99.98% | |
| 2022年8月 | 99.92% | |
| 2022年7月 | 99.95% | |
| 2022年6月 | 99.96% | |
| 2022年5月 | 99.99% | |
| 2022年4月 | 99.98% | |
| 2022年3月 | 99.91% | |
| 2022年2月 | 99.87% | |
| 2022年1月 | 99.95% | |
| 2021年12月 | 99.96% | |
| 2021年11月 | 99.71% | |
| 2021年10月 | 99.98% | |
| 2021年9月 | 99.85% | |
| 2021年8月 | 99.86% | |
| 2021年7月 | 99.78% | |
| 2021年6月 | 99.84% | |
| 2021年5月 | 99.85% | PostgreSQL 12 アップグレード の手動調整は含まれていません |
| 2021年4月 | 99.98% | |
| 2021年3月 | 99.34% | |
| 2021年2月 | 99.87% | |
| 2021年1月 | 99.88% | |
| 2020年12月 | 99.96% | |
| 2020年11月 | 99.90% | |
| 2020年10月 | 99.74% | |
| 2020年9月 | 99.95% | |
| 2020年8月 | 99.87% | |
| 2020年7月 | 99.81% | |
| 2020年6月 | 99.56% | |
| 2020年5月 | 99.58% |
関連ページ
関連動画
これらの動画は、サーバー、ネットワーク、データベース、セキュリティ、パフォーマンスに関連する障害、欠陥、問題を素早く特定する方法の例を提供します。
- モニタリングツールプレイリスト (GitLab Unfiltered YouTube アカウントへのアクセス権が必要)
- 可視化ツールプレイリスト (GitLab Unfiltered YouTube アカウントへのアクセス権が必要)
モニタリング
Pingdom 統計
公式の可用性を報告するには apdex ベースの測定を使用します(上記参照)。ただし、GitLab.com の全体的なパフォーマンスを代表する観点で、いくつかの公開 Pingdom テストもあります。これらは https://stats.pingdom.com で利用できます。具体的には、次のものへの到達可用性とレイテンシを持っています。
- GitLab.com の Issue。参考までに、これは 最初の gitlab-ce Issue です。
- GitLab.com は「シンプルで分かりやすい」もので、GitLab パブリックチェック と呼ばれます。
モニタリングインフラストラクチャ
メトリクスの取り込みとクエリには Grafana Mimir を使用しています。Mimir は Prometheus を拡張したオープンソースの分散時系列データベースです。実装の詳細は Runbook ドキュメント で読むことができます。
モニタリングダッシュボード
メトリクスは Grafana で表示できます。Grafana の Explore ダッシュボードでは、PromQL を使って Mimir 内のすべてのデータをクエリできます。
- アクセスには Google SSO 経由の
@gitlab.comメールアドレスが必要です - 高可用性セットアップ
- アラートはこのセットアップから供給されます
- コンプライアンス、セキュリティ、可用性の理由から、パブリックとは分離されています
ダッシュボードの追加
Grafana を使った新しいグラフまたはダッシュボードのセットアップ方法を学ぶには、次のリソースをご覧ください。
- Grafana ダッシュボードのセットアップガイド (Grafana 提供)
- ダッシュボードのセットアップ方法を示す YouTube 動画
- Grafana で作成された InfluxDB ダッシュボードのアーカイブを保管している Grafana リポジトリ。ファイル構造の詳細を確認するのに使用しますが、このリポジトリは実際にはアーカイブであり (そこから何かが取り込まれることはない)、古くなっている可能性があることに注意してください。
ダッシュボードを追加するためのアクセスが必要ですか? インフラストラクチャチーム 内のチームリードに尋ねてください。
ステージグループ向けダッシュボード
各ステージグループ 向けに設計された一連のモニタリングダッシュボードがあります。これらのダッシュボードは、特定のフィーチャーカテゴリーで働くすべての人に、コードが GitLab.com スケールでどのように動作するかについてのインサイトを提供するように設計されています。ステージグループごとにグループ化され、フィーチャー／コード変更、デプロイ、フィーチャーフラグの切り替えの影響を示します。
ステージグループ向けダッシュボードは非常に初期段階です。すべてのコントリビューションを歓迎します。質問や提案がありましたら、Scalability チームの Issue トラッカー に Issue を作成してください。
モニタリングから役立つダッシュボードのセレクション
ブラックボックスモニタリング
- GitLab Web ステータス: GitLab のフロントエンドの観点。GitLab.com がユーザーの観点からどのように見えるかを理解するのに便利。GitLab のどの部分が遅いかをすばやくトラブルシューティングするには、このグラフを使用してください。
- GitLab Git ステータス: GitLab の ssh アクセスのフロントエンド観点。
プライベートホワイトボックスモニター
- Host Stats: 特定のホストの状況を深く掘り下げるのに便利。上部のドロップダウンからホストを選択します。
- Business Stats: プッシュ、新規リポジトリ、CI ビルドの数を表示します。
- Daily overview: 呼び出し数とパフォーマンスメトリクスを持つエンドポイントを表示します。何が遅いかを一般的に理解するのに便利。
ログ
ネットワーク、システム、アプリケーションのログは、ELK スタック を使用して処理、保存、検索されます。私たちは GCP 上のマネージド Elasticsearch クラスター を使用しており、API、Kibana、および elastic.co の Web UI を通じてのみインタラクトできます。システムのパフォーマンスとメトリクスのモニタリングには、Elastic の x-pack モニタリングメトリクスを使用しています。これらは専用のモニタリングクラスターに送信されます。長期的には、好ましいインターフェースとして Prometheus と Grafana に切り替える予定です。Elastic がマネージドするため、彼らが VM を運用し、私たちはそれらにアクセスできません。ただし、エラーやインシデントを調査するために、生のログは Kibana 経由で利用できます。 ステージングのログは別の Kibana インスタンス経由で利用できます。
Kibana ダッシュボードは、アプリケーションのアクティビティ、スパムイベント、一時的なエラー、システムおよびネットワークの認証イベント、セキュリティイベントなどをモニターするために使用されます。よく使われるダッシュボードは、Abuse、SSH、Rack Attack ダッシュボードです。
私たちのインフラストラクチャをどのようにログ記録しているかは、私たちの runbook で概説されているとおり閲覧できます。
ログ管理に関連するポリシーは [the monitoring policy] にあります。
ダッシュボードの追加
Kibana ダッシュボードの作成方法を学ぶには、次のリソースを使用してください。
GitLab プロファイリング
Go サービス
Stackdriver Continuous Go Profiling を使用して、Go サービスのパフォーマンスとリソース消費をより理解できます。 (Google Workspace の stackdriver-profiler-sg グループのメンバーシップが必要)
GCP 上に CPU とメモリ使用量のデータを表示するシンプルな UI を提供します:
詳細については、短い動画チュートリアル が利用可能です。
また、この Issue で各プロジェクトの開発チームとペアリングして一連のディープダイブを実施し、次の動画が作成されました。
パフォーマンス計測のための Ruby インストルメンテーション
Ruby コードのブロックを「インストルメント」してパフォーマンスを測定できます。
- インストルメンテーションのドキュメント と その実装方法の詳細
- GitLab 自体でこれがどのように使用されているかの例は、この initializer にあります。
その他のツール
Sentry
エラートラッキングサービス。
グループ向けの Sentry アラート設定
アラートルールを作成すると、グループが自身のフィーチャーをモニターし、問題をプロアクティブにキャッチするのに役立ちます。これにより、エラー予算 SLO を侵害する前に問題を修正でき、結果として GitLab.com のサービス可用性を高く保つのに役立ちます。
アラートを作成する手順:
- Sentry の アラートルールダッシュボード にアクセスします。
- 右上の「Create Alert」ボタンをクリックします。
- グループのフィーチャーカテゴリーに合わせて必要な条件を設定します。
- 次の命名規則 “g_group_name_alerts” で新しいパブリック Slack チャンネルを作成します。例: #g_govern_compliance_alerts
- このチャンネルをアラート通知の送信先に選択します。
- 新しいアラートがあればグループを監視し、解決に向けて作業します。
Sitespeed.io
ウェブサイトの速度とパフォーマンスをモニター、分析、最適化するのを助けるツール。
最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (
c955a93f)