Golang 日志在 CentOS 上的最佳实践
一 核心选型与输出策略
在 CentOS 上部署 Go 应用，日志选型是第一步。生产环境里，性能与可维护性必须兼顾。因此，结构化日志库是首选——它输出的 JSON 格式日志，天生就为后续的检索、聚合与分析铺平了道路。
具体到库的选择，高性能、低开销的 zap 通常是生产环境的优先选项；如果团队更看重易用性和灵活性，logrus 也是个不错的选择。至于标准库的 log，更适合用在快速验证或极其简单的场景里，毕竟它在结构化支持和性能上有所欠缺。
这里有个小技巧：开发阶段，可以用 zap.NewDevelopment 来获取可读性更好的控制台输出；到了生产环境，则切换到 zap.NewProduction 或相应的 JSON 配置。为了兼顾本地排查的便利性，完全可以同时将日志输出到控制台和文件，并为两者配置不同的编码器——控制台用易读的格式，文件则用结构化的 JSON。
实现起来并不复杂。以 zap 为例，通过 zapcore.NewTee 合并多个 core，就能轻松实现多路输出。而 logrus 则可以通过 WithFields 来为日志添加上下文信息，让每一条日志都“有据可查”。
二 日志轮转与系统整合
日志文件可不能无限增长，否则迟早会撑满磁盘。轮转策略，就是用来解决这个问题的。通常有两种思路：应用内轮转和系统级轮转。
应用内轮转，比如使用 lumberjack 库，可以直接在代码中控制单个日志文件的大小、备份数量以及保留天数。这种方式特别适合容器化部署，或者那些无法依赖宿主机系统工具的场景。典型的配置参数可以参考：MaxSize=10（单位 MB）、MaxBackups=3、MaxAge=28（天），以及 Compress=true 开启压缩以节省空间。
系统级轮转，则是 CentOS 这类 Linux 发行版的“传统艺能”。利用系统预装的 logrotate 工具，可以统一管理所有应用的日志生命周期，实现运维的标准化。一个典型的配置文件（例如放在 /etc/logrotate.d/myapp）可能长这样：
/var/log/myapp/*.log {
daily
missingok
rotate 7
compress
notifempty
create 0640 root root
}那么，两种方式怎么选？其实可以协同工作。让应用内轮转负责“快速的切割与短期保留”，而把“统一的清理、压缩和长期归档”交给系统级的 logrotate。这样既能保证实时性，又能实现全局的资源管控。
三 目录权限与运行配置
日志写到哪里、怎么写入，直接关系到服务的稳定性和可维护性。
首先，日志目录与权限要规划好。遵循 Linux 惯例，将日志写入 /var/log/myapp/ 这类标准目录是个好习惯。记得提前创建目录并设置合适的权限（例如 0755），日志文件本身的权限建议设为 0640。最关键的一点：文件的属主和属组，一定要与运行该服务的系统用户保持一致，否则很可能因为权限问题导致日志写入失败。
其次，考虑服务编排与标准输出。如果你的服务是通过 systemd 管理的，那么一个推荐的做法是：将日志直接输出到标准输出（stdout）和标准错误（stderr）。这样一来，日志可以由 systemd 的 journald 或者容器运行时（如 Docker）自动收集，便于集中查看。而文件日志，则可以专门用于需要长期留存或审计的场景。两者并行不悖，分别服务于实时采集和归档留存的不同需求。
最后，别忘了进程退出前的刷盘。日志库的缓冲区可能不会立即将数据写入磁盘。因此，在程序正常退出、或者遇到关键错误即将退出时，务必调用一下 logger.Sync()（在 zap 中）或等效的刷盘方法。这个简单的步骤，能有效避免缓冲区内的宝贵日志在进程崩溃时丢失。
四 性能与可靠性要点
日志记录本身不能成为系统的性能瓶颈，更不能在出问题时“哑火”。以下几个要点需要关注：
合理设置日志级别：这是最直接的性能优化。开发环境可以放开到 DEBUG 级别以便排查，但生产环境务必收紧，通常 INFO 或 WARN 级别就足够了，能大幅减少不必要的日志开销。
减少字符串拼接：在记录日志时，尽量避免使用 fmt.Sprintf 进行字符串拼接，尤其是在高频调用的代码路径中。应该直接使用日志库提供的结构化字段传参方法（如 zap 的 zap.String、zap.Int）。这样做不仅更安全，避免了潜在的格式化错误，也为后续的日志检索提供了便利。
错误包装与堆栈：处理错误时，推荐使用 fmt.Errorf(“…: %w”, err) 的方式进行包装，这样可以保留完整的错误因果链。同时，在记录错误或关键日志的位置，应该记录下调用者信息（Caller）甚至堆栈（Stacktrace）。像 zap 就可以通过配置 CallerKey 和 StacktraceKey 来轻松实现。
处理 panic：通过 recover 捕获 panic 是 Go 服务的标配。在 recover 的逻辑里，务必记录下 panic 的具体信息和堆栈，这是服务可观测性和事后诊断的关键。
缓冲与异步：对于性能极其敏感的场景，可以考虑启用日志的缓冲或异步写入模式。例如，zap 就提供了 BufferedWrite 的选项，或者可以配置多个 core 进行并行输出。当然，别忘了我们前面提到的，在关键节点需要手动触发 Sync 来确保日志落盘。
五 集中化采集与监控告警
当服务数量增长后，登录一台台服务器去查看日志就变得不现实了。这时，就需要走向集中化。
日志收集与可视化：将分布在所有 CentOS 服务器上的日志，统一采集到一个中心平台。经典的 ELK 栈（Elasticsearch, Logstash, Kibana）或 Graylog 都是成熟的选择。也可以使用 Fluentd 这样的采集袋里，负责收集、过滤并转发日志。集中之后，全文检索、多维分析和可视化仪表盘就都成为可能了。
监控与告警：日志不能只用于事后排查，更应该用于事前预警。结合 Prometheus 和 Grafana，可以建立基于日志的错误率、特定接口延迟等关键指标的面板。更进一步，可以设置阈值告警规则。当错误日志激增，或出现特定的错误码、关键字时，告警系统能主动通知到负责人，从而实现问题的快速发现与响应。
