遥测和事件收集

1）任命和原则

• 分析、防冻、RG、合规和ML的单一和可预测的事件流。
• 端到端跟踪（user/session/request/trace）和可重现性。
• 最小化PII并满足隐私要求。

Принципы: schema-first, privacy-by-design, idempotency-by-default, observability-by-default, cost-aware.

2）事件分类

付款： '付款。deposit`, `payment.withdrawal`, `payment.chargeback`.

游戏： "游戏。session_start/stop`, `game.bet`, `game.payout`, `bonus.applied`.

自定义： 'auth。login`, `profile.update`, `kyc.status_changed`, `rg.limit_set`.

操作： 'api.request`, `error.exception`, `release.deploy`, `feature.flag_changed`.

合规性： 'aml。alert_opened`, `sanctions.screened`, `dsar.requested`.

每种类型都有所有者（域所有者），方案和SLO新鲜度。

3）计划和合同

• `event_time` (UTC), `event_type`, `schema_version`, `event_id` (UUID/ULID),
• `trace_id`/`span_id`, `request_id`, `user.pseudo_id`, `session_id`,

json
{
"event_id": "01HFY1S93R8X",
"event_time": "2025-11-01T18:45:12. 387Z",
"event_type": "game. bet",
"schema_version": "1. 4. 0",
"user": {"pseudo_id": "p-7a2e", "age_band": "25-34", "country": "EE"},
"session": {"id": "s-2233", "device_id": "d-9af0"},
"game": {"id": "G-BookOfX", "provider": "StudioA", "stake": {"value": 2. 00, "currency": "EUR"}},
"ctx": {"ip": "198. 51. 100. 10", "trace_id": "f4c2...", "request_id": "req-7f91"},
"labels": {"market": "EE", "affiliate": "A-77"}
}

方案的演变：语义版本；backward-compatible-我们添加不可分割的字段；破解-仅在具有双重录制时间段的新版本（'/v2'）中。

4）工具： 在哪里和如何

4.1个客户（Web/Mobile/Desktop）

带有本地缓冲区的遥测SDK，击球发送，指数回程。
自动事件：访问,点击,块可见性,网络活性（TTFB, LCP, CLS）, JS错误。

ID： "device_id"（稳定但私有），"session_id"（更新），"user"。pseudo_id`.

"噪音"防护："event_id"，trottling，client-side采样。

4.2服务器/后端

Ger/Tracer包装纸（OpenTelemetry）→域事件的emit。
强制从边缘/网关到所有下游服务的"trace_id"。
域事件事务发布的Outbox模式。

4.3供应商/第三方

连接器（PSP/KYC/工作室）与主机电路正常化；转化适配器。
Payload签名/完整性检查，周边日志（ingest audit）。

5) OpenTelemetry (OTel)

Traces：每个请求都收到"trace_id"；我们通过"trace_id"/"span_id"链接逻辑/事件。

Logs： 使用OTel Logs/转换器；环境标签'服务。name`, `deployment.env`.

度量标准：按服务划分的RPS/latency/error-rate、业务指标（GGR,转换）。
Collector：单一接收点/缓冲区/导出到Kafka/HTTP/grafic。堆栈。

6） ID和相关性

"event_id"是唯一性和幂等性。
`user.pseudo_id'是稳定的别名（单独和受限制）。
"session_id"、"request_id"、"trace_id"、"device_id"是端到端分析的必备条件。
API网关和SDK级别的ID一致性。

7）采样和量控制

规则：按活动类型，按市场，动态（自适应）负载。
准确拍摄的事件：付款/合规/事件-不采样。
分析事件：10-50%允许在橱窗中调整权重。
服务器侧下载：允许高频度度量。

8）隐私和合规性

最小化PII：令牌PAN/IBAN/电子邮件；在ingest中→ IP 地理代码/ASN。
区域化：发送到区域内部（EEA/UK/BR）。
DSAR/RTBF：支持选择性投影隐藏；法律交易日志。

保留策略： 按类型划分的时间表（分析更短,监管时间更长）；Legal Hold.

9）运输和缓存

客户端→ Edge：HTTPS（HTTP/2/3），"POST/telemetry/batch"（最多100个事件）。

Edge → Sheena： Kafka/Redpanda通过"用户"参与。pseudo_id`/`tenant_id`.

格式为：JSON（ingest），Avro/Protobuf（总线），Parquet（湖）。
可靠性：带有jitter、DLQ、poison-pill绝缘的转发。

