ログのタイムスタンプ判別実務
公開: 2026-06-16・対象: SRE・運用エンジニア
本番サーバーのログに 1734220800.123 や 1734220800123456 が並んでいて『いつだ?』が即時に出ない、というのは深夜の障害対応で一番つらい瞬間です。秒・ミリ秒・マイクロ秒の判別、ISO 8601との往復、UTC/JST取り違えという3つの定番落とし穴を、実例で整理します。
桁数で秒・ミリ秒・マイクロ秒を判別する
UNIXタイムスタンプの単位は『見た目』では分かりませんが、2026年時点では桁数で機械的に判別できます。
| 桁数 | 単位 | 例 | よく見る場所 |
|---|---|---|---|
| 10桁 | 秒 | 1734220800 | Nginx access_log($msec整数部)、JWT |
| 13桁 | ミリ秒 | 1734220800123 | JavaScript Date.now()、Java System.currentTimeMillis() |
| 16桁 | マイクロ秒 | 1734220800123456 | Pythonのtime_ns()/1000、PostgreSQL timestamp |
| 19桁 | ナノ秒 | 1734220800123456789 | Goのtime.Now().UnixNano()、Prometheus |
| 小数点付き | 秒.端数 | 1734220800.123 | Pythonのtime.time()、Rubyのto_f |
『10桁が秒』が直感に反するかもしれませんが、秒で10桁になるのは2001-09-09以降、11桁になるのは2286年以降です。2001年〜2286年のログはすべて10桁の秒と覚えれば判別ミスはほぼ起きません。
UNIX時間とISO 8601の相互変換
人間が読むログはISO 8601(2026-06-16T12:00:00+09:00)形式が標準。機械処理はUNIX秒。両者を素早く往復するためのコマンドを並べます。
# Linux(GNU date): UNIX秒 → ISO 8601 date -d @1734220800 -Iseconds # → 2024-12-15T09:00:00+09:00(端末がJSTの場合) # UTC基準で出したい TZ=UTC date -d @1734220800 -Iseconds # → 2024-12-15T00:00:00+00:00 # 逆方向: ISO 8601 → UNIX秒 date -d "2024-12-15T09:00:00+09:00" +%s # → 1734220800 # macOS(BSD date)は -d ではなく -j -f date -j -f "%s" "1734220800" "+%Y-%m-%dT%H:%M:%S%z"
RFC 3339(IETF Standards Track)はISO 8601のサブセットで、必ずタイムゾーン情報を含むのが特徴です。インターネット越しの通信ではRFC 3339形式を推奨します。
Nginxアクセスログのタイムスタンプ
NginxはデフォルトでローカルタイムゾーンのCommon Log Format形式(15/Dec/2024:09:00:00 +0900)で記録します。これをUNIX秒で残したい場合は $msec 変数(秒.ミリ秒)を使います。
# nginx.conf
log_format with_unix '$msec $remote_addr "$request" $status';
access_log /var/log/nginx/access.log with_unix;
# 出力例
# 1734220800.123 203.0.113.10 "GET /api/users HTTP/1.1" 200
# 秒の整数部だけ抜き出す
awk '{split($1, a, "."); print a[1]}' access.logCloudflare Logpush・AWS CloudFrontの形式
- Cloudflare Logpush:
EdgeStartTimestampはナノ秒(19桁、RFC 3339形式オプションあり)。ClientRequestUserAgentと一緒に出る前提。 - AWS CloudFront access log:
dateとtime列はUTC基準のISO 8601風(2024-12-15 00:00:00)。タイムゾーン情報は付かないのでUTC前提で読む。 - AWS ALB:
timestamp列はISO 8601 + マイクロ秒精度のUTC(2024-12-15T00:00:00.123456Z)。 - GCP Cloud Logging:
timestampはRFC 3339形式、内部的にはナノ秒精度で保持。
UTC/JST取り違えの実例
障害対応で最も多い『9時間ズレている』問題の典型パターンです。
- LinuxサーバーのデフォルトはUTCで動作することが多い(
/etc/timezoneを確認)。アプリログのISO 8601は+00:00またはZ付きでも、運用者は無意識にJSTで読む。 - DockerコンテナはホストOSのTZを引き継がない。デフォルトUTC。アプリ起動時に
TZ=Asia/Tokyoを渡さないとログがUTCになる。 - SlackやPagerDutyの通知はユーザータイムゾーンで表示されるが、APIで取得した生データはUTCのUNIX秒。これを目視でJSTと勘違いするとアラート時刻が9時間ズレる。
- 監視ダッシュボードのDatadog・Grafana・New Relicは、ブラウザのタイムゾーンで自動換算する。チームメンバーの環境差で『同じグラフが違って見える』ことがある。
syslog・journaldとの照合
syslogとアプリログを突き合わせるとき、syslog側のタイムスタンプは RFC 5424形式のISO 8601(2024-12-15T00:00:00.123456+00:00)です。
# journalctlでUNIX秒で出力
journalctl --output=short-unix
# → 1734220800.123456 hostname systemd[1]: Started ...
# 特定UNIX秒の前後10秒のログを抽出
journalctl --since=@1734220790 --until=@1734220810
# syslogをUNIX秒に変換しながら表示
awk '{
cmd = "date -d \"" $1 "\" +%s"
cmd | getline ts; close(cmd)
print ts, $0
}' /var/log/syslog補足
- ・本記事は2026-06-16時点の各社ログ仕様に基づきます。Nginx・Cloudflare・AWS各社の仕様は更新される可能性があります。
- ・本番ログのタイムゾーンを変更する作業は、過去ログとの突合が困難になるためメンテナンス窓を確保して実施してください。
- ・うるう秒の扱いはOS・NTPの実装で異なります(smear方式/step方式)。ミリ秒精度の照合では設計時に確認を。
タイムスタンプを変換して試す
実際のログの値を貼り付けて、秒/ミリ秒/マイクロ秒の自動判別とJST/UTCの同時表示を試せます:UNIXタイムスタンプ変換