エンジニアの皆さん、こんにちは。
システムの監視、ちゃんと「出口」まで見えていますか？
多くの現場では、Prometheusでメトリクスを監視し、Grafanaでグラフを眺め、何かあればログをgrepして必死に原因を探す……という「お決まりの儀式」が繰り返されています。
しかし、もしメトリクスが「体温」、ログが「問診票」だとしたら、「何が体内で起きているか」を直接覗き込む「内視鏡」が欠けているのではないでしょうか。それが今回紹介する「連続的プロファイリング（Continuous Profiling）」の世界です。
今日は、Prometheusのエコシステムに「Pyroscope」を統合し、CPUやメモリの「中身」までをメトリクスと同じ軸で捉える、次世代のオブザーバビリティを手に入れましょう。
—
1. なぜ「メトリクス」だけでは不十分なのか？
CPU使用率が100%になった時、あなたはこう思いませんか？
「どの関数が、どのスタックトレースで、今まさにCPUを食いつぶしているのか？」
メトリクスは「事象（What）」を教えてくれますが、その「原因（Why）」を特定するには、断片的なログか、運任せのデバッグしかありませんでした。ここで登場するのがPyroscopeです。
Pyroscopeは、アプリケーションの実行状態を一定間隔でサンプリングし、それを時系列データとして保持します。つまり、「10分前にCPU使用率が跳ねたその瞬間の、コードレベルの実行状態」を、タイムトラベルして振り返ることができるのです。
—
2. アーキテクチャの基本：Prometheus + Pyroscope
連携のコンセプトはシンプルです。
- Prometheus: システム全体の「健康状態」を監視。
- Pyroscope: アプリケーション内部の「筋肉の動き（スタックトレース）」を監視。
これらをGrafanaに集約することで、メトリクスで異常を発見し、そのまま同じタイムラインでプロファイルを確認するという、淀みのない「解決への最短ルート」が完成します。
—
3. 早速やってみよう：PyroscopeのHelloWorld
今回はGo言語のアプリケーションを例に、最もシンプルかつ強力なセットアップを行います。
① Pyroscopeサーバーの起動（Docker）
まずは司令塔となるPyroscopeを立ち上げます。
ローカルでサクッと起動
docker run -p 4040:4040 grafana/pyroscope:latest
これだけで `http://localhost:4040` に管理画面が立ち上がります。
② アプリケーション側のセットアップ
次に、Goのコードに「内視鏡」を仕込みます。わずか数行です。
package main
import (
“github.com/grafana/pyroscope-go”
)
func main() {
// プロファイラーの初期化
pyroscope.Start(pyroscope.Config{
ApplicationName: “my-awesome-service”, // サービス名
ServerAddress: “http://localhost:4040”, // Pyroscopeの場所
ProfileTypes: []pyroscope.ProfileType{
pyroscope.ProfileCPU, // CPU使用率
pyroscope.ProfileMemHeap, // メモリヒープ
},
})
// ここにあなたのメイン処理を書く
runBusinessLogic()
}
たったこれだけです。アプリケーションを起動すれば、PyroscopeのUI上に刻一刻とスタックトレースの「炎（Flame Graph）」が積み上がっていきます。
—
4. 障害時の「ボトルネック特定」手順
実際に障害が起きたとき、現場ではこのように動きます。
1. メトリクスを確認: Prometheus/GrafanaでCPUスパイクを発見。
2. タイムラインを同期: Grafanaのパネルで該当の時間をマウスドラッグ。
3. プロファイルを確認: 連携されたPyroscopeのFlame Graphを開く。
4. 原因の特定: グラフの幅が広い関数＝最もCPU時間を消費している処理を特定。
- 「ああ、この正規表現の計算でループしていたのか！」 と、コードの場所まで一瞬でたどり着けます。
—
5. 先輩エンジニアからのアドバイス：極意
初心者のうちは、「すべてをプロファイルしよう」としがちですが、それは禁物です。
- 本番環境はオーバーヘッドに注意: 連続的プロファイリングは非常に軽量ですが、サンプリング間隔を極端に短くするのは避けましょう。デフォルトの設定で十分な精度が出ます。
- 「差分」を見る: Pyroscopeの真骨頂は、「障害発生前」と「発生中」のプロファイルを比較（Diff）することです。何が増えたのかが一目瞭然になります。
—
まとめ：今日から「勘」でコードを直すのはやめよう
メトリクス監視の次に進むべき道は、間違いなく「連続的プロファイリング」です。これをマスターすれば、障害対応の時間が劇的に短縮されるだけでなく、ボトルネックがどこにあるのかを推測ではなく「事実」に基づいて語れるようになります。
「なぜか重い」という曖昧な悩みから解放され、自信を持ってコードを改善できるようになる。これこそが、プロのオブザーバビリティです。
さあ、あなたのシステムにも「内視鏡」を通してみませんか？毎日の運用が、きっと少しだけ楽しくなりますよ。