Prometheus：收集指标

（部分： 技术和基础设施）

简短摘要

Prometheus是时间指标的工业标准：它通过HTTP刮掉目标，在TSDB中存储系列，在PromQL中计算聚合物，并通过Alertmanager触发变量。对于iGaming，它是SLO方法（RED/USE，支付业务指标），p95/p99快速诊断和自动解决方案（freeze/rollback）的基础。

1）数据模型和基数

度量标准：'name {label1='v1'，label2='v2'} value@timestamp'。
基数=所有唯一标签集的容量乘积；主要价值因素。

• базовые: `service`, `env`, `region`, `instance`, `pod`, `container`, `version`;
• 域："route"，"psp"，"tenant"（小心！），"game_provider"。
• 不能聚集"user_id"、"session_id"和随机/高心值。

2）指标类型

Counter-仅增长（例如"http_requests_total"）。
Gauge是即时值（例如"queue_depth"）。
Histogram/Summary-潜伏分布。出售的是Histogram（支持"histogram_quantile（）"和exemplars）。
Native Histograms-可变垃圾箱，提高准确性并节省尺寸（包括在可用的地方）。

go var httpLatency = prometheus. NewHistogramVec(
prometheus. HistogramOpts{
Name:  "http_request_duration_seconds",
Help:  "HTTP latency",
Buckets: prometheus. DefBuckets ,//or custom
},
[]string{"route","method"},
)

3）出口商以及衡量标准

服务：您的代码（Go/Java/Node/Python）、RED API度量、业务指标（付款转换）。
系统：node_exporter，cAdvisor/kubelet。
第三方：DB/缓存（mysqld_exporter，postgres_exporter，redis_exporter)，NGINX/HAProxy，Kafka/RabbitMQ。
OTel指标：通过OpenTelemetry Collector → Prometheus Remote Write或Prometheus-receiver →共享堆栈。

4）Scrape和relabel： 如何连接目标

基本的'prometheus。yml`

yaml global:
scrape_interval: 15s evaluation_interval: 15s external_labels:
env: "prod"
region: "eu-west"

scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['10. 0. 1. 10:9100','10. 0. 1. 11:9100']

- job_name: 'payments-api'
metrics_path: /metrics scheme: https tls_config:
ca_file: /etc/ssl/ca. crt cert_file: /etc/ssl/tls. crt key_file: /etc/ssl/tls. key relabel_configs:
- source_labels: [__address__]
regex: '(.):\d+'
target_label: instance replacement: '$1'

Kubernetes через Prometheus Operator

使用ServiceMonitor/PodMonitor代替手动的"scrape_configs"。

yaml apiVersion: monitoring. coreos. com/v1 kind: ServiceMonitor metadata: { name: payments-api }
spec:
selector: { matchLabels: { app: payments-api } }
namespaceSelector: { matchNames: [ "prod" ] }
endpoints:
- port: metrics interval: 15s scheme: http relabelings:
- action: replace targetLabel: service replacement: "payments-api"

K8s注释（无操作员,简化）

yaml metadata:
annotations:
prometheus. io/scrape: "true"
prometheus. io/port: "9102"
prometheus. io/path: "/metrics"

5）存储： TSDB，WAL和重构

WAL（Write-Ahead Log）在重新启动后→快速恢复。
Compaction：压缩块,节省磁盘/CPU。
重建：存储7-30天的热数据；长期耐用（请参阅缩放）。

• `--storage.tsdb.retention.time=15d`
• `--storage.tsdb.max-block-chunk-segment-size`
• 驱动器：快速SSD/NVMe；避免网络卷而无需。

6） PromQL： 基本原理和频繁模式

Rate/irate

promql rate(http_requests_total{route="/deposit"}[5m])

错误和成功率

promql sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95,
sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)

队列/饱和度

promql max(queue_depth{queue="withdrawals"}) by (region)

7）记录规则和性能

提前读取沉重的表达式，并存储为系列。

