日志系统入门：日志产生机制、日志存储路径、日志文件命名规则、日志级别分类
各位好，我是老张。干OTN运维这些年，我最大的体会就是——日志这东西，平时没人搭理它，一出故障它就是救命稻草。今天咱们就聊聊日志系统的基础，说白了就是搞清楚三件事：日志从哪来、存哪去、怎么认。
一、日志产生机制
OTN设备里的日志，不是凭空冒出来的。每个模块、每个单板、每个端口，都在实时产生事件。我打个比方：设备就像个24小时不睡觉的监控员，眼睛盯着所有光口、电口、时钟、电源……但凡有点风吹草动，它就记一笔。
具体来说，日志的产生分这么几步：
- 事件触发：硬件检测到异常（比如光功率下降、误码率超标），或者软件执行了某个操作（比如用户登录、配置变更），就会触发一个事件。
- 信息封装：系统把事件的时间、位置、类型、严重程度打包成一个结构化的记录。
- 写入缓存：先写到内存缓冲区，防止频繁写硬盘影响性能。
- 落盘存储：缓冲区满了或者达到定时周期，再批量写入日志文件。
重点来了：我遇到过好几次，设备掉电导致缓存里的日志没来得及写盘，结果故障分析时关键信息缺失。所以，有条件的话建议开启日志实时落盘功能，虽然性能会降一点，但数据安全更重要。
二、日志存储路径
不同厂商的OTN设备，日志存放位置大同小异。我以华为和中兴的设备为例，给大家列个参考：
| 设备类型 | 日志存储路径 | 说明 |
|---|---|---|
| 华为OSN系列 | /opt/oss/log/ | 网管日志 |
| 华为OSN系列 | /mnt/board/log/ | 单板日志 |
| 中兴M系列 | /var/log/otn/ | 系统日志 |
| 中兴M系列 | /data/log/board/ | 单板日志 |
| 第三方网管 | C:\Program Files\OTN\logs\ | Windows环境 |
嗯，这里要注意：路径里的斜杠方向别搞反了。Linux系统用正斜杠，Windows用反斜杠。我见过有人把路径写错，结果查了半天日志说找不到文件——其实路径就不对。
我的习惯：登录设备后第一件事，先敲 ls -l /var/log/otn/ 看看日志目录是否存在、权限对不对。这一步能避免后面很多麻烦。
三、日志文件命名规则
日志文件名不是随便起的，里面藏着很多信息。你想想看，如果所有日志都叫log.txt，那找起来得多崩溃？
常见的命名格式是这样的：
设备类型_单板槽位_日志类型_日期_序号.log
举例：
OSN9800_SLOT3_ALARM_20250101_001.log
M7210_BOARD2_EVENT_20250101_005.log
NMS_SYSTEM_ERROR_20250101_010.log拆开来看：
- 设备类型：OSN9800、M7210等，一眼知道是哪款设备
- 单板槽位：SLOT3、BOARD2，定位到具体板卡
- 日志类型：ALARM（告警）、EVENT（事件）、ERROR（错误）、DEBUG（调试）
- 日期：YYYYMMDD，按天归档
- 序号：001、002……同一天可能有多个文件
我记得有一次，客户说设备频繁闪断，我一看日志文件名——全是ALARM类型的，而且集中在SLOT5这块板。马上锁定目标，换板后问题解决。你看，文件名本身就能帮你缩小排查范围。
避坑指南：我曾经遇到日志文件命名里日期格式不统一的情况，有的用20250101，有的用2025-01-01。脚本解析时直接报错。所以，建议团队内部统一命名规范，别搞混搭。
四、日志级别分类
日志级别，说白了就是给问题定个「严重程度」。不是所有日志都需要你半夜爬起来处理，得有个轻重缓急。
OTN设备常见的日志级别，从高到低排列：
| 级别 | 名称 | 含义 | 我的处理建议 |
|---|---|---|---|
| 1 | EMERGENCY（紧急） | 系统不可用，比如主控板宕机 | 立即处理，刻不容缓 |
| 2 | ALERT（警报） | 需要立即响应，比如光缆中断 | 马上派人去机房 |
| 3 | CRITICAL（严重） | 关键功能失效，比如单板脱管 | 当天必须解决 |
| 4 | ERROR（错误） | 功能异常但不影响整体运行 | 安排计划处理 |
| 5 | WARNING（警告） | 潜在风险，比如光功率劣化 | 关注趋势，提前干预 |
| 6 | NOTICE（通知） | 正常但重要的事件，比如配置变更 | 记录备查 |
| 7 | INFO（信息） | 常规运行信息 | 日常巡检时看 |
| 8 | DEBUG（调试） | 开发调试用，生产环境慎开 | 非必要不开启 |
为什么会这样分级？说白了，就是让你在成千上万条日志里，一眼抓住重点。我个人的习惯是：日常只看WARNING及以上级别，DEBUG日志除非厂家要求，否则绝对不开——开过你就知道，那信息量能把硬盘撑爆。
实战经验：有一次半夜被电话叫醒，说设备告警刷屏。我远程一看，全是INFO级别的端口up/down日志。运维小哥把日志级别设成了DEBUG，结果正常操作也被记录成告警。我让他改回WARNING级别，世界清净了。所以，日志级别设置要合理，别矫枉过正。
五、日志轮转与清理
日志文件不能无限增长，否则硬盘早晚爆掉。OTN设备一般都有日志轮转机制：
- 按大小轮转：单个日志文件达到10MB或50MB，自动切分
- 按时间轮转：每天生成一个新文件，旧文件保留30天
- 按数量轮转：最多保留100个日志文件，超出的自动删除
嗯，这里要提醒一句：别把日志保留时间设得太短。我遇到过客户只保留7天日志，结果故障发生在第8天，想查历史数据已经没了。建议至少保留30天，关键设备保留90天。
我的小技巧：定期检查日志目录的磁盘占用，用 df -h 看一眼。如果日志占用了超过50%的磁盘空间，就该考虑扩容或者调整轮转策略了。
好了，日志系统入门就聊到这儿。下一章咱们会深入讲日志解析工具的使用，到时候带着今天的基础知识去实操，效果会更好。记住一句话：日志是设备的「黑匣子」，读懂它，你就能掌控设备的命脉。