Webman进程监控与日志上报教程

Webman自定义进程的稳定运行远不止写个任务类那么简单，它深度依赖Workerman的生命周期管理机制，稍有疏忽就会导致进程静默退出、日志丢失、上报阻塞或无法重启——本文直击五大高频痛点：从命名空间与可见性校验、Windows启动方式陷阱、日志必须走独立Channel而非echo输出，到远程上报应绕过Monolog改用异步批量提交，再到必须显式处理SIGTERM信号与规范exitCode以触发自动拉起，每一步都关乎生产环境的可靠性与可观测性。

自定义进程不执行？检查 config/process.php 和 handler 类的可见性

Webman 的自定义进程本质是 Workerman 的 Worker 实例，必须确保类文件能被自动加载、构造方法参数匹配、且类声明为 public。常见错误是把 app\TaskTest 类写成 class TaskTest 但没加 namespace app;，或在 config/process.php 中写错类名（比如漏了 app\ 前缀）。

实操建议：

• 确认 config/process.php 返回的数组中，'handler' 值是完整命名空间路径，如 app\TaskTest::class
• 确保 app/TaskTest.php 文件顶部有 namespace app;，且类定义为 class TaskTest（非 final class 或 abstract）
• onWorkerStart() 方法必须是 public，且不能带类型提示（如 public function onWorkerStart(Worker $worker) 会失败——Workerman 不传参，只调用）
• Windows 下必须用 php windows.php start 启动，否则自定义进程不会运行

定时任务日志不输出？别依赖 echo，要用 Log::channel()

在 onWorkerStart() 里用 echo 或 var_dump() 看不到输出——因为自定义进程没有标准输出重定向到控制台，且多进程下 echo 内容会混在一起、无法归属。

实操建议：

• 所有日志统一走 Log::channel('task')->info('xxx')，并在 config/log.php 中为 'task' channel 单独配置 RotatingFileHandler
• 避免在 Timer::add() 回调里直接写 Log::error()，应先捕获异常再记录，例如：

  Timer::add(30, function () {
      try {
          Db::table('orders')->where('status', 'pending')->update(['status' => 'checking']);
      } catch (\Throwable $e) {
          Log::channel('task')->error('order check failed: ' . $e->getMessage(), ['trace' => $e->getTraceAsString()]);
      }
  });

• 如果发现日志没写入，先检查 config/log.php 中该 channel 的 'path' 目录是否存在、权限是否正确（如 www-data 可写）

上报日志到远程服务？绕过 Monolog 默认 handler，手动 POST 更可控

Monolog 的 SocketHandler 或 CurlHandler 在 Webman 多 worker 场景下容易因连接复用、超时、阻塞导致主请求变慢。生产环境更推荐「异步触发 + 队列缓冲 + 批量上报」模式。

实操建议：

• 在自定义进程中用 Swoole\Coroutine\Http\Client 异步发日志，不阻塞主线程：

  Timer::add(60, function () {
      $logs = \support\Db::table('log_buffer')->where('sent', 0)->limit(100)->get();
      if ($logs) {
          go(function () use ($logs) {
              $client = new \Swoole\Coroutine\Http\Client('api.your-log.com', 443, true);
              $client->set(['timeout' => 5]);
              $client->post('/v1/batch', json_encode(['items' => $logs]));
              if ($client->statusCode === 200) {
                  \support\Db::table('log_buffer')->where('id', 'in', array_column($logs, 'id'))->update(['sent' => 1]);
              }
          });
      }
  });

• 不要在每次 Log::channel('xxx')->xxx() 时都触发 HTTP 请求；而是先写入本地数据库或 Redis 队列，由独立进程批量拉取上报
• 远程接口需支持幂等性：同一 log_id 重复提交应返回成功，避免因网络重试造成日志重复

进程崩溃后不重启？补上 exitCode 和 SIGTERM 捕获

Webman 自定义进程默认不监听 SIGTERM，当系统发信号终止时可能直接退出、不执行清理逻辑；若进程异常退出且未设 exitCode，Workerman 不会自动拉起新进程。

实操建议：

• 在 onWorkerStop() 中做资源释放（如关闭 DB 连接、断开 Redis），并显式调用 exit(0)
• 在 onWorkerStart() 开头加 pcntl_signal(SIGTERM, function () { exit(0); });，确保收到终止信号时优雅退出
• 若进程内发生未捕获异常，应在 try/catch 最外层记录错误后调用 exit(1)，让 Workerman 触发重启
• 检查 config/process.php 中是否误设 'count' => 0 或 'enable' => false

Webman 的自定义进程不是“写完就跑”，它和 Workerman 共享生命周期管理机制；最容易被忽略的是信号处理与退出码约定——没设 exit(1) 的崩溃，看起来就像“静默消失”。

文中关于Webman的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Webman进程监控与日志上报教程》文章吧，也可关注golang学习网公众号了解相关技术文章。