yaml groups:
- name: api. rules interval: 30s rules:
- record: job:http:request_duration_seconds:p95 expr:
histogram_quantile(0. 95,
sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))
- record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

另外：快速降压板，减少Prometheus CPU的负载。

8) Alerting и SLO (burn rate)

Burn-rate alerta（多窗口、多燃烧）

yaml groups:
- name: slo. payments rules:
- alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 5m labels: { severity: "page" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"
- alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

Alertmanager：跨服务/区域路由、重复数据抑制、ChatOps。

9）与跟踪和日志的相关性

启用exemplars：直方图箱中的点击式"trace_id"。
将"服务"，"版本"和"区域"标签设置为"发布比较"。
在行车记录板上-版本注释（Git SHA/版本）。

10）扩展和长期存储

联邦：顶部Prometheus从底部（通过工作/标签过滤器）聚集。
远程写作：将行发送到长期存储/群集后端（Thanos/Cortex/Mimir）。

优点：无限重构、水平缩放、全局视图。
缺点：更难操作，成本。
按功能划分：系统指标的单独实例、业务、安全。

11）安全性

Prometheus ↔ 目标/Alertmanager/remote_write之间的TLS/mTLS。
基本/令牌身份验证/目标和API（在滚动网关之前）。
RBAC：限制按角色访问UI/系列；隐藏私人标签。
PII卫生：不要将PII写成指标；使用哈希/别名。

12） Kubernetes练习

Prometheus Operator: CRD (ServiceMonitor, PodMonitor, Alertmanager, Prometheus).

kube-state-metrics+cAdvisor →群集的完整图片。
Teynings和资源：用于监测的专用记号；CPU/RAM限制。
降低噪音："生产"neyspace的标签选择器，在可能的情况下scrape_interval围场。

13）商业指标和产品

Платежи: `payments_success_total{psp, currency}`, `payment_conversion_ratio`, `ttw_seconds_histogram`.

游戏活动：投注/分钟，保持会话为高格，失误时失效。
风险/风险：速度/地理异常触发因素；单独编写，度量是聚合。

14）成本和性能（FinOps）

控制基数（在添加新标签之前进行标记）。
Sampling直方图/罕见的出口商→ 'scrape_interval'↑用于非关键目标。
在长期存储后端下载。
行车记录缓存和广泛依赖记录规则。

15）"快速启动"示例"

应用程序中的RED出口商（Python）

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route','method'])
start_http_server(8000)

def handle(req):
with lat. labels(req. route, req. method). time():
status = app(req)
reqs. labels(req. route, req. method, str(status)). inc()
return status

阈值差p95

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }

16）实施支票

1.定义一组基本指标（RED/USE）和域指标。
2.在基数上匹配标签和海德。
3.配置scrape/ServiceMonitor, TLS/mTLS, relabel。
4.启用关键路径和exemplars的直方图。
5.为p95、成功率、业务单元创建记录规则。
6.输入SLO-Alerta（燃烧率）和Alertmanager Ruting。
7.提高行车记录：服务地图,发布比较,付款。
8.决定联盟/remote_write和重建。
9.限制访问（RBAC）,检查是否缺少PII。
10.启用runbooks和游戏日检查。

17）反模式

高基数标签（user/session/request_id)。
用于关键SLO的摘要而不是Histogram →没有"histogram_quantile"。
没有过滤/旋转的Scrape"全部连续"→成本和噪音上升。
根据没有SLO的原始度量标准，Alerta → alert-fattig。
缺乏记录规则→"沉重"的行列。
对没有TLS/mTLS的指标的信心→欺骗/泄漏风险。

结果

Prometheus为iGaming平台提供了与目标相关的可观察性：精确的直方图，稳定的聚集，清晰的SLO同位素以及缩放到多个区域图。标签纪律，正确的记录规则，跟踪/记录链接以及经过深思熟虑的存储体系结构即使在高峰时段也能提供快速发布和可预测的p99。