4、日志文件命名规范：{service}_{host}_{type}_{timestamp}.log 格式详解
日志文件怎么命名？这事儿看着小，但坑特别多。我见过不少团队，日志随便起名，结果排查问题时翻半天找不到文件。今天咱们就把这个格式掰开揉碎了讲清楚。
4.1 为什么需要统一命名规范？
说白了，日志文件命名就是给数据打标签。没有规范，你想想看：
- 运维脚本没法自动匹配文件
- 日志采集器配置要写一堆正则
- 排查问题时全靠人工翻目录
我在项目中遇到过，某团队用 app.log.2024-01-01 这种格式。结果日志轮转后变成 app.log.2024-01-01.1，采集器直接懵了。嗯，这就是没规范的代价。
4.2 格式拆解：{service}_{host}_{type}_{timestamp}.log
这个格式是我个人比较推荐的。它把四个关键信息都塞进了文件名，一眼就能看出日志的来龙去脉。
| 字段 | 含义 | 示例 | 说明 |
|---|---|---|---|
| {service} | 服务名称 | user-service |
微服务名或应用名，不要带版本号 |
| {host} | 主机标识 | web-01 |
主机名或IP简写，区分实例 |
| {type} | 日志类型 | access |
如 access、error、audit、slow |
| {timestamp} | 时间戳 | 2024-01-15T08:30:00Z |
必须使用UTC，避免时区混乱 |
完整示例：
user-service_web-01_access_2024-01-15T08:30:00Z.log
payment-api_pod-5_error_2024-01-15T08:31:15Z.log
audit-svc_node-3_audit_2024-01-15T08:32:00Z.log4.3 各字段设计要点
4.3.1 {service}：服务名称
服务名要稳定。别今天叫 user-svc，明天改 user-service。我建议用项目立项时的正式名称，全小写，连字符分隔。
- 正确：
order-service、payment-api、data-pipeline - 错误：
OrderService（大小写混用）、svc-v2（带版本号）
4.3.2 {host}：主机标识
容器化环境下，主机名可能是一串随机字符。这时候我建议用 Pod 名称或 Deployment 名称加序号。比如 web-deploy-7d8f9，这样能快速定位到具体实例。
小技巧：Kubernetes 环境下，可以用 metadata.name 作为 host 字段。但注意截断长度，别让文件名超过 255 字符。
4.3.3 {type}：日志类型
类型字段决定了日志的用途。我一般分这几类：
- access：访问日志，记录请求和响应
- error：错误日志，记录异常和堆栈
- audit：审计日志，记录操作行为
- slow：慢查询日志，记录性能瓶颈
- metric：指标日志，记录系统状态
类型别超过 10 种，否则管理成本太高。我曾经见过一个项目定义了 30 多种类型，最后没人分得清。
4.3.4 {timestamp}：时间戳（UTC）
这是最容易出问题的字段。为什么强制用 UTC？
你想想看，如果服务器在东京，你在北京，日志时间戳用本地时间。排查问题时，你看到 2024-01-15 17:30:00，但不知道这是 JST 还是 CST。嗯，这就是混乱的根源。
注意：时间戳格式建议使用 ISO 8601 标准：YYYY-MM-DDTHH:MM:SSZ。不要用 YYYYMMDDHHMMSS，虽然短，但可读性差，而且排序时容易出错。
4.4 时间戳使用UTC的深层原因
我遇到过最惨的一次事故：某系统日志用东八区时间，结果服务器迁移到美西后，日志时间直接乱了。运维同学排查问题时，发现日志时间比实际时间晚了 16 个小时。折腾了两天才定位到问题。
用 UTC 的好处：
- 全局统一：不管服务器在哪，时间戳都一样
- 排序正确：按文件名排序就是时间顺序
- 采集方便：日志采集器不需要做时区转换
- 归档简单：按日期归档时不会跨时区
4.5 命名规范知识体系
下面这张图展示了命名规范的核心逻辑：
4.6 避坑指南
这些年我踩过的坑，总结一下：
- 分隔符别乱用：统一用下划线。我曾经见过用
@和#的，结果 shell 脚本解析时直接报错。 - 文件名别太长：Linux 文件名上限 255 字符。服务名 + 主机名 + 类型 + 时间戳，控制在 100 字符以内比较安全。
- 时间戳精度：如果日志量特别大，建议精确到秒。毫秒级的话，文件名会很长，而且排序时容易出问题。
- 轮转后的命名：如果日志轮转，建议在文件名后加
.1、.2序号。比如user-service_web-01_access_2024-01-15T08:30:00Z.log.1。
个人建议：在日志框架中直接内置这个命名规范。比如 Logback 的 FileNamePattern 里配置好，开发人员不需要手动处理。这样从源头就保证了规范落地。
4.7 小结
日志文件命名规范，说白了就是给日志文件一个身份证。四个字段各司其职，时间戳用 UTC 统一全局。这套规范我用了好几年，在多个项目中验证过，效果不错。你照着这个来，基本不会出大问题。