滑动窗口是处理连续日志流中动态极值指标最直接有效的算法模式；按驱动方式分为时间窗口（如最近60秒，适用于sla类指标）和计数窗口，兼顾时效性与低开销。
滑动窗口是处理连续日志流中动态极值指标（如最大响应延迟、峰值qps、最小空闲线程数）最直接有效的算法模式——关键不在于维护整个历史，而是在固定时间或数量窗口内实时更新极值，兼顾时效性与低开销。
明确窗口类型：时间驱动 or 计数驱动
日志流天然具有时间戳，但实际选型需看监控目标：
- 时间窗口（如最近60秒）：适合 SLA 类指标（如“99% 请求耗时
- 计数窗口（如最近1000条日志）：适合吞吐类指标（如“每千条请求中的错误数”），实现更简单：用固定长度数组 + 循环索引，或 deque 控制长度，插入即弹出最老项。
高效更新极值：避免每次遍历
若每次窗口滑动都扫描全量数据求 max/min，复杂度退化为 O(n)，无法应对高吞吐日志流。应采用单调队列（Monotonic Deque）：
- 维护一个递减双端队列存 可能成为当前窗口最大值的候选值索引（按值从大到小）；
- 新元素入队前，从队尾弹出所有 ≤ 它的旧值（它们已不可能成为后续窗口最大值）；
- 队首始终是当前窗口最大值；滑出窗口的元素若在队首，才从队首移除。
- 同理，最小值用递增队列。单次操作均摊 O(1)。
适配日志流特性：乱序、突发、多维度
真实日志流不是理想序列，需针对性加固：
- 乱序容忍：接收日志时先缓存（如 5 秒缓冲区），按时间戳排序后再送入滑动窗口；或改用“事件时间 + 允许延迟”模型（类似 Flink 的 watermark）。
- 突发流量保护：限制窗口内日志处理速率（如每秒最多消费 1 万条），超速日志暂存或采样（如哈希后保留 10%）。
- 多指标并行提取：不要为每个指标建独立窗口。共享同一套滑动结构，每个日志 entry 携带多个字段（latency_ms、status_code、bytes_sent），各指标分别维护自己的单调队列。
落地建议：从原型到生产
初期可用 Python deque + heapq 快速验证逻辑；上线前必须考虑：
- 内存控制：窗口大小需有硬上限（如最多存 10 万条），超限时自动丢弃最老批次；
- 状态快照：支持定时 dump 当前窗口状态，用于故障恢复或离线比对；
- 指标导出：将窗口极值封装为 Prometheus Gauge 或 OpenTelemetry Histogram，对接现有监控体系；
- 异常降级：当窗口更新延迟 > 阈值（如 200ms），自动切到上一周期值并告警，避免雪崩式误报。
