ようこそ、エンジニアの世界へ。今日は、GitLabという巨大なプラットフォームをただ「コード置き場」として使うのではなく、その「心拍数」を読み解く術を伝授しましょう。
開発が順調な時はいい。しかし、チームが拡大し、コードベースが肥大化すると、必ず「なぜかGitLabの画面が重い」「CIが走り出すまでが遅い」という壁にぶつかります。その時、多くの人は「サーバーのスペックを上げよう」と考えますが、それは素人のやり方です。
「どこが」ボトルネックなのか。 これを正確に特定し、メスを入れるのがプロのDevOpsエンジニアの仕事です。今日はGitLabの奥底にある「パフォーマンス監視」の扉を開きましょう。
—
1. なぜ「GitLab Performance Monitoring」が必要なのか？
GitLabはRuby on Railsで書かれた巨大なアプリケーションです。Webリクエストがどこで止まっているのか（DBのクエリか、外部APIの呼び出しか、あるいはRubyのGCか）、勘で当てるのは不可能です。
GitLabには、Prometheusという時系列データベースと連携して、実行時のメトリクス（処理時間、メモリ使用量、DBクエリ時間など）を可視化する機能が標準で備わっています。これを使えば、「どのAPIエンドポイントが、どのSQLで時間を溶かしているか」が手に取るように分かります。
—
2. ステップ1：監視の心臓部「Prometheus」を起動する
GitLabのパフォーマンス監視を有効にするには、まずはPrometheusが動いている必要があります。Omnibus版（パッケージ版）を使っているなら、設定は一瞬です。
`/etc/gitlab/gitlab.rb` を開き、以下の設定を確認（または追記）してください。
Prometheusを有効化（デフォルトでtrueですが念のため）
prometheus[‘enable’] = true
GitLab自体のパフォーマンス監視用エクスポートを有効化
gitlab_exporter[‘enable’] = true
監視データの保持期間（運用に合わせて調整）
prometheus[‘retention’] = ’15d’
設定を反映させます。
sudo gitlab-ctl reconfigure
これで、GitLabは自身の内部メトリクスをPrometheusへ流し込み始めます。
—
3. ステップ2：エンドポイントを特定する（HelloWorld的アプローチ）
監視が動いているか確認するために、まずは「今のGitLabがどう動いているか」を数値で見てみましょう。
GitLabは内部的に、Prometheusフォーマットでメトリクスを公開しています。以下のコマンドをサーバー内で実行してみてください。
GitLabのエクスポートデータを確認
curl http://localhost:9090/metrics | grep “gitlab_transaction_duration_seconds”
この `gitlab_transaction_duration_seconds` こそが、リクエストごとの処理時間のヒストグラムです。これが「HelloWorld」の第一歩。ここからが本番です。
—
4. ステップ3：ボトルネックを撃ち抜くプロの分析フロー
ここからが、現場で震えるほど役立つ「ボトルネック特定」の極意です。
A. グラファナ（Grafana）で視覚化する
GitLabには標準でGrafanaが組み込まれています（`gitlab-ctl enable-grafana` で有効化可能）。ダッシュボードを開き、以下の項目を重点的にチェックしてください。
1. Rails Controller Latency: 特定のコントローラーが突出して遅くないか？
2. Database Query Duration: どのSQLが実行時間を食いつぶしているか？
3. Rugged/Gitaly Latency: Git操作（ファイル読み書き）で詰まっていないか？
B. 「遅いリクエスト」をピンポイントで追う
特定のAPIが遅い場合、GitLabのログを確認するのが定石です。
`/var/log/gitlab/gitlab-rails/production_json.log` を見てください。
ログ例
{“method”:”GET”,”path”:”/api/v4/projects/1/repository/commits”, … ,”duration_ms”:2500,”db_duration_ms”:2200}
このログから `db_duration_ms` が高いことが判明すれば、「あぁ、N+1問題か、インデックスが貼られていないクエリがあるな」と、コード修正の優先順位が瞬時に決まります。
—
5. 先輩からのアドバイス：完璧を目指さない
最後に一つだけ。「すべての処理を高速にする」のは悪手です。
プロは、「ユーザー体験に最も影響を与える、頻繁に叩かれるエンドポイント」の0.1秒を削ることに命をかけます。Prometheusのデータを見て、全体のトラフィックの90%を占める処理が快適なら、残りの10%は後回しでいい。
この視点を持つだけで、あなたのチームの生産性は劇的に向上します。
—
まとめ：
1. `/etc/gitlab/gitlab.rb` で監視を有効化。
2. `curl` でメトリクスが取れるか確認。
3. Grafanaで「DBクエリ時間」と「コントローラー遅延」を監視。
4. ログ（`production_json.log`）と突き合わせて、遅いクエリを特定。
これをマスターすれば、もう「GitLabが遅いんです」という報告に対して、勘に頼った回答をすることはありません。自信を持って「あそこのDBクエリにインデックスを貼りましょう」と言えるようになります。
さあ、あなたのGitLabの「心臓」を覗きに行きましょう。応援していますよ。