Alerta系统容量→操作和管理

1）为什么需要它

电容变量警告说，在事件发生前很久就接近技术限制："我们离天花板80%是时候扩大规模了。"对于杂货商来说，这直接是关于金钱：错过投注/存款，会话失误，直播游戏延迟和提供商拒绝=收入损失，声誉，罚款和回扣。

• 可以预见的是承受峰值负荷（活动、锦标赛、流媒体、大型活动）。
• 按时打开自动滑板，并计划容量提升。
• 减少SLO/金钱风险时的噪音并唤醒。
• 通过运行手册向工程师提供准确的建议。

2）基本概念

容量（Capacity）-最大限度地保持吞吐量（RPS/TPS,连接器,IOPS, throughput）。
Headroom：当前负载和限制之间的余量。
SLO/SLA：目标可用性/响应时间级别；Alertes必须是"SLO-aware"。
Burn-rate：SLO预算"燃烧"错误/潜伏的速度。
High/Low Watermark：用于触发和自动恢复的上层/下层。

3）信号架构和数据源

远程计量学：度量（Prometheus/OTel），logi（ELK/ClickHouse），跟踪（OTel/Jaeger）。
分层方法：按层排列（Edge → API →业务服务→队列/流→ DB/缓存 →文件/对象存储→外部提供商）。
背景：ficheflagi，发行版，营销活动，锦标赛，地质布局。
事件总线：Alertmanager/PagerDuty/Opsgenie/Slack；绑定到runbook和升级矩阵。

4）按层划分的关键指标（监视什么以及为什么）

Edge / L7

RPS, 95-99-percentile latency, error rate （5xx/4xx）, open connections.

Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

通过锻炼者/锻炼池，查询队列，定时到下流。
降解比例（fallbacks，电路断路器）。

队列/流媒体（Kafka/Rabbit/Pulsar）

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).

分区skew，重建教堂，ISR（用于Kafka），retrai/祖父。

异步操作员

任务等待时间、队列长度、逾期任务的SLA百分比。
池中的饱和CPU/内存/FD。

缓存（Redis/Memcached）

Hit ratio, latency, evictions, used memory, 连接的客户端/ops/s。
群集：插槽/复制副本,failover事件。

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.

IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

对象/文件存储

PUT/GET latency, 4xx/5xx, egress,查询/秒,提供商限制。

外部提供商（付款/KUS/游戏提供商）

TPS限制，窗口QPS，error rate/timeout，转发队列，"cost per call"。

基础架构

CPU/Memory/FD/IOPS/在节点/pods/ASG上的网络设置。
HPA/VPA事件，pending pods，集装箱OOM/Throttling。

5）电容变量类型

1.静态阈值

简单易懂：'db_connections> 80% max'。好像"信号灯塔"。

2.自适应（动态）阈值

基于季节性和趋势（滚动windows，STL分解）。允许捕获"每周这个小时/天异常高"。

3.SLO定向（burn-rate）

当X时钟视野中的SLO受到错误预算穿越速度的影响时触发。

4.预测（预测）

"在当前趋势下的20分钟内，队列将达到90％。"在短窗口上使用线性/Robust/Prophet样预测。

5.复合（多信号）

结合使用：'queue_lag ↑'+'consumer_cpu 85%'+'autoscaling at max' →"需要手动干预"。

6）阈值政策与反噪音

High/Low Watermark:

上图：70-75%的警告，85-90%的克里特岛。向下：滞后5-10个百分点。不要"冲过门槛"。

• 'for： 5 m' for crits, 'for： 10-15 m' for警告。夜间模式：在没有分页的聊天中漫游非关键。

• 按服务/集群/地质分组,以免发生事故。

Dependency-aware suppression:

如果KYC提供者出局和API错误，则结果是集成所有者而不是所有消费者的分页。

• 在股票期间，提高了"预期增长"的噪音阈值，但使SLO-Alerta保持不变。

7）规则示例（伪普罗米修斯）

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8） SLO方法和业务优先级

从信号到业务影响：容量差异应引用风险到SLO（特定游戏/地理/GGR度量，存款转换）。
分层：呼叫服务警告；克里特岛-域所有者的页面；SLO跌落是主要事件和命令"合并"频道。
Ficheflagi降解：自动减少负载（部分只读负载，减少重型眼镜，降低头奖流浪者的频率，在实时游戏中关闭"重型"动画）。

9）自动滑冰和"正确"触发器

HPA/VPA：目标不仅通过CPU/Memory，而且通过业务指标（RPS，queue lag，p99 latency）。
Warm-up计时：考虑冷启动和供应商限制（ASG分拆,集装箱售票员,缓存加热）。
Guardrails：雪崩状错误生长的停止条件；防护"滑板问题"。
Capacity-playbooks：在何处以及如何添加shard/party/复制副本,如何按区域重新分配流量。

