P4サーバーのログをPSLA（log2sql）で解析する方法

対象とするログ

log2sqlが解析するのは、P4LOGまたはp4d -Lで出力されたテキスト形式の標準ログです。serverlog.file.Nで出力するCSV／JSON形式の構造化ログを入力する手順ではありません。

P4LOGにはユーザー名、IPアドレス、クライアント名、コマンド引数、Depotパスなどが含まれる場合があります。ログ、生成されるSQLiteデータベース、およびHTMLレポートは、アクセスを制限した場所で取り扱ってください。

本記事で使用する環境

項目	内容
解析用OS	Linux x86_64
log2sql	v0.15.1（2026年8月4日時点の最新リリース）
入力	P4サーバーのテキスト形式P4LOG（非圧縮またはgzip圧縮）
出力	SQLiteデータベース（.db）およびHTMLレポート
追加ツール	curl、gzip、SQLite 3、Bash 4以降

log2sqlのバイナリはLinux、macOS、Windows向けに公開されています。本記事ではLinux x86_64向けバイナリを使用します。バージョンは更新されるため、作業前にリリースページで最新バージョンと対応OS／CPUを確認してください。

1. 解析に必要なログ情報を記録する

解析に必要なコマンド開始・終了情報や性能トラッキング情報を記録するため、P4サーバーでは次の診断設定が推奨されています。

p4 configure set <server-id>#server=3

• server=3：コマンドの開始・終了情報に加え、一部コマンドのcompute end情報を記録します。
• <server-id>#を付けると、分散構成の特定サーバーだけに設定できます。すべてのサーバーに適用する場合は、この部分を省略します。
• サーバー仕様(p4 server <server-id>)のDistributedConfigで設定いただくこともできます。

P4LOGの出力先は、P4サーバーの起動時にP4LOG環境変数またはp4d -Lで設定します。上記の診断レベルではログ量が増加するため、空き容量を監視し、定期的にログをローテーションしてください。設定前の処理について、後からトラッキング情報を追加することはできません。

P4LOGのローテートについては以下を参照ください。

P4D起動オプションによるログ管理

2. log2sqlをダウンロードする

解析用ホストで作業ディレクトリを作成します。

mkdir -p "$HOME/psla/input" "$HOME/psla/output"
cd "$HOME/psla"

Linux x86_64向けの最新バイナリをダウンロードします。

curl -L -O https://github.com/rcowham/go-libp4dlog/releases/latest/download/log2sql-linux-amd64.gz

ダウンロード後、リリースページに表示されているSHA-256値と照合します。

sha256sum log2sql-linux-amd64.gz

一致を確認したら展開し、実行権限を設定します。

gzip -d log2sql-linux-amd64.gz
mv log2sql-linux-amd64 log2sql
chmod 755 log2sql
./log2sql --version

バージョン番号が表示されれば準備完了です。Go版log2sqlは単体実行ファイルであり、PythonやGoの実行環境を別途インストールする必要はありません。

3. 解析対象のP4LOGを用意する

解析中のP4サーバーへ負荷を加えないよう、可能であればローテーション済みのログを解析用ホストへコピーします。障害や性能低下を調べる場合は、事象発生時刻だけでなく、その前後を含むログを用意してください。

cp /path/to/rotated-p4d.log "$HOME/psla/input/p4d.log"

log2sqlは.gz形式のログを直接読み込めるため、容量の大きいログを事前に展開する必要はありません。また、同一サーバーの連続した複数ログを一つのデータベースへ取り込むこともできます。コミット、エッジ、レプリカなど異なるサーバーのログは、通常はサーバーごとに別のデータベースを作成してください。

4. P4LOGをSQLiteデータベースへ変換する

次のコマンドを実行します。

cd "$HOME/psla/output"
../log2sql --no.metrics -d p4d-analysis ../input/p4d.log

完了すると、$HOME/psla/output/p4d-analysis.dbが作成されます。

• d p4d-analysis：出力データベース名を指定します。拡張子.dbは自動的に付加されます。
• no.metrics：VictoriaMetrics向けの履歴メトリクスファイルを作成しません。SQLite／HTMLレポートのみを使用する場合に指定します。

