CentOS 下 Golang 日志管理实用技巧
一 日志库选择与基础配置
选型这事儿，直接关系到后续维护的便利性。生产环境里，咱们优先考虑那些支持结构化、性能又足够强悍的日志库。目前社区里，zap（来自Uber）和logrus是两大热门选择：前者性能卓越且高度可定制，后者则以上手快、生态丰富著称。如果只是简单的调试场景，标准库的log包也完全够用。
具体操作上，有个小细节值得注意：开发阶段可以用zap.NewDevelopment()，输出更易读的日志；到了生产环境，则切换为zap.NewProduction()。别忘了，程序退出前务必调用一下logger.Sync()，确保缓冲区里的“尾巴”日志能安全落盘，避免丢失关键信息。
还有一点，尽量避免用字符串拼接的方式记录日志。多使用结构化字段来承载上下文信息，比如zap.String()、zap.Int()这些方法，能让日志内容一目了然。为了方便日后检索，最好统一日志的时间格式、服务名、实例或主机名等核心字段，这算是为未来的自己铺路。
二 输出目标与多路写入
实际场景中，我们常常需要日志既能实时在控制台看到，又能持久化到文件里。这在zap里很容易实现，核心就是利用zapcore.NewMultiCore或zapcore.NewTee来组合多个WriteSyncer。
举个例子，你可以为控制台配置一个可读性强的ConsoleEncoder，级别设为Debug；同时为文件配置一个结构化的JSONEncoder，级别设为Info。对于文件输出，强烈推荐搭配lumberjack来实现日志轮转，比如设置单文件最大5MB、保留3个备份、日志最长保存28天，并开启压缩。
如果是标准库log或者logrus，虽然也能通过os.OpenFile或log.SetOutput写入文件，但涉及到轮转和多路写入这种复杂操作，还是交给lumberjack或者系统级的日志工具更省心。
三 日志轮转与保留策略
日志文件不能无限增长，轮转策略是关键。这里主要有两种思路：
应用内轮转：适合容器化部署或者无法依赖宿主机系统工具的环境。方法就是直接将lumberjack.Logger嵌入到日志库（如zap、logrus）的配置里，通过MaxSize、MaxBackups、MaxAge、Compress这几个参数来控制文件的大小、数量、保存时长和压缩。
系统级轮转：在传统的CentOS服务器上，用系统自带的logrotate是更通用的做法。只需在/etc/logrotate.d/目录下为你的应用（比如myapp）创建一个配置文件即可。一个典型的策略可能包含这些指令：按天轮转（daily）、保留7份（rotate 7）、压缩旧日志（compress），并设置创建新文件时的权限（create 640 root root）。
需要警惕的是，CentOS的crond默认会定时执行logrotate，所以咱们千万别自己再额外添加每分钟触发的cron任务了，否则很容易和系统机制冲突，导致轮转混乱。
四 与 systemd 和 rsyslog 集成
如果你的服务是用systemd托管的，那么日志集成会非常方便。在服务的单元文件（如/etc/systemd/system/app.service）里，配置StandardOutput=journal和StandardError=journal，之后就能用journalctl -u app.service命令来统一查看日志了。当然，你也可以选择将标准输出和错误重定向到文件，然后用Supervisor或systemd自身来管理这些文件。
当服务数量多起来后，集中化管理就成了刚需。这时可以请出老牌工具rsyslog。基本思路是：让应用将日志写入本地syslog，然后由rsyslog根据配置的规则进行转发、过滤和落盘。你可以通过journalctl或者直接查看/var/log/messages等文件来检索日志。这种方式特别适合需要统一日志接入、实施集中化存储和审计策略的中大型环境。
五 错误记录、性能与集中化
说到错误处理，有些技巧能让排查效率倍增。包装错误时，推荐使用fmt.Errorf(“…: %w”, err)这样的格式，它能完整保留错误的因果链和堆栈信息。在HTTP服务中，可以在入口中间件里生成并注入唯一的RequestID，然后通过logger.With(…)将这个ID透传到后续所有日志中，这样就能轻松串起一次请求的完整生命周期了。对于未捕获的panic，一定要用recover在顶层兜住，并记录下关键的现场信息。
性能方面，高并发场景下，结构化日志+异步写入是黄金组合。在zap中，通过精心组合不同的Core并制定合理的Sync策略，可以在日志的可靠性和写入性能之间找到最佳平衡点。核心优化方向是减少全局锁竞争和避免频繁的系统调用。
最后，日志的终极价值在于分析和利用。将日志统一输出为JSON格式，无论是落到文件还是syslog，都可以轻松接入ELK（Elasticsearch, Logstash, Kibana）或Graylog这类集中化日志平台。关键在于，提前为所有日志约定好统一的字段，比如time、level、service、instance，这样后续的检索、聚合、可视化乃至告警规则的配置，都会变得事半功倍。