10）过程： 从设计到操作

1.限制映射：收集每个层（max conns、IOPS、TPS、quotas提供商）的"真实"瓶颈限制。
2.预测指标的选择：早于所有人指示哪些信号"在N分钟内打扰"。
3.阈值设计：高/低+SLO-burn+复合。
4.每个克里特岛的运行手册：诊断步骤（"打开什么"，"哪些命令"，"升级到哪里"），三个操作选项：快速绕过，缩放，退化。
5.测试：载荷模拟（chaos/game days），"干启动"警报器，防噪声检查。
6.咆哮和收养：信号所有者=服务所有者。没有主人-没有页面。
7.回顾和调整：每周分析虚假/遗漏的内容；度量标准"MTTA （ack）、MTTD、MTTR、Noise/Signal ratio"。

11）反模式

CPU> 90% ⇒恐慌：与latency/queues没有关联可以正常。
"每个人的一个阈值"：不同的区域/超时区域是不同的流量配置文件。
Alert没有运行手册：没有明确操作的页面会耗尽呼叫。
对提供商的盲目性：外部配额/限额通常是第一个"打破"脚本（PSP，KYC，antifrod，游戏提供商）。
没有滞后：80％/79％的边界处的"锯齿"。

12） iGaming/finplatform功能

日程安排：黄金时段，锦标赛决赛，主要比赛；提前升级目标复制副本并填充缓存。
现场直播和头奖：广播节目激增→经纪人/网站的限制。
付款和KYC：提供商窗口，反欺诈得分；保留备用路线和存款的"宽限期"。
地理平衡：提供商的本地故障-将流量带到有头顶的邻近地区。

责任： 如果风险的利率/头奖损失是即时分页域命令+业务警报.

13）Dashbords（最低设置）

Capacity Overview：按层、前3个风险区、燃烧式SLO排序的头部。

Stream & Queues: lag, backlog growth, consumer saturation, HPA state.

DB&Cache： connects, repl-lag, p95/p99 latency, hit ratio, evictions.

提供者：TPS/窗口/配额，timeouts/errors，呼叫成本。
Release/Feature context： 曲线旁的版本/ficheflagi。

14）实施支票

• "真实"限制和所有者列表。
• 预测指标映射+层之间的链接。
• 静态阈值+滞后。
• SLO-burn-alerta进入关键路径（押金，投注，推出现场游戏）。
• 在队列/流/连接上预测异位。
• 窗口支持/维护；反政治噪音。
• Runbook"以及团队，图表，ficheflags降解。
• 每周分析误报和调整。
• 记录营销活动和活动日历。

15）示例runbook模式（缩写）

信号： "StreamBacklogAtRisk"

目的：防止长度>1000万和延迟处理>5分钟。

1.检查"hpa_desired/max", throttle/oom在pod中。

2.查看"rate（lag）"，按批次分配（skew）。

3.验证经纪人（ISR, under-replicated, network）。

• 在+N上增加consumer-replicas，提升飞行中的最大值。
• 在"关键拓扑"中启用优先池。
• 暂时降低辅助处理/恢复的频率。
• 如果"ASG at max"-要求在云端临时加载；并行-包括重函数的降解。
• 回滚：在'lag <100万'15分钟后返回到"常规流量"配置文件。
• 升级：集群所有者Kafka，然后是SRE平台。

16） KPI和信号质量

Coverage：电容过滤器封闭的关键路径的百分比。
Noise/Signal：每周/每周不超过1个假分页。
MTTD/MTTR：在SLO撞击前≤5分钟检测出电容性事件。
实现性保护：在预防事件中（按事后分列）。

17）快速启动（保守违约）

DB： 75% 连接器警告/IOPS/lat；克里特岛85%，滞后8-10 p.p.

缓存：'hit <0。9'和'evictions> 0'>5 min-警告；'used_mem> 85%'-克里特岛。
队列："lag"身高>3 σ，平均每30 d+'hpa at max'-克里特岛。

API: `p99 > SLO1.3'10 min-警告；'burn-rate> 4'15 min-crit.

提供者："throughput> 90%配额"-警告；"timeouts> 5%"-克里特岛。

18) FAQ

问：为什么不简单地区分"CPU> 80%"？
答：没有后缀/队列上下文是噪音。CPU本身并不等于风险。

问：需要适应性阈值吗？
答：是的，对于每天/每周的季节性-减少假阳性。

问：如何考虑营销/活动？
答：活动日历→图表上的注释+反噪声的时间调整，但SLO-Alerta不触摸。