3、基础目录结构：/var/log/{service}/{env}/{type}/{YYYY}/{MM}/{DD}/ 标准模型解析
日志目录怎么设计？很多人觉得随便建个文件夹就行。但我在企业里踩过坑——日志混在一起，排查问题时像大海捞针。后来我总结出这套模型，说白了就是给日志文件上了个「多维索引」。
先看这个标准路径：
/var/log/{service}/{env}/{type}/{YYYY}/{MM}/{DD}/嗯，一共五层。每一层都有它的道理。我们一层层拆开看。
3.1 第一层：{service} —— 服务隔离
为什么第一层是服务名？你想想看，一个企业里少说几十个服务。如果所有日志堆在一起，光找文件就能让你崩溃。
我建议用服务名做顶层目录。比如：
/var/log/nginx//var/log/mysql//var/log/api-gateway//var/log/user-service/
这样做的好处很明显：
- 权限控制方便 —— 每个服务只读写自己的目录
- 磁盘隔离 —— 可以针对单个服务做磁盘配额
- 运维清晰 —— 哪个服务出问题，直接进对应目录
user-service，不要用 UserService 或 user_service。Linux 系统对大小写敏感，统一风格能避免很多低级错误。
3.2 第二层：{env} —— 环境区分
第二层放环境标识。我在项目中遇到过，有人把开发环境和生产环境的日志混在一起。结果半夜排查生产故障，翻出来的全是测试数据……那场面，别提多尴尬了。
标准的环境分类：
| 环境标识 | 说明 | 典型用途 |
|---|---|---|
prod |
生产环境 | 线上真实流量，需要长期保留 |
staging |
预发布环境 | 上线前最后验证，保留周期较短 |
test |
测试环境 | 自动化测试、集成测试日志 |
dev |
开发环境 | 开发人员本地调试，通常不集中采集 |
dev、test、prod 三个环境，但测试环境日志量特别大，把磁盘撑爆了，导致生产日志写不进去。后来我强制要求每个环境挂载独立磁盘分区，才彻底解决这个问题。
3.3 第三层：{type} —— 日志类型
第三层按日志类型划分。一个服务会输出多种日志，混在一起根本没法用。
常见的日志类型：
access—— 访问日志，记录每次请求error—— 错误日志，记录异常和报错audit—— 审计日志，记录操作行为slow—— 慢查询日志，记录性能瓶颈debug—— 调试日志，开发阶段使用
举个例子，Nginx 的日志目录结构：
/var/log/nginx/prod/access/2025/03/21/
/var/log/nginx/prod/error/2025/03/21/
/var/log/nginx/staging/access/2025/03/21/这样设计，你想查生产环境 Nginx 今天的错误日志，直接进 /var/log/nginx/prod/error/2025/03/21/，一秒定位。
3.4 第四到六层：{YYYY}/{MM}/{DD} —— 时间分区
最后三层是年、月、日。为什么拆成三层而不是一层？
我刚开始做日志系统时，也想过用 20250321 这种单层目录。但后来发现，时间长了目录里文件太多，ls 命令都卡。而且做日志清理时，按月份删除非常麻烦。
拆成三层的好处：
- 目录扁平 —— 每个目录下最多 31 个文件
- 清理方便 —— 想删某个月的数据，直接
rm -rf /var/log/nginx/prod/access/2025/03/ - 归档灵活 —— 可以按年、按月、按天做不同策略
3.5 完整示例：一个真实的日志目录
来看一个完整的例子。假设我们有个电商系统，包含订单服务和支付服务。生产环境的访问日志目录结构：
/var/log/
├── order-service/
│ ├── prod/
│ │ ├── access/
│ │ │ └── 2025/
│ │ │ └── 03/
│ │ │ ├── 21/
│ │ │ │ ├── access.log
│ │ │ │ └── access.log.gz
│ │ │ └── 22/
│ │ │ └── access.log
│ │ ├── error/
│ │ │ └── 2025/
│ │ │ └── 03/
│ │ │ └── 21/
│ │ │ └── error.log
│ │ └── slow/
│ │ └── 2025/
│ │ └── 03/
│ │ └── 21/
│ │ └── slow_query.log
│ └── staging/
│ └── access/
│ └── 2025/
│ └── 03/
│ └── 21/
│ └── access.log
└── payment-service/
└── prod/
└── access/
└── 2025/
└── 03/
└── 21/
└── access.log看到没？这个结构天然支持按服务、按环境、按类型、按时间做任意维度的查询。你可以在 5 秒内定位到任何一条日志。
3.6 核心逻辑：为什么是这五层？
这五层不是随便定的。我画了张图，帮你理解它们的关系：
这张图想表达的核心思想：五层目录 = 五个索引维度。服务、环境、类型是「业务维度」，年、月、日是「时间维度」。两者组合，构成了一个完整的日志索引体系。
3.7 避坑指南：常见错误
我见过不少团队在这个模型上翻车。总结几个常见问题：
- 层级顺序搞反 —— 有人把时间放前面，服务放后面。结果想查某个服务的所有日志，得遍历所有时间目录，性能极差。
- 环境标识不统一 —— 有人用
production，有人用prod，还有人用prd。统一规范比什么都重要。 - 日志类型太粗 —— 所有日志都扔进
general目录，等于没分类。我建议至少分出access、error、audit三类。 - 时间分区不完整 —— 只按天分区，没有年、月。一年后目录里 365 个文件夹，管理起来很痛苦。
3.8 小结：记住三个要点
这套目录模型，你只需要记住三点：
- 业务维度在前 —— 服务 > 环境 > 类型，从大到小排列
- 时间维度在后 —— 年 > 月 > 日，从粗到细拆分
- 保持一致性 —— 所有服务、所有环境都遵循同一套规则
做到这三点，你的日志目录就已经具备了企业级的基础。后面章节我们会在这个基础上，加上日志轮转、压缩、清理策略，让它真正能支撑大规模生产环境。