geedge-jira/md/OMPUB-564.md

# 新疆前端运营商环境 TSG21.12版本 主面板和实时图表数据不准确

| ID | Creation Date | Assignee | Status |
|----|----------------|----------|--------|
| OMPUB-564 | 2022-07-22T17:14:22.000+0800 | 窦凤虎 | 已解决 |


---

1、以联通为例：联通的7月19日联通CN省口报告中流量速率峰值是1.01Tbps，联通NEZHA系统显示流量峰值速率为1.1Tbps，而联通TSG显示流量峰值速率为869.67Gbps，除此之外，基本界面所有数据均与CK查询数值都对不上

2、以移动为例：移动的7月23日吞吐量 TSG界面实时图表显示4.64PB

!移动23日实时图表.png|thumbnail!

CK查询显示4.52PB

!移动23日CK查询.jpg|thumbnail!

3、电信测试环境CK数据库中11日-14日无数据，巡检发现电信TSG界面实时图表显示15日20:30到17日无数据（排查原因为durid任务重启导致，不影响CK中的数据），16日CK服务器80.7硬盘大量损坏，电信测试环境仅剩2台CK存储。

4、需要确认移动和联通环境是否以CK数据库查询出的数据为准？

5、需要排查电信环境CK少几天数据是否是因为电信只保存12天日志或是80.7硬盘损坏导致？

 **doufenghu** commented on *2022-07-29T10:40:31.914+0800*:

相关问题答复：
 * {color:#0747a6}统计口径不一致，存在两方面原因{color}
 ** {color:#0747a6}统计口径： 关于峰值速率，计算方式为“单位时间带宽大小/时间粒度”，误差尽量控制在 ±5%。关于该问题麻烦列下运营商那边流量峰值和计算粒度作为参考值。[~jiayimeng] {color}
 ** {color:#0747a6}系统bug： 可能为现场配置或系统bug，目前在定位排查。{color}

{quote}1、以联通为例：联通的7月19日联通CN省口报告中流量速率峰值是1.01Tbps，联通NEZHA系统显示流量峰值速率为1.1Tbps，而联通TSG显示流量峰值速率为869.67Gbps，除此之外，基本界面所有数据均与CK查询数值都对不上
{quote}
 
 * {color:#0747a6}Live Charts 图表计算属于流式计算，基于处理时间(实时任务的时间）切分窗口进行聚合计算。因实际会话以事件时间（会话结束时间）并且为乱序状态。因选取时间口径不一致，导致实时计算总量与离线报告统计的总量不一致。离线报告结果更精确。同样误差尽量控制在 ±5%。{color}

 
{quote}2、以移动为例：移动的7月23日吞吐量 TSG界面实时图表显示4.64PB，CK查询显示4.52PB
{quote}
 
 * {color:#0747a6}电信为混部环境，CK仅3台存储，保持尽可能存储的原则，完整数据最大保存7天（可沟通后，按需调整）。{color}

 
{quote}3、电信测试环境CK数据库中11日-14日无数据，巡检发现电信TSG界面实时图表显示15日20:30到17日无数据（排查原因为durid任务重启导致，不影响CK中的数据），16日CK服务器80.7硬盘大量损坏，电信测试环境仅剩2台CK存储。

5、需要排查电信环境CK少几天数据是否是因为电信只保存12天日志或是80.7硬盘损坏导致？
{quote}
 
 * {color:#0747a6}相关 Top X 或 一些协议，APP计算 尽量通过Report定制。当前直接查询数据库也没问题。{color}

 
{quote}4、需要确认移动和联通环境是否以CK数据库查询出的数据为准？
{quote}



---

**doufenghu** commented on *2022-07-29T16:00:10.143+0800*:

联通7月20号日志，统计流量峰值
||统计来源||指标||10s||1min||5min||
|已关闭会话日志|c2s_bytes
s2c_bytes| {*}4.49Tbps{*}（ 2022-07-20 23:05:50）|2.27 Tbps（2022-07-20 23:05:00）|1.2 Tbps (2022-07-20 23:05:00)|
|已关闭+过渡会话日志|c2s_byte_diff
S2c_bytes_diff|1.02Tbps|1Tbps|980Gbps|
|Traffic Metrics （Dashboard）|total_in_bytes
total_out_bytes|*942.3Gbps*|907.86Gbps|888.44Gbps|
|实时统计(Live Charts)|c2s_byte_diff
S2c_bytes_diff|*1.56Tbps*|*759.58Gbps*|*654.11Gbps*|
 * 基于已关闭会话日志-(C2S+S2c) Bytes 计算峰值流量速率，可能受UDP流量影响，不适用计算速率; 现象如下： 
 ** TCP和UDP流量占比符合8/2原则，24小时带宽TCP占75%-85%，UDP 15%-25% ; 24小时会话量TCP占75%-85%，UDP 15%-25%。
 ** 抽取10s的数据，2022/7/20 23:05:50({*}4.49Tbps{*}) 和 2022/7/20 0:04:20({*}1.02Tbps{*})对比
 *** 会话量在一个量级900多万
 *** 2022/7/20 23:05:50 ，带宽{*}TCP占56.29%，UDP占 43.71%{*} ； 会话量TCP占80.85%，UDP 19.15%。
 **** UDP 会话持续时间AVG: 129s, P95: 60s，P99: 576s 
 ***  2022/7/20 0:04:20,  带宽{*}TCP占81.85%，UDP占 18.15%{*} ； 会话量TCP占82.13%，UDP 17.87%。 
 **** UDP 会话持续时间AVG: 18s, P95: 54s，P99: 223s 
 ** 抽取60s的数据，2022-07-20 23:05:00({*}2.27 Tbps{*}) 和 2022/7/20 0:00:00({*}1Tbps{*})对比
 *** 会话量在一个量级5000多万
 *** 2022/7/20 23:05:00 ，带宽{*}TCP占56.99%，UDP占 43.01%{*} ； 会话量TCP占79.48%，UDP 20.52%。
 *** 2022/7/20 0:00:00,  带宽{*}TCP占80.71%，UDP占 19.29%{*} ； 会话量TCP占82.29%，UDP 17.71%。
 * 从数据上看，已关闭+过渡会话日志 计算速率相对稳定，可基于该指标计算带宽速率；目前实时统计计算结果不正确，已确认Flink Live Charts 性能问题，待调优。[~qidaijie] 
 * Traffic Metrics(DPI ) 流量指标，目前与Nezha 1.1Tbps ,存在差距，需要进行排查。[~yangwei] 



---

**jiayimeng** commented on *2022-07-29T18:19:17.536+0800*:

新疆联通流量峰值数据来源是EDPI系统，这个系统基于netflow，在各路由设备上采集数据。



---

**doufenghu** commented on *2023-02-27T11:15:58.312+0800*:

1，2 问题基于22.07 新疆移动继续排查下。[~qidaijie] 



---

**qidaijie** commented on *2023-03-09T11:16:48.937+0800*:

问题1：查询了联通和移动3月2号-6号的TSG与NZ的流量峰值图，峰值数据几乎没有误差，个别误差在1%。
[^移动TSG-NZ峰值流量对比.zip] 
[^联通TSG-NZ峰值流量对比.zip]



---

**qidaijie** commented on *2023-03-10T21:35:08.308+0800*:

问题2：查询了移动3月1号-3月6号livecharts和Closed日志统计的流量情况，平均误差在0.5%左右。

[^移动流量对比.xlsx]



---



## Attachments

**35909/联通TSG-NZ峰值流量对比.zip**

---

**29818/移动23日CK查询.jpg**

---

**29817/移动23日实时图表.png**

---

**35910/移动TSG-NZ峰值流量对比.zip**

---

**36009/移动流量对比.xlsx**

---