gzip圧縮されたログも同じ方法で指定できます。

../log2sql --no.metrics -d p4d-analysis ../input/p4d.log.gz

同一サーバーの複数のローテーションログをまとめて解析する例は次のとおりです。

../log2sql --no.metrics -d p4d-analysis ../input/p4d-2026080*.log.gz

--no.metricsを省略すると、SQLiteデータベースに加えて.metricsファイルが作成されます。このファイルはVictoriaMetricsへ取り込み、Grafanaで時系列グラフを表示する場合に使用します。

5. HTMLレポートを作成する

現行リポジトリには、SQLiteデータベースに対して定型SQLを実行し、テキスト、JSON、CSV、またはHTML形式のレポートを作成するsql_report.shが用意されています。本記事ではHTML形式を使用します。

Ubuntu／Debianの例では、SQLite 3をインストールします。

sudo apt-get install sqlite3

log2sqlと同じバージョンのsql_report.shをダウンロードします。次の例はv0.15.1です。別バージョンを使用する場合は、URL内のタグも同じバージョンへ変更してください。

cd "$HOME/psla"
curl -L -o sql_report.sh https://raw.githubusercontent.com/rcowham/go-libp4dlog/v0.15.1/cmd/log2sql/sql_report.sh
chmod 755 sql_report.sh

HTMLレポートを作成します。

./sql_report.sh \
  -f html \
  -o output/p4d-analysis-report.html \
  output/p4d-analysis.db

$HOME/psla/output/p4d-analysis-report.htmlをブラウザで開きます。レポートはローカルHTMLとして生成され、P4サーバーへ接続しません。

6. レポートを確認する

主な項目	確認内容
Database metadata	log2sqlのバージョン、データベース作成日時、取り込んだログファイルを確認します。
Start and end time	データベースに含まれるログの時間範囲が、調査対象期間を含んでいるか確認します。
Command counts	コマンド種別、ユーザー、アプリケーションごとの実行回数を確認します。
Long commands	長時間実行されたコマンドを確認します。既定値は通常コマンド100秒超、sync／transmit系500秒超です。
Busiest Running Per Minutes	同時実行コマンド数が多かった時間帯を確認します。既定のしきい値は20です。
CPU／Memory／I/O	CPU時間、メモリ使用量、ディスクI/Oが大きいコマンドを確認します。
Blocking commands	データベースロックを長く保持し、他の処理を待たせた可能性があるコマンドを確認します。
Blocked commands	データベースロックの取得を長く待ったコマンドを確認します。待機したコマンドが必ずしも原因側とは限りません。
Replication	対象ログに情報がある場合、マスター／Commit側のrmt-Journal処理時間を確認します。

ロック問題を調べる場合は、待機時間（wait）が大きい処理だけでなく、その直前に同じテーブルのロック保持時間（held）が大きい処理を確認します。待機時間が大きい処理は影響を受けた側であり、保持時間が大きい処理が原因側の候補です。

7. レポートのしきい値を変更する

小規模環境や短時間の遅延を調査する場合は、レポートのしきい値を変更できます。次の例では、通常コマンド30秒、sync系120秒、同時実行数30、ロック5秒、上位50件に変更します。

./sql_report.sh \
  -f html \
  -t long_cmd=30 \
  -t long_sync_cmd=120 \
  -t busy=30 \
  -t locks=5000 \
  -t limit=50 \
  -o output/p4d-analysis-report.html \
  output/p4d-analysis.db

性能とロックに関するセクションだけを出力する場合は、次のように指定します。

./sql_report.sh \
  -f html \
  -s performance,locks \
  -o output/p4d-performance-locks.html \
  output/p4d-analysis.db

8. その他の公開ツール

2026年8月4日時点のgo-libp4dlog v0.15.1では、次の利用者向けツールが公開されています。log2sqlとsql_report.shは前項までで説明したため、ここでは残りの3ツールを説明します。