json
{
"sdk": {"name":"igsdk-js","version":"2. 7. 1"},
"sent_at": "2025-11-01T18:45:12. 500Z",
"events": [ {... }, {... } ]
}

10）可靠性和相容性

客户端生成的"event_id"+服务器祖先通过"（event_id，源）"。
服务上的Outbox，线程中的Exactly-Once语义（键入状态+dedupe）。
按键内的顺序：通过"用户/会话"进行分期。
时间控制：NTP/PTP，有效漂移（例如≤ 200 ms），服务器上的"received_at"。

11）遥测（TQ）和SLO质量

Completeness: ≥ 99.T后关键类型事件的 5％。
Freshness： p95延迟交付至Silver ≤ 15分钟。

Correctness： 有效方案≥ 99。9%, drop-rate < 0.1%.

Trace coverage：使用"trace_id"的查询比例≥ 98%。
Cost/GB：按域划分的ingest/存储目标预算。

12）可观察性和dashbords

• 按来源和地区分列的Lag ingest （p50/p95）。
• 按事件类型和市场划分的完整性。
• 电路验证/超额付费错误。
• SDK版本映射和旧客户端百分比。
• Web-vitals相关性↔转换/故障。

13）客户端SDK： 要求

轻量级footprint，离线缓冲区，延迟初始化。

设置： 采样,max batch size, max queue age, privacy mods （no-PII）.

保护：封装签名/反标记，密钥溷淆。
更新：用于禁用嘈杂事件的功能标志。

14）边缘层和保护

利率限制，WAF，计划验证，压缩（gzip/br）。
客户上的Token bucket；反重播（"request_id"，TTL）。
删除IP和UA →在"原始"付费之外进行标准化/富集。

15）与数据输送机集成

青铜：不可逆的添加原料payload（用于伪装）。
Silver：具有重复数据消除/丰富性的标准化表。
黄金：BI/AML/RG/产品展示。
事件和报告之间的Lynedge；转换版本。

16）客户质量分析

"安静的客户"比率（N小时内没有事件）。
"风暴"（mass duplicate/burst）异常。
按版本和平台划分的"传统SDK"份额。

17）流程和RACI

R：数据平台（ingest/总线/验证程序），App Teams（SDK工具）。

A: Head of Data/Architecture.

C：Compliance/DPO（PII/retention），SRE（SLO/事件）。
I： BI/营销/风险/产品。

18）实施路线图

1.6-8类型的v1+JSON模式事件分类法。

2.SDK (Web/Android/iOS) с batch и sampling;Edge `/telemetry/batch`.

3.Kafka+青铜层；基本的验证者和去世者。

4.Dashbord ingest lag/completeness, alerta on drop/验证器。

• OTel收藏，跟踪相关性；银规范化和DQ规则。
• 区域终端（EEA/UK），privacy时尚，DSAR/RTBF程序。
• SDK版本卡，环轮自动滚动更新。

• Exactly-Once在线程中，Feature Store连接，反属在线模拟。
• 电路和验证器的Rule-as-Code，更改模拟（影响分析）。
• 成本优化：自适应采样,Z-order/聚类到湖中。

19）发布前质量检查表

• 已填充必填图域和正确类型。
• 存在'trace_id'/'request_id'/'session_id'。
• SDK支持batch、retry、sampling。
• Edge验证了电路并限制了付费负载的大小。
• 包括敏感字段的隐私过滤器和标记化。
• 设置了SLO/Alerts和dashbords。
• 域文档（事件示例,所有者,SLA）。

20）频繁的错误以及如何避免错误

原始事件无图：输入registry和CI验证。
无等效性：要求"event_id"并存储重复数据消除窗口。
PII和分析师的混合：分开mappings，掩盖字段。
缺少tracing：通过gateway铺设"trace_id" →服务→事件。
非管理卷：应用采样/trottling和预算配额。
全球无区域端点：使用区域化和数据驻留。

21）词汇表（简短）

OpenTelemetry（OTel）是预告片/度量/逻辑的开放标准。
Outbox是域事件的事务性发布。
DLQ是"bit"消息的队列。
采样-选择事件的一部分以减少体积。
Data Residency-将数据存储在正确的司法管辖区。

22）结果

设计精良的遥测是安排，而不仅仅是"发送日志"：严格的方案，协调的标识符，默认的隐私，可靠的运输，可观察性和经济成本。根据这篇文章，您将获得稳定的事件流，准备使用可预测的SLO进行分析，合并和机器学习。