my_markdown/mine/告警和埋点不统一回复.md

现状

• 部分埋点日志比告警日志少
• 部分告警比埋点日志少；部分功能只有告警数据，没有埋点数据

原因：收到告警但并未收到相应的埋点

• 可能原因为本地数据库满，或者乱码丢弃，也可能是服务器部分问题，我们这边回进一步统计排查原因。 ==日志链路过长，统一日志不是100%可靠，理论上也存在丢失可能，所以追求100%的必要性和可能性，还是说以多少比例对等就可以切换成埋点使用？==

原因：部分告警比埋点日志少；部分功能只有告警数据，没有埋点数据

• 这个是低终端版本导致，7.5版本之前的还未做卡机分离，所以卡机故障时记录在cardissuer实体
• 这个是因为跨机激活超时错误，发生在cardReadAdapter实体，告警只能记录在此实体

==- 之前独立发布的龙华卡库（7.3.1），是低版本导致的数据不一致问题。==

• 就上个讨论的，埋点丢失原因有可能为==本地数据库满，或者乱码丢弃，也可能是服务器部分问题==，我们会通过上送数据的方式，确定根本原因是什么。
• 待确定问题点了，再解决这个问题。

• ==但埋点和告警是两个不同的模块，数据量差异也是巨大的；我认为即使到最后，也不太可能完全一致，只能说数量上比较接近；请考虑相关的问题。==

• 统计了10.1-10.14的level3和UE，数量比对为2344/2324，数量误差为0.8532%。 可能原因为本地数据库满，或者乱码丢弃，也可能是服务器部分问题。 我们认为追求100%理论不太可能。当前数量已经达到99.14%。

• 心跳实体记录的业务中故障，是跨机激活时卡库处理耗时过长引起的错误。因现在无法查询到9月埋点记录，统计了10.1-10.14号阶段记录，告警level3 9条 埋点记录 9条 完全对应上，怀疑心跳实体9月数据差异是不是埋点记录重复导致。

• 卡机功能集实体记录的业务中故障，是跨机激活超时引起的错误。==发生记录点在卡机功能集实体，埋点日志记录实体名称是cardReadAdapter实体==，因此业务属于卡机跨机业务故障，故障码使用的是卡机cardissuerStand故障码。

• ==后续如何处理，需要两组和蔡总讨论如何处理。==