📚 课程目录第4章日志格式解析

4. 日志格式解析：NCSA、JSON与自定义格式

做性能分析，第一步就是读懂日志。我记得刚带团队那会儿，有个同事盯着日志文件看了半天，跟我说“这日志是乱码”。我过去一看，其实就是个标准的NCSA格式，只是时间戳是用Unix时间戳表示的。说白了，不是日志有问题，是眼睛没训练过。

今天咱们就把OCSP常见的三种日志格式掰开揉碎。每种格式我都遇到过线上案例，有些坑，嗯，真是一步都不想让你再踩。

4.1 为什么格式这么重要？

你想想看，日志格式决定了你用什么工具去解析。格式不对，grep、awk、ELK全得白费劲。解析错了字段，性能数据就全错了。我之前有一次把响应时间解析成了请求时间，结果画出来的延迟曲线完全反了——排查了一整天才发现是字段位置搞混了。

OCSP服务器通常支持三种日志格式：

NCSA格式 —— Apache等Web服务器的标准格式，OCSP最早借鉴过来的
JSON格式 —— 现代OCSP服务器最推荐的格式，结构化、好解析
自定义格式 —— 各家厂商自己定制的格式，千奇百怪

咱们一个一个说。

4.2 NCSA格式：老派但依然常见

NCSA格式长这样：

192.168.1.10 - - [10/Oct/2023:13:55:36 +0800] "POST /ocsp HTTP/1.1" 200 832 "-" "Java/17.0.5" 0.035

关键字段拆开来看：

字段位置	字段含义	性能分析中的作用
客户端IP	请求来源IP地址	判断是否有单IP大量请求，用于流量来源分析
时间戳	[日/月/年:时:分:秒时区]	计算QPS、请求分布热点
方法+URL	POST /ocsp HTTP/1.1	核实请求路径是否正常，排除扫描流量
状态码	200	判断响应成功率，4xx/5xx占比
响应大小	832（字节）	OCSP响应体大小，判断是否正常
User-Agent	Java/17.0.5	识别客户端类型，区分正常客户端和爬虫
响应时间	0.035（秒）	核心性能指标，延迟分析的基础

特别注意：NCSA格式最后那个响应时间字段，不是所有OCSP实现都默认输出。我遇到过某厂商的OCSP服务器，日志末尾多了一个“-”占位符，响应时间字段被吞了。上线前一定要确认字段是否完整。

解析NCSA格式的窍门：用grep配合正则就够了，但性能分析时建议用awk。我个人习惯写个简单的awk脚本，把响应时间字段提出来算P50、P99：

awk '{print $NF}' ocsp_access.log | sort -n | awk '{count[NR]=$1} END{p50=count[int(NR*0.5)]; p99=count[int(NR*0.99)]; print "P50:",p50,"P99:",p99}'

4.3 JSON格式：现代OCSP的标配

JSON格式最大的好处就是结构清晰，字段名就是文档。举个例子：

{
  "timestamp": "2023-10-10T13:55:36.123Z",
  "client_ip": "192.168.1.10",
  "method": "POST",
  "uri": "/ocsp",
  "status_code": 200,
  "response_size": 832,
  "response_time_ms": 35.2,
  "user_agent": "Java/17.0.5",
  "serial_number": "0xAB1234CD",
  "certificate_issuer": "CN=Root CA,O=Example"
}

这里多出来的字段很关键：

serial_number：证书序列号，用来分析是不是某个特定证书导致了性能异常
certificate_issuer：证书颁发者，用于统计不同CA的请求分布
response_time_ms：毫秒级响应时间，比NCSA的秒级精度高

我的建议：如果用JSON格式，响应时间字段一定要用毫秒级精度。秒级精度在秒级以下的延迟分析中会产生大量无效数据。我之前排查过一个问题，所有日志响应时间都是“0秒”，你查不到任何延迟信息——后来发现是精度不够，实际延迟都在100ms以下。

解析JSON格式，我一般用jq工具，一行命令就能搞定复杂的过滤和聚合：

# 统计P50、P99延迟
cat ocsp.json | jq -s '. | map(.response_time_ms) | sort | {p50: .[length * 0.5 | floor], p99: .[length * 0.99 | floor]}'

JSON格式的另一个优势是方便导入到ELK等分析平台。你不需要写解析规则，直接投递就能用。我们生产环境100%使用JSON格式，就是为了这个。

4.4 自定义格式：厂商的“黑盒”

自定义格式是最头疼的。每家厂商都有自己的“特色”。我见过最奇葩的一种：

10-10-2023 13:55:36|192.168.1.10|POST|/ocsp|200|832|35|Java/17.0.5|AB1234CD|Root CA

用管道符分割，字段顺序和标准格式完全不同。碰到这种格式，核心要做两件事：

找字段映射文档 —— 问厂商要，或者去官网找。没有文档就对着日志和实际请求量慢慢猜。
确认响应时间字段的单位 —— 是秒还是毫秒？我遇到过厂商把纳秒当成秒写的，差了一百万倍。

避坑指南：我曾经踩过一个坑，某厂商自定义格式的时间戳是本地时间不带时区。跨区域部署后，日志时间全乱套了。如果你遇到自定义格式，第一时间确认时间戳是否含时区信息。

解析自定义格式，没有通用工具。我通常用Python写个解析脚本，灵活处理各种分隔符和字段顺序：

import re

line = "10-10-2023 13:55:36|192.168.1.10|POST|/ocsp|200|832|35|Java/17.0.5|AB1234CD|Root CA"
fields = line.split('|')
log_entry = {
    'timestamp': fields[0] + ' ' + fields[1],
    'client_ip': fields[2],
    'method': fields[3],
    'uri': fields[4],
    'status_code': int(fields[5]),
    'response_size': int(fields[6]),
    'response_time_ms': int(fields[7]),
    'user_agent': fields[8],
    'serial_number': fields[9],
    'issuer': fields[10]
}

4.5 三种格式的对比取舍

对比维度	NCSA格式	JSON格式	自定义格式
可读性	一般，需要查字段位置	好，字段名自解释	差，需要文档
解析工具	awk/grep基本够用	jq/ELK原生支持	需要自己写脚本
扩展性	差，加字段要改解析器	好，新增字段不影响旧数据	取决于厂商设计
性能分析适用性	适合快速查看，不适合大规模分析	适合自动化分析和大数据场景	能用的只有厂商自己的工具
推荐指数	★★☆☆☆	★★★★★	★☆☆☆☆

一句话总结：能用JSON就别用NCSA，能用NCSA就别碰自定义。三种格式我都用过，JSON格式带来的运维成本最低，分析效率最高。如果你还在用自定义格式，我建议你跟厂商沟通，看能不能升级到JSON格式。

4.6 知识结构一览

下面这张图把三种格式的核心字段与性能分析的关系梳理出来了。红色节点是关键性能字段，绿色是辅助分析字段：

读懂这张图其实很简单。你拿到日志后，先看格式类型，再按颜色抓字段。红色节点是性能分析的核心，少了任何一个，定位瓶颈时都会很吃力。紫色节点是JSON格式特有的，用来做精细化分析——比如证书序列号能帮你定位到某个具体证书的请求是否异常。