ツール	対象	主な用途	出力
log2sql	P4サーバーのP4LOG	ログ全体を検索・集計可能なデータへ変換	SQLite、JSON、SQL、履歴メトリクス
sql_report.sh	log2sqlが作成したSQLiteデータベース	定型レポートの作成	text、JSON、CSV、HTML
p4locks	P4サーバーのP4LOG	テーブルロックの待機時間・保持時間をタイムライン表示	HTML
p4dpending	P4サーバーのP4LOG	完了レコードが見つからないコマンド候補を抽出	JSON Lines
p4plog2sql	P4 Proxy（P4P）のログ	同期ファイルが上位サーバーとProxyキャッシュのどちらから配信されたかを集計	SQLite、JSON、SQL

p4locks：テーブルロックを可視化する

p4locksは、P4LOGに記録されたデータベーステーブルごとのread／writeの待機時間（wait）と保持時間（held）を解析し、Google Chartsのタイムラインを含むHTMLファイルを作成します。ロック競合の発生時刻と、原因側の候補となるコマンドを時系列で確認したい場合に使用します。

Linux x86_64向けバイナリをダウンロードします。

cd "$HOME/psla"
curl -L -O https://github.com/rcowham/go-libp4dlog/releases/latest/download/p4locks-linux-amd64.gz
gzip -d p4locks-linux-amd64.gz
mv p4locks-linux-amd64 p4locks
chmod 755 p4locks
./p4locks --version

10秒以上のロック待機または保持をHTMLへ出力する例は次のとおりです。

cd "$HOME/psla/output"
../p4locks \
  -t 10000 \
  -o p4d-locks.html \
  ../input/p4d.log

• t 10000：10,000ミリ秒未満のロック待機・保持を除外します。既定値も10,000ミリ秒です。
• o p4d-locks.html：出力するHTMLファイルを指定します。
• x "(monitor|user)"：必要に応じて、表示対象外とするテーブル名をGo正規表現で指定できます。

作成されたHTML自体はローカルで開けますが、グラフ表示ではGoogle ChartsのJavaScriptを読み込むため、閲覧端末からインターネットへ接続できる必要があります。

p4dpending：完了レコードがないコマンドを抽出する

p4dpendingは、ログ内に開始レコードがある一方で、対応する完了レコードが見つからないコマンドを新しい順に抽出します。障害発生時点で長時間継続していた可能性のあるコマンドを探す場合や、ログ解析結果を検証する場合に使用します。

Linux x86_64向けバイナリをダウンロードします。

cd "$HOME/psla"
curl -L -O https://github.com/rcowham/go-libp4dlog/releases/latest/download/p4dpending-linux-amd64.gz
gzip -d p4dpending-linux-amd64.gz
mv p4dpending-linux-amd64 p4dpending
chmod 755 p4dpending
./p4dpending --version

ログ末尾の時点で完了レコードが見つからないコマンドをJSON Lines形式で出力します。

cd "$HOME/psla/output"
../p4dpending \
  --json.output p4d-pending.json \
  ../input/p4d.log

v0.15.1では、--end.time "YYYY/MM/DD HH:MM:SS"を指定すると、その時刻より後のログエントリを処理せず、調査時刻時点の候補を抽出できます。出力はJSONオブジェクトを1行ずつ記録するJSON Lines形式です。jqで配列として扱う場合はjq -sを使用します。

p4plog2sql：P4 Proxyのキャッシュ効果を集計する

p4plog2sqlはP4サーバーではなく、P4 Proxy（p4p）のテキストログを解析します。同期されたファイル数とデータ量について、上位サーバーから取得した分とProxyキャッシュから配信した分をSQLiteデータベースへ記録します。Proxyキャッシュの利用状況を日別などで集計する場合に使用します。

Linux x86_64向けバイナリをダウンロードします。

cd "$HOME/psla"
curl -L -O https://github.com/rcowham/go-libp4dlog/releases/latest/download/p4plog2sql-linux-amd64.gz
gzip -d p4plog2sql-linux-amd64.gz
mv p4plog2sql-linux-amd64 p4plog2sql
chmod 755 p4plog2sql
./p4plog2sql --version

P4 ProxyのログをSQLiteデータベースへ変換します。

cd "$HOME/psla/output"
../p4plog2sql \
  -d p4p-analysis \
  ../input/p4p.log

