hyperf 可观测性方案大全

---1)日志结构化日志、ELK 大白话 日志就像飞机黑匣子。 出了问题你要能回答三件事1. 谁请求的user_id、trace_id2. 做了什么接口、参数、结果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);$startmicrotime(true);try{// 业务代码...$orderId12345;$logger-info(order_create_success,[eventorder_create,order_id$orderId,user_id1001,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,[ eventorder_create,user_id1001,error$e-getMessage(),trace_id\Hyperf\Context\Context::get(trace_id),]);throw $e;} } } ELK 怎么接-Filebeat 收集日志文件-Logstash/Ingest Pipeline 处理-Elasticsearch 存储-Kibana 查询看板 关键点日志里一定带 trace_id后面链路追踪能串起来。---2)指标PrometheusGrafana 大白话 日志是“看细节”指标是“看体温”。 你每天盯的核心指标通常就这些-QPS每秒请求数-错误率5xx 比例-延迟P95/P99-Redis/MySQL 连接状态 Hyperf 示例打业务指标 下面用 CounterHistogram计数耗时分布?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]);$startmicrotime(true);try {//业务逻辑... $counter-inc([success]);} catch(\Throwable $e){ $counter-inc([fail]);throw $e;} finally { $costMs(microtime(true)-$start)*1000;$histogram-observe($costMs,[pay]);} } } Prometheus 定时抓/metricsGrafana 画图。 最实用面板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%且 QPS50”。 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 分级多窗口先控误报再扩覆盖 先把这套最小闭环跑起来你的线上排障效率会明显上一个台阶。