1. 课程导论与背景：为什么需要日志检索准入门禁？自监控与告警自愈的核心价值

1.1 从“日志可用”到“日志可信”的演进

在微服务与云原生架构下，日志早已不是简单的排错工具，而是可观测性的三大支柱之一。然而，多数团队仍停留在“日志能查到就行”的阶段，忽略了三个致命问题：

• 日志丢失不可知：采集端异常、磁盘写满、网络抖动导致日志静默丢失，业务故障排查时才发现数据空洞。
• 检索性能不可控：突发流量或错误日志暴增，导致 Loki/Elasticsearch 查询超时，甚至拖垮集群。
• 准入标准缺失：任意应用随意输出高基数标签、超大行日志，污染索引，降低全局检索效率。

传统方案依赖人工巡检和事后复盘，无法在分钟级感知日志管道的健康状态。因此，我们需要一套日志检索准入门禁机制，在数据写入前完成校验、限流、降级，同时构建自监控与告警自愈闭环，让日志系统具备自我修复能力。

1.2 日志检索准入门禁：三道防线

准入门禁并非单一组件，而是贯穿采集、传输、存储三层的一系列策略。下表对比了无门禁与有门禁的差异：

准入门禁的落地通常包含三个环节：

1. 采集端门禁：在 Promtail / Fluent Bit 侧完成标签校验、行大小截断、采样率控制。
2. 传输层门禁：通过 Gateway 或 Sidecar 代理实现速率限制、协议校验、重试策略。
3. 存储端门禁：在 Loki 或 Elasticsearch 侧配置写入配额、索引映射校验、拒绝非法请求。

1.3 自监控与告警自愈：闭环的价值

仅有门禁还不够——门禁本身也可能成为故障点。自监控体系需要覆盖日志管道的全链路：

• 采集端指标：采集速率、丢弃行数、重试次数、内存使用率。
• 传输层指标：请求延迟、错误率、队列积压、连接数。
• 存储端指标：写入 QPS、查询延迟、索引大小、拒绝请求数。
• 门禁自身指标：拦截次数、降级次数、规则命中分布。

告警自愈则是在指标异常时自动触发修复动作，而非仅发送通知。典型场景包括：

1.4 整体架构：准入门禁 + 自监控闭环

下图展示了本课程实践的核心架构，包含日志采集、准入门禁、存储检索、自监控与自愈四个层次：

架构中关键设计点：

• 准入门禁位于采集与存储之间，形成“守门人”角色，拒绝非法数据进入下游。
• 自监控层独立于业务日志管道，使用单独的 Prometheus 实例采集门禁和存储指标，避免故障扩散。
• 自愈反馈回路：当自监控检测到门禁误拦截率过高时，自动回滚最近一次规则变更，并将调整结果写回门禁配置。

1.5 本课程能解决什么？

通过本课程，你将掌握以下核心能力：