完了するとp4p-analysis.dbが作成されます。主なデータはp4pcmdテーブルに記録され、proxyTotalsSvr／proxyTotalsSvrBytesが上位サーバーから取得したファイル数／バイト数、proxyTotalsCache／proxyTotalsCacheBytesがProxyキャッシュから配信したファイル数／バイト数です。sql_report.shはP4サーバー用のlog2sqlデータベースを対象としているため、このデータベースには使用しません。sqlite3や表計算ソフトで集計してください。

Workshopに残っている旧スクリプトの扱い

WorkshopのPSLAソースツリーには旧実装も引き続き公開されていますが、公開されていることと現行推奨であることは同じではありません。新規の解析環境では前述の現行ツールを使用してください。

ファイル	役割	現時点での扱い
log2sql.py	P4LOGをSQLiteへ変換するPython版	PSLA READMEで非推奨。Go版log2sqlに置き換えられています。
log_analyzer.php	P4LOGからSQLite、テキスト、HTMLレポートを作成するPHP版	PSLA READMEで非推奨。Go版log2sqlを使用します。
p4clog.py	P4LOGを走査し、グラフ作成向けデータを出力するPythonスクリプト	PSLA READMEで非推奨です。
log2sql.rb	P4LOGからSQLを生成する旧Ruby版	ソースツリーには残っていますが、現行READMEの推奨対象ではありません。
pxlog2sql.py	P4 ProxyログをSQLite／SQLへ変換する旧Python版	新規利用では現行リリースのp4plog2sqlを使用します。
psla.py、run_psla.sh	旧Flask Webアプリの起動ファイル	本記事のsql_report.shによるレポート手順では使用しません。
log2sql-examples.sql	SQLiteデータベースを調べるSQL例	解析スクリプトではなく、参考用のSQL集です。

テストコード、設定ファイル、Makefile、Dockerfile、およびGrafana／VictoriaMetrics向けのmetrics/docker環境は、利用者がP4LOGを直接解析する追加スクリプトではないため、上表の実行対象には含めていません。

トラブルシューティング

Permission deniedと表示される

実行権限を設定してください。

chmod 755 log2sql sql_report.sh

レポートに期待するコマンドが表示されない

ログの時間範囲、P4LOGの出力先、構成可能変数serverの設定を確認してください。server=1で作成され、完了レコードが含まれないログを解析する場合は、log2sqlの--no.completion.recordsオプションを検討します。

../log2sql \
  --no.metrics \
  --no.completion.records \
  -d p4d-analysis \
  ../input/p4d.log

大きなログの解析でサーバー負荷が高くなる

log2sqlはマルチスレッドで動作し、複数のCPUコアを使用します。P4サーバー本番ホストではなく解析用ホストで実行するか、Linuxのniceで優先度を下げて実行してください。

nice -n 10 ../log2sql \
  --no.metrics \
  -d p4d-analysis \
  ../input/p4d.log

旧手順のPython／Flask環境でエラーになる

旧PSLAに含まれるPython版log2sql.pyは非推奨です。現行のGo版log2sqlでSQLiteデータベースを作成し、sql_report.shでHTMLレポートを生成してください。この方法ではPython／Flask環境は不要です。

注意事項

• 本ツールはP4サーバーに標準添付されるコマンドではありません。Perforce Workshop／GitHubで公開されているログ解析ツールです。
• レポートは問題箇所を絞り込むための材料です。原因の確定には、元のP4LOG、OS／ストレージ／ネットワークの監視情報、P4サーバーの設定、障害発生時刻を併せて確認してください。
• P4LOGと解析結果には環境固有情報が含まれる場合があります。社外へ提供する前に、組織のセキュリティポリシーに従って内容を確認してください。
• 診断レベルを上げるとログが急速に増加する場合があります。空き容量の監視とログローテーションを必ず実施してください。

関連情報

• Perforce Workshop：Perforce Server Log Analyzers
• GitHub：go-libp4dlog／log2sql
• log2sql 最新リリース
• sql_report.sh
• P4 Server Administration Documentation：Diagnostic flags for monitoring the server
• P4 Server Administration Documentation：Using P4LOG
• P4 Server Administration Documentation：Configure logging