自托管一旦有"一个请求穿过多个服务"（前端 → 网关 → 多个后端 → 数据库/缓存），出问题时"到底是哪个环节慢"就成了一团浆糊：每个服务都说自己迟,却拼不出整条链路的时序。OpenTelemetry（OTel）是"统一可观测性"的标准框架：它用 trace...

自托管服务一多，"日志到哪儿去"就成了真问题：看 docker logs 只能看单个容器、重启就没历史、想跨服务按时间检索/聚合基本靠人工；而"日志要不要长期留、怎么统一收、怎么既好查（全文）又好统计（聚合）"是两条不同的路。成熟的落地是"采集 - 传输 - ...

监控里有一个"看得见却说不清"的盲区：Prometheus 能告诉你"这个 API 的延迟变高了"，但它说不清"这个请求到底慢在哪个环节、是被哪一层拖住的"。当系统是"网关 → 认证 → 服务 → 数据库 → 缓存"这样一层套一层时，想知道"一次请求慢的这 2...

自托管最阴险的事故，不是报错，而是"机器其实已经病了，但没人发现"。磁盘悄悄写满、内存被某个进程吃光、某个服务从昨晚起就不通了——等到用户叫起来才去查，往往已经晚了。Prometheus + Grafana 这套组合解决的正是"尽早、主动地看见这台机器的状态"...

服务器出问题时，最快的定位方式还是翻日志——但前提是你找得到日志在哪。十几台容器各自把 stdout 写到本机，真要排障就是一台台 docker logs 来回问，还跨不过历史的窗口。前面我们用 Prometheus 管好了"指标"（数值型状态），这轮用 Lo...