先分区，再谈检索效率

日志的价值，取决于需要它的时候能不能被快速找到。很多团队在采集、存储环节投入不少，却在目录结构上随手一放：所有业务日志平铺在一个目录里，所有运维日志按日期堆在一起。结果是排障时靠关键词全量扫描，审计时无法界定范围，清理时不敢下手。

把日志的组织方式和它的归属关系对齐，是一种成本很低、收益很持久的做法。对业务日志，以站点作为一级目录；对运维日志，以服务器或网络设备作为归档单元。前者对应业务边界，后者对应资产边界。

业务日志：按站点分目录

站点通常对应机房、可用区或城市节点，它天然划分了流量的来源与服务的部署范围。以站点为一级目录，等于在文件系统层面先做了一次分区，后续的检索、迁移、清理都可以限定在单个站点内完成。

推荐的分层结构

一个可读性较好的层次是：站点 → 业务线或应用 → 实例或容器 → 日期。例如：

• /logs/{site}/{app}/{instance}/{yyyy-mm-dd}/
• /logs/{site}/{app}/access-{yyyy-mm-dd}.log
• /logs/{site}/{app}/error-{yyyy-mm-dd}.log

站点名建议直接使用内部统一的机房或节点编码，而不是临时的城市拼音缩写，避免同一地点出现多种写法。

切分与命名规则

• 按天切分为主，单个文件过大时再按小时或按大小切分，保证单文件可被常用工具打开。
• 文件名中固定包含日期，便于脚本按文件名排序和过期删除，减少对文件时间戳的依赖。
• 访问日志与错误日志分开存放，避免排障时在大量正常记录中翻找。
• 同一应用在不同站点的日志格式保持一致，只让站点目录不同。

权限与保留

站点目录天然适合做权限边界：负责某站点的团队只对本站点目录具备读取权限，跨站点访问走审批。保留周期也可以按站点差异化设置，例如核心站点保留更久，测试站点更短。具体期限应结合所在行业的合规要求和业务方的实际需要来确定，而不是照搬他人配置。

运维日志：按服务器与设备归档

运维日志的来源是资产，而不是业务。系统日志、内核日志、带外管理日志、硬件告警、网络设备日志，它们的共同点是：出问题的单位是某一台服务器、某一台交换机，而不是某一个站点。

以资产编号为主键

归档目录建议使用资产编号或设备序列号作为主键，而不是 IP 地址。IP 会随着迁移、扩容、回收而重复使用，用 IP 命名会把不同时期的记录混在同一目录里；资产编号则与设备一一对应，跨越整个生命周期。

• /archive/{device-type}/{site}/{asset-id}/{yyyy}/{mm}/
• 网络设备可按设备角色再分一层，如核心、汇聚、接入。

归档内容与格式

• 操作系统日志：系统消息、认证记录、内核与硬件报错。
• 带外与管理口日志：开关机、重启、告警等硬件层面事件。
• 网络设备日志：接口状态变化、路由与链路相关事件。
• 归档时统一压缩，并保留校验信息，避免长期存放后文件损坏而无法察觉。

与资产台账联动

设备下线、更换、迁移时，归档目录应同步记录起止时间，并在资产台账中标注日志的存放位置。这样在追溯历史故障时，可以按时间点定位到当时真正在用的那台设备，而不是被后来复用的编号误导。

落地时的几个关键动作

1. 先定规范再上工具。目录层级、命名格式、字段含义写成文档，采集配置和清理脚本都以此为准。
2. 让采集端负责落位。由采集代理根据站点标签和资产标签自动写入对应路径，避免人工放置导致错位。
3. 区分热数据与冷数据。近期日志留在本地或高性能存储上便于检索，历史日志压缩后转入低成本存储，查询时按需回取。
4. 建立清理策略。按站点和资产设置不同的保留周期，清理动作可追溯，避免误删无法恢复。
5. 保留索引元数据。即使原始日志被压缩或迁走，也应保留站点、资产编号、时间范围等索引信息，让定位第一步不依赖全量扫描。

需要避开的几个误区

• 用 IP 或临时主机名作为归档主键，资产变更后历史记录失去对应关系。
• 业务日志与运维日志混放，排障时互相干扰，权限也无法细分。
• 只按日期堆放，站点和资产信息只存在于日志内容里，目录本身不携带任何语义。
• 目录层级过深或过浅。层级过深导致路径冗长难维护，过浅则单目录文件数量过多，影响列举和清理效率。

结语

日志目录结构不产生直接的业务功能，却决定了排障、审计和数据治理的成本上限。业务日志按站点分目录，运维日志按服务器与设备归档，本质上是让存储结构与责任归属保持一致。规范一旦确定，采集、检索、清理、交接都会随之变得简单。