Swoole的日志记录主要通过配置服务器参数实现，将运行时信息输出到指定文件，而日志文件的管理则是一项系统工程，涉及轮转、清理和监控，以确保系统稳定运行并方便故障排查。
解决方案
Swoole服务器的日志记录核心在于
SwooleServer
的
set
方法，通过设置
log_file
参数来指定日志文件的路径。这是一个非常直接的方式，Swoole会将内部的错误、警告、信息等按配置的日志级别写入这个文件。在协程环境中，你也可以利用
SwooleCoroutineLog
组件进行更灵活的日志输出，比如打到标准输出或者自定义的回调函数。
<?php $http = new SwooleHttpServer("0.0.0.0", 9501); $http->set([ 'worker_num' => 4, 'daemonize' => false, // 调试模式下设为false，方便查看控制台输出 'log_file' => '/var/log/swoole/swoole.log', // 指定日志文件路径 'log_level' => SWOOLE_LOG_INFO, // 设置日志级别 // 'display_errors' => 'stderr', // 也可以将错误输出到标准错误 ]); $http->on('request', function ($request, $response) { $response->header('Content-Type', 'text/plain'); $response->end("Hello Swoolen"); // 在协程中记录日志 SwooleCoroutineLog::info("收到新的请求: " . $request->server['request_uri']); }); $http->on('start', function ($server) { echo "Swoole http server is started at http://127.0.0.1:9501n"; }); $http->start();
除了服务器层面的日志，业务逻辑中的日志记录通常会结合PHP的通用日志库，如Monolog，然后通过Monolog的Handler将日志导向Swoole的
log_file
，或者直接通过
SwooleCoroutineLog
输出。
Swoole日志级别有哪些？如何选择合适的级别？
Swoole提供了几种不同的日志级别，用来控制输出日志的详细程度。这就像是你在调试一个复杂系统时，可以选择是看最粗略的概览，还是深入到每一个微小的操作细节。了解并合理选择日志级别，对于生产环境的性能和问题排查至关重要。
这些级别包括：
-
SWOOLE_LOG_DEBUG
: 最详细的调试信息，通常只在开发和调试阶段使用。生产环境开启这个级别可能会产生海量的日志，迅速耗尽磁盘空间，并且对性能有一定影响。
-
SWOOLE_LOG_TRACE
: 比DEBUG更详细，会输出函数调用栈信息，用于追踪代码执行路径。同样，只在极端问题排查时临时开启。
-
SWOOLE_LOG_INFO
: 一般信息，比如服务启动、停止、Worker进程管理等。这是生产环境常用的级别，能让你了解服务的运行状态。
-
SWOOLE_LOG_NOTICE
: 值得注意的事件，比如某些配置警告、连接断开等，这些事件不一定是错误，但可能需要关注。
-
SWOOLE_LOG_WARNING
: 警告信息，表示可能存在问题，但服务仍在运行。比如资源耗尽的边缘、非致命的连接错误。
-
SWOOLE_LOG_ERROR
: 错误信息，表示发生了严重问题，可能导致服务部分功能失效或整体崩溃。这是你最需要关注的级别。
-
SWOOLE_LOG_NONE
: 不输出任何日志。这通常不推荐，除非你确定有其他完善的日志收集机制，并且Swoole的内部日志对你来说完全不重要。
选择合适的日志级别，我个人经验是，生产环境一般将
log_level
设置为
SWOOLE_LOG_INFO
或
SWOOLE_LOG_NOTICE
。这样既能获取到服务的关键运行状态，又不会因为日志量过大而造成磁盘压力。当线上出现问题需要深入排查时，可以临时将级别调高到
SWOOLE_LOG_DEBUG
或
SWOOLE_LOG_TRACE
，但务必在问题解决后及时调回，避免不必要的资源消耗和安全风险。开发和测试环境则可以随意开启
DEBUG
级别，以获取尽可能多的信息。
Swoole日志文件过大怎么办？日志轮转和清理策略探讨
日志文件无限增长是一个常见的运维噩梦，它能轻易地把服务器硬盘撑爆，导致服务崩溃。我见过不少线上事故，都是日志文件把磁盘撑爆了，结果服务直接挂掉，所以日志管理绝不是小事。对于Swoole的日志文件，我们必须有明确的轮转和清理策略。
最常见且推荐的做法是使用linux系统自带的
logrotate
工具。
logrotate
是一个功能强大且高度可配置的日志文件管理工具，它可以自动对日志文件进行切割、压缩、删除，并可以在切割后执行自定义命令（比如通知Swoole重新打开日志文件句柄）。
一个简单的
logrotate
配置示例（通常放在
/etc/logrotate.d/swoole
）：
/var/log/swoole/swoole.log { daily # 每天轮转 rotate 7 # 保留7个轮转文件 compress # 压缩旧的日志文件 delaycompress # 延迟压缩，直到下一个轮转周期 missingok # 如果日志文件不存在，不报错 notifempty # 如果日志文件为空，不轮转 create 0644 root root # 如果日志文件不存在，创建它，并设置权限 postrotate # 轮转后执行的命令 # 这一步非常关键，通知Swoole重新打开日志文件句柄 # 可以通过向Swoole主进程发送USR1信号实现 # 或者重启服务（不推荐，会中断服务） # 如果你的Swoole版本支持热加载log_file，这里可以放一个reload命令 # kill -USR1 `cat /var/run/swoole.pid` # 假设你的pid文件在这里 # 或者更稳妥的方式是重启Swoole服务，但会中断业务 /usr/bin/pkill -USR1 -F /var/run/swoole.pid # 假设pid文件路径 endscript }
postrotate
部分是关键，因为Swoole进程会一直持有日志文件的句柄。当
logrotate
将旧的日志文件重命名后，Swoole仍然会往旧的文件句柄对应的 inode 上写入内容，导致新的日志文件为空。所以，需要通知Swoole重新打开
log_file
。这通常通过向Swoole主进程发送
USR1
信号来实现，Swoole收到信号后会重新加载配置并打开新的日志文件。
除了
logrotate
，你也可以编写自定义脚本，通过cron定时任务来执行日志切割和清理。这在一些特殊场景下可能更灵活，但增加了维护成本。清理策略则主要围绕保留周期，比如只保留最近7天或30天的日志，更旧的日志可以删除或归档到成本更低的存储中。
除了文件日志，Swoole日志还能怎么记录？集中化日志系统集成实践
当你的服务规模上去了，或者采用了微服务架构，仅仅将日志记录到本地文件会变得非常低效和难以管理。想象一下，几十上百台服务器，每台都有自己的日志文件，你要怎么快速定位一个跨服务的问题？集中化日志系统几乎是标配。
Swoole的日志除了可以写入本地文件，还可以通过多种方式输出到集中化日志系统：
-
发送到Syslog: Swoole可以配置将日志发送到系统的syslog服务。syslog是Linux系统标准的日志服务，它可以将日志转发到远程的syslog服务器。这是一种比较传统但有效的方式。
$server->set([ 'log_file' => '/dev/null', // 不写入本地文件 'log_level' => SWOOLE_LOG_INFO, 'log_output_buffer_size' => 8192, // 缓冲区大小 'enable_syslog' => true, // 启用syslog // 'syslog_facility' => LOG_LOCAL0, // 可以指定syslog的facility ]);
开启
enable_syslog
后，Swoole的内部日志就会通过syslog协议发送。
-
集成PHP日志库 (如Monolog) 到远程服务: 这是最灵活和强大的方式。你可以在Swoole应用中使用Monolog这样的PHP日志库，然后配置Monolog的Handler将日志发送到各种远程日志服务。
- ELK Stack (elasticsearch, Logstash, Kibana): Monolog可以通过
SocketHandler
、
AmqpHandler
等将日志发送到Logstash，Logstash再处理后存入Elasticsearch，最后通过Kibana进行可视化和查询。
- Loki: 如果你习惯使用grafana，Loki是一个不错的选择。Monolog可以通过HTTP Handler将日志以json格式发送到Loki的API。
- graylog/Splunk: 类似的，这些专业的日志管理平台也都有对应的API或协议，Monolog可以轻松集成。
- 消息队列: 将日志异步推送到kafka、rabbitmq或redis列表，然后由专门的日志消费者服务从队列中取出并存储到数据库、数据湖或集中化日志系统。这种方式可以解耦日志生产和消费，提高系统吞吐量。
这种方式的优势在于：
- 集中管理: 所有服务的日志都汇聚到一个地方，方便统一查询、分析和监控。
- 实时性: 日志可以近乎实时地被收集和索引，便于快速响应问题。
- 可观测性: 结合监控和告警系统，可以基于日志内容触发告警，实现更全面的可观测性。
- 可扩展性: 集中化系统通常具备良好的扩展性，能够处理海量的日志数据。
- ELK Stack (elasticsearch, Logstash, Kibana): Monolog可以通过
在实践中，我会倾向于在业务代码中使用Monolog，并根据环境配置不同的Handler。例如，开发环境可能直接输出到控制台或本地文件，测试环境输出到测试日志服务器，而生产环境则通过udp或HTTP异步发送到日志收集器（如Logstash或Fluentd），再由收集器转发到Elasticsearch集群。这不仅解决了日志存储和管理问题，更是提升了整个系统的可观测性和问题排查效率。
