分布式可观测性 Structured Log

对於Log, 在Log采集服务, 希望是采取Structured Log的结构来输出.
常见的结构有JSON和KVP, 两者对於人类阅读性是很高的.
对於日志解析与搜寻更是方便,
相对於format string来输出成flat log来说, 後者还得费心的写Regex来parsing.

# flat log, 通常都透过format把值塞进去
%d{yyyy-MM-dd HH:mm:ss.SSS} %level ${application_name} trace=%X{X-B3-TraceId},span=%X{X-B3-SpanId} <%t> %c{40} - %msg%n

这种格式用ELK的话, 就是透过Logstash的grok写regex来解析, 转换成structured log, 再送到Elasticsearch.
然後维护grok的regex是脏活, 又累又没效率又没产出价值.
不做regex转换? 上一篇提到如果没有透过解析出来的filed做索引, 而直接全文检索,
恭喜你, 出事情找Log时应该慢到想骂人.
甚至也没办法透过Log中的时间来查找, 因为连时间都是要Regex来解析转换的
用前几篇的awk? 更会写到想死吧!

JSON格式的Log就没什麽好展示的, Kibana上看到的都是这类.
JSON格式基本上, 存的时候都是扁平的一行, 只是展示时会Pretty.

KVP则是通常长这样Key=Value Key2=Value2, 也没一定要用=或用space做衔接就是
通用格式则是Key Separator Value KVDelimiter
Separator可以是=或:
KVDelimiter可以是space,,, \t之类的
Key限制上就是至少一个非数字字元, 允许_、.、$和@
Value基本就是只要value中有Separator就要用" "包住

早期用Flat log是为了省空间, 因为JSON和KVP格式会大量重复出现Key, 以前量不大且是单机.
大多与Application在同一台机器上.
现在这点可以透过Compress压缩来解决,
因此在现在的时空背景, 查询与写入效能反而是我们在意的点.

令一个缺点大概是, 用OS提供的像是tail,less,cat
大概就看到眼花了吧, 都挤成一行XD

但优点真的太多, 光是一整行就能方便用grep或awk来搜寻到完整的Log内容,
也方便从内容里直接解析出一个时间值,
Key值本身就具备索引的属性, 便於查询跟分析,
其实也增加了事件描述语意的能力.

Go的生态圈有Zap与Logrus提供了Structured Log的输出

明日继续从Metrics与Tracing来介绍.

---参考资料
JSON & KVP
Introducing Structured Logs
logfmt