hyperf 可观测性方案大全

---1)日志（结构化日志、ELK） 大白话 日志就像飞机黑匣子。 出了问题你要能回答三件事：1. 谁请求的（user_id、trace_id）2. 做了什么（接口、参数、结果）3. 什么时候慢/错了（耗时、错误栈） 结构化日志就是把日志写成 JSON，不是乱七八糟一行字符串。这样 ES 才好查、Kibana 才好看。 Hyperf 示例：写结构化日志（JSON）<?php namespace App\Controller;use Hyperf\Logger\LoggerFactory;use Hyperf\Di\Annotation\Inject;class OrderController{#[Inject]protected LoggerFactory$loggerFactory;publicfunctioncreate(){$logger=$this->loggerFactory->get('app','default');$start=microtime(true);try{// 业务代码...$orderId=12345;$logger->info('order_create_success',['event'=>'order_create','order_id'=>$orderId,'user_id'=>1001,'cost_ms'=>(int)((microtime(true)-$start)*1000),'trace_id'=>\Hyperf\Context\Context::get('trace_id'),]);return ['order_id'=>$orderId];} catch(\Throwable $e){ $logger->error('order_create_fail',[ 'event'=>'order_create','user_id'=>1001,'error'=>$e->getMessage(),'trace_id'=>\Hyperf\Context\Context::get('trace_id'),]);throw $e;} } } ELK 怎么接-Filebeat 收集日志文件-Logstash/Ingest Pipeline 处理-Elasticsearch 存储-Kibana 查询看板 关键点：日志里一定带 trace_id，后面链路追踪能串起来。---2)指标（Prometheus+Grafana） 大白话 日志是“看细节”，指标是“看体温”。 你每天盯的核心指标通常就这些：-QPS（每秒请求数）-错误率（5xx 比例）-延迟（P95/P99）-Redis/MySQL 连接状态 Hyperf 示例：打业务指标 下面用 Counter+Histogram（计数+耗时分布）：<?php namespace App\Service;use Prometheus\CollectorRegistry;use Hyperf\Di\Annotation\Inject;class PayService { #[Inject] protected CollectorRegistry $registry;public function pay(int $userId,float $amount):void { $counter=$this->registry->getOrRegisterCounter('biz','pay_total','Total pay requests',['result']);$histogram=$this->registry->getOrRegisterHistogram('biz','pay_cost_ms','Pay cost in ms',['api'],[10,30,50,100,200,500,1000]);$start=microtime(true);try {//业务逻辑... $counter->inc(['success']);} catch(\Throwable $e){ $counter->inc(['fail']);throw $e;} finally { $costMs=(microtime(true)-$start)*1000;$histogram->observe($costMs,['pay']);} } } Prometheus 定时抓/metrics，Grafana 画图。 最实用面板：QPS+错误率+P95+下游依赖耗时 四联图。---3)链路追踪（OpenTelemetry） 大白话 链路追踪就是给一次请求发“快递单号”。 请求经过网关->订单服务->库存服务->支付服务，整个路径和每段耗时都能看到。 Hyperf 示例：手动埋 Span<?php namespace App\Service;use OpenTelemetry\API\Trace\TracerInterface;use Hyperf\Di\Annotation\Inject;class StockService { #[Inject] protected TracerInterface $tracer;public function deduct(int $skuId,int $num):void { $span=$this->tracer->spanBuilder('stock.deduct')->startSpan();$scope=$span->activate();try { $span->setAttribute('sku_id',$skuId);$span->setAttribute('num',$num);//扣库存逻辑... usleep(20000);$span->setAttribute('result','success');} catch(\Throwable $e){ $span->recordException($e);$span->setAttribute('result','fail');throw $e;} finally { $scope->detach();$span->end();} } } 配 OTLP 导出到 Jaeger/Tempo，就能看到完整调用链。 日志里加同一个 trace_id，排障速度会快很多。---4)告警策略 大白话 告警不是“越多越好”，是“能叫醒人且真有事”。 常见坑：阈值太敏感，半夜一直误报，最后大家都静音了。 实战策略（推荐）1.分级-P1：核心不可用（立刻电话）-P2：性能明显下降（企业微信/钉钉）-P3：趋势异常（白天处理）2.多窗口（短窗口+长窗口） 避免瞬时抖动误报。3.按业务SLO告警 比如“5分钟错误率>2%且 QPS>50”。 Prometheus 告警规则示例 groups:-name:hyperf-alerts rules:-alert:HighErrorRate expr:|(sum(rate(http_requests_total{status=~"5.."}[5m]))/ sum(rate(http_requests_total[5m])))>0.02and sum(rate(http_requests_total[5m]))>50for: 10m labels: severity: P1 annotations: summary:"HyPerf 5xx 错误率过高"description:"5xx错误率连续10分钟超过2%，且请求量>50rps"- alert: HighP95Latency expr:|histogram_quantile(0.95, sum(rate(http_request_duration_ms_bucket[5m]))by(le))>300for: 10m labels: severity: P2 annotations: summary:"HyPerf P95 延迟过高"description:"P95 连续10分钟大于300ms"---5)一套能直接上的 Hyperf 可观测性最小方案 - 日志：JSON结构化 + trace_id + ELK 检索 - 指标：QPS/错误率/P95/依赖耗时 + Grafana 四联图 - 追踪：OpenTelemetry 打通服务链路 - 告警：按 SLO 分级，多窗口，先控误报再扩覆盖 先把这套最小闭环跑起来，你的线上排障效率会明显上一个台阶。