用途：在 PostHog 项目中调查日志，用于验证服务或部署是否健康、解释错误激增、进行事故分诊，或了解某个日志流在说什么。核心思路是先汇总再阅读：一次 posthog:logs-patterns 调用可把海量日志压缩为最多 200 个模板，一次 posthog:logs-patterns-diff 直接回答“现在与之前有何不同”。原始行（posthog:query-logs）是调查的最后一步，而非第一步。
主要能力与工具：posthog:logs-services-create 列出前 25 个服务及日志量、错误数、错误率与迷你趋势，用于定位；posthog:logs-patterns 挖掘单个窗口的消息模板并按频率排序；posthog:logs-patterns-diff 对比两个窗口的模板，给出新增、速率变化、消失项；posthog:logs-count 与 posthog:logs-count-ranges 做标量与时间分桶计数；posthog:logs-sparkline-query 按严重级别或服务查看量随时间变化；posthog:logs-facet-values-create 查看过滤条件下的分布；posthog:logs-attributes-list 与 posthog:logs-attribute-values-list 发现属性键值；posthog:query-logs 拉取原始行。
使用方式：按问题形态选择流程。健康检查时先确定变更时间与受影响服务，用 services 调用确认服务仍在记录日志及当前错误率，再用 patterns-diff 对比变更前后窗口，检查是否出现新的 error/fatal 模板或错误模板速率大幅偏移，并用 count-ranges 检查量连续性；通过需同时满足无新错误模板、无大幅错误速率偏移、量连续。解释激增时先用 count-ranges 逐层定位密集桶（3–4 层），再用 patterns-diff 对比激增窗口与前一窗口。事故分诊先用 patterns-diff 对比事故窗口与已知良好窗口，若不知故障服务，先用 facet-values-create 按 service_name 在 error/fatal 下分面。陌生服务用 patterns 看最近一小时模板。已知精确目标时跳过模板挖掘，直接发现键、计数、拉行。
限制与规则：确定目标服务后每次调用都应限定 serviceNames 或资源属性过滤；posthog:query-logs 必须显式提供 query.dateRange，否则返回 400；模板计数为采样估计（sampled: true），稀有模板可能不可见，缺失不代表停止；对比前检查 baseline.total_count，基线过小会让一切看起来是新的；severityLevels 精确匹配六个规范小写桶；预算上建议一次 services 调用、每窗口对最多一次 patterns-diff、3–4 层 count-ranges，query-logs 仅用于确认的嫌疑且 limit ≤ 100。输出应先给结论（健康/回归/不确定及对比窗口），再给嫌疑模板、分类、估计计数或速率比、服务与 1–2 条样本行，最后说明检查与未检查范围及采样或基线注意事项。相关技能：authoring-log-alerts、exploring-apm-traces。