ForHosting KIT · 開発者向けツール

ログのタイムスタンプ解析

Apacheの25/Jul/2026:14:30:00 +0200も、syslogのJul 25 14:30:00も、2026-07-25T14:30:00.123Zも、ISO 8601のUTC時刻とエポックミリ秒、判定した形式で返ります。ブラウザで無料で使えます。

  • 無料
  • ブラウザで動作
  • 登録不要
  • データは端末の外に出ません
ご利用方法 ウェブAPIメールTelegramアプリ 近日
入力した場合
テキスト
2026-07-25T14:30:00.123Z INFO worker started
結果
Iso
2026-07-25T14:30:00.123Z
エポック (ms)
1,784,989,800,123
出力形式
iso8601

ログファイルごとにタイムスタンプの書き方はバラバラです。アプリは ISO 8601 を出力し、ホストは syslog を書き、Web サーバーは Apache の共通ログ形式で記録するため、3つのソースを統合するには同じ解析コードをまた書くことになります。1回の呼び出しで、形式ごとの正規表現とタイムゾーン計算の山を置き換えられます。

3つの形式、1つの正規化された回答

どのログソースも何十年も前に独自の慣習を選び、そのまま変わっていません。2026-07-25T14:30:00.123Z のような ISO 8601 のタイムスタンプは曖昧さがありませんが、実際に出会う形式の一つにすぎません。

RFC 3164 に従う syslog 行は Jul 25 14:30:00 のようなタイムスタンプで始まり、年もタイムゾーンもなく、日が一桁のときは空白が2つ入ります。

Apache や nginx の共通ログ形式のアクセスログは、25/Jul/2026:14:30:00 +0200 のようにスラッシュとコロン、数値のゾーンを使う全く別の形です。ログタイムスタンプパーサーは、いずれの形式であっても行頭のタイムスタンプを受け付け、正規化された一つの ISO 8601 UTC 文字列、エポックミリ秒、一致した形式名を返します。

ソースの種類で処理を分ける必要はもうありません。既知のタイムスタンプで始まらない行は、推測した日付ではなく明確なエラーで拒否されるため、不正な行は下流の分析を静かに壊すのではなく、上流で確実に失敗します。

正規化が実際に意味すること

微妙なバグが潜むのは正規化の部分なので、ルールは明確に定められています。2026-07-25T16:30:00+02:00 のように明示的なオフセットを持つ ISO 8601 の入力は UTC に変換され、2026-07-25T14:30:00.000Z として返されます。同じ瞬間を、一つの標準的な表記で表します。

ゾーンを持たない ISO スタンプは UTC とみなされます。これはサーバーログにとって最も意外性の少ない既定です。Apache の必須の数値ゾーンはそのまま正確に尊重されます。

syslog に年がない点だけは推測が避けられません。小数秒はミリ秒精度まで保持されます。暦の検証は厳密で、2月30日、25時、61秒は翌日への暗黙の繰り上げではなくエラーです。

ありえない日付を受け入れるログパイプラインは、いつか障害対応の最中にあなたを迷わせるからです。

パイプライン向け、設計上決定論的

このパーサーは純粋関数です。形式を認識する正規表現と、暦日付とエポックを変換する整数の暦計算だけで構成されています。システム時計もネットワークも使わず、実行マシンのタイムゾーンにも依存しません。

つまり、同じ入力は今日のテストでも1年後の本番環境でも同じ出力を生みます。この決定論性は、アーカイブしたログを新しいパイプラインで再生し、再構築したタイムラインが元と一致することを期待する場面で重要です。

典型的な用途は、混合形式のアーカイブを検索エンジンに読み込む前の正規化、障害分析時にアプリケーション・システム・Web サーバーのイベントを一つの UTC タイムラインに並べること、シッパーがコレクターの期待する形式で行を記録しているかの検証です。同じコードはこのページのブラウザ上で無料で動かせます。行を貼れば結果が見られます。

異なるソースのログを統合

混合形式のアーカイブをログストアに読み込む前に、ISO、syslog、Apache のスタンプを一つの UTC タイムラインに正規化します。

障害タイムラインの再構築

各層が異なる形式で記録していても、アプリケーション、システム、Web サーバーのイベントを時系列に並べます。

ログシッパーの形式検証

エージェントから出力される行がコレクターの期待するタイムスタンプ形式で始まっているかを確認し、不正な行を早期に拒否します。

どのタイムスタンプ形式に対応していますか?

ISO 8601(小数秒やタイムゾーンオフセットの有無を問わず)、'Jul 25 14:30:00' のような RFC 3164 の syslog、'25/Jul/2026:14:30:00 +0200' のような Apache 共通ログ形式です。

タイムスタンプにタイムゾーンがない場合は?

UTC とみなされます。明示的なオフセットを持つスタンプは UTC に変換されるため、すべての回答が同じ正規化された形で返ります。

行が既知のタイムスタンプで始まらない場合は?

2月30日や25時のようなありえない日付も同じように拒否されます。

ログデータは保存されますか?

いいえ。 行はメモリ上で解析されて破棄され、返されるのは正規化されたタイムスタンプだけです。

syslogの時刻に年がない場合はどうなりますか?

syslogの形式はもともと年を持たないため、指定した年で補います。指定しなければ2000年を使い、年を推定したことを結果の中に明記します。

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

POSThttps://api.kit.forhosting.com/dev/timestamp-log-parse

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

curl -X POST https://api.kit.forhosting.com/dev/timestamp-log-parse \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"2026-07-25T14:30:00.123Z INFO worker started"}'
{
  "text": "2026-07-25T14:30:00.123Z INFO worker started"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.timestamp_log_parse",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

max_chars10000
HTTPコード意味
401unauthorizedAPIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
402insufficient_balance残高が不足しています。チャージ後に再度お試しください。
404unknown_type指定されたタスクタイプは存在しません。タイプ名を確認してください。
429rate_limitedリクエストが多すぎます。しばらく待ってから再度お試しください。

この API はログ行を受け取り、行頭のタイムスタンプを3つの形式のいずれかとして読み取り、ISO 8601 UTC に正規化して、エポックミリ秒と一致した形式名とともに返します。

3つの形式、1つの正規化された回答

何が来ても、一つのフィールドがいつ起きたかを教えてくれます。

正規化が実際に意味すること

RFC 3164 には年が含まれないため、パーサーは default_year パラメーター(指定しない場合は 2000)で補い、year_assumed: true を付けて、出力自体がその仮定を認めるようにします。

パイプライン向け、設計上決定論的

API 経由で自動化する場合はリクエストごとに $0.002 で、回答を返した後にファイルや行が保持されることはありません。

料金はいくらですか?

リクエストごとに $0.002 です。同じパーサーはこのページのブラウザ上でも無料で動作します。

年を含まない syslog 行はどうなりますか?

年は default_year パラメーター(指定しない場合は 2000)で補われ、結果には year_assumed: true が付くため、その仮定が出力から分かります。

KITの完全なドキュメントを見る →