# 【E21现场】YouTube deny失败 | ID | Creation Date | Assignee | Status | |----|----------------|----------|--------| | OMPUB-641 | 2022-09-23T15:21:11.000+0800 | 杨威 | 已关闭 | --- 目前现在版本22.07情况下，对YouTube的deny失败。**liuxueli** commented on *2022-09-26T09:45:50.811+0800*: * 测试时间段已排查内容： ** 交换版均为pass状态 ** 没有相应的DDOS Bypass ** 没有丢包 ** 策略没有问题 ** 与单向流无关 ** youtube在E境内存在节点，但不是IGW阻断无效果的真正原因 *** !image-2022-09-26-09-45-16-214.png! --- **liuxueli** commented on *2022-09-29T15:58:06.746+0800*: * 暂时关闭BOL-IGW NPB 1/2/5的overload protection功能，观察丢包情况。 --- **yangwei** commented on *2022-10-08T19:07:50.103+0800*: 更新10.5-10.7排查记录 * 10.5 UTC+8 18:00-22:00 ** 现象描述 *** 在IGW下发YouTube deny策略，拨测（固定公网IP）有效率低于10% *** 在PE下发相同策略，拨测有效率100% *** PE相当于省口，IGW相当于国际口，流量理论上先过PE，再上行至IGW至国际互联网 ** 现场拨测 *** {*}生效策略{*}：IGW deny Client IP（196.188.136.150）+YouTube  *** 使用现场终端，分别用浏览器直接访问www.youtube.com和命令行执行curl [https://www.youtube.com|https://www.youtube.com/] ，多次测试后，有效率仍然低于10% *** 通过观察客户端捕获的数据包，观察到 **** *问题1：deny有效的会话，实际生效的动作为drop，未收到rst包* **** 都有用172.217.169.238这个IP（归属地美国，所属公司为Google）使用SSL SNI请求www.youtube.com的行为，相同二元组不同四元组的情况下，同时存在有效和失效的情况 *** 缩小测试范围 **** 测试终端上修改hosts，将www.youtube.com固定解析为172.217.169.23 **** 使用curl复测，仍然存在有效率低的现象，但是并不为0 *** 界面查询会话日志 **** 查询条件为172.217.169.23-196.188.136.150二元组 **** 二元组会话日志同时存在于Old Airpod PE、DIR IGW和MW IGW三个站点 ***** PE的会话日志数量与拨测数量相符 ***** 两个IGW站点的会话数量，与拨测数量不相符 *** 策略改为在PE生效，有效率100% *** 通过在DIR IGW的NPB捕包，配合拨测操作，未捕获到deny无效的会话 *** *推测1：PE流量完整，IGW流量不完整，即使相同二元组，也存在部分会话流量缺失的情况* ** 当天结论 ***  怀疑IGW接入流量不完整，建议用户如果想使用deny功能，优先在PE生效。不足之处在于丢流量的工具链完全由我方提供，加上存在丢日志的情况，对业主的说服力或许不够. *** 补充测试了Facebook、Instagram、Telegram等应用，有效率都是100%，暂时可观察到的有问题应用范围仍然是YouTube * 10.6 UTC+8 17:00-19:00 ** 补充前一晚拨测结果 *** OLAP已经尝试修复日志丢失的问题 *** 策略仅在IGW生效的话，拨测有效率在10%-50%之间变化 *** 仍然存在PE的会话日志量，与拨测次数能够对应，但是IGW的会话日志量，少于拨测次数，怀疑仍然存在日志丢失的问题 ** 补充测试策略 *** 安全策略日志缺失的量，似乎少于会话日志，因此补充两条安全策略，方便进行对比验证  **** PE新增一条client IP + YouTube Monitor策略 **** IGW新增一条 Client IP + Server IP Monitor策略 **** !image-2022-10-08-19-07-46-060.png|width=575,height=168! * 10.7 UTC+8 17:00-22:00 ** 测试问题 *** 由于同一天业主同时也在办公网内，使用同一个公网出口进行拨测，因此，界面上出现二元组的策略日志和会话日志，远大于拨测终端访问的次数 *** 要求现场人员，补充了客户端捕包，和NPB捕包的数据，方便进行对比验证 * ** *** **** 业主办公网的出口，经过NAT后共享196.188.136.150这个公网IP进行访问，除源端口发生转换外，似乎NAT中包含一个L4 Proxy，导致TSG日志中使用TCP_ISN无法关联拨测终端捕到的包 **** 使用SSL JA3 Hash，成功关联拨测终端产生的会话，和TSG日志中的会话 ** 结果分析 *** 以最后一次拨测为例，尝试31次访问，15次有效deny，16次deny失败 **** PE ***** NPB上捕获的数据包，能够查询到31条会话，且{*}全部为双向流{*} ***** 可以查询到31条会话日志，和31条monitor策略日志 **** DIR_IGW ***** NPB捕获的数据包，能够查询到15条会话，与deny成功的对应，{*}全部为C2S单向流{*} ***** 查询到Deny策略日志13条，均包含在上述15条会话中 ***** 查询到Monitor策略日志13条，均包含在上述15条会话中 ***** 查询到会话记录日志12条，均包含在上述15条会话中 **** MW_IGW ***** NPB捕获的数据包，能够查询到16条会话，与deny失败的对应，{*}全部为S2C单向流{*} ***** 查询到Monitor策略日志12条，均包含在上述16条会话中 ***** 查询到会话记录日志6条，均包含在上述16条会话中 ** 更新结论 *** *测试固定的二元组（196.188.136.150，172.217.169.23）过IGW时存在单侧流量缺失的情况* **** 经过PE时为完整的双向流 **** 上行至IGW，随机从DIR_IGW或者MW_IGW出口访问国际互联网 **** 经过DIR_IGW的流量，缺失S2C侧流量，不影响deny效果 **** 经过MW_IGW的流量，缺失C2S侧流量，影响YouTube识别，导致无法有效deny *** {*}IGW仍然存在丢失日志的情况{*}，包括安全日志和会话记录日志 --- **yangwei** commented on *2022-11-07T10:04:24.067+0800*: 更新记录11.01 UTC+8 17:00-22:00 * Old Airport的70次访问，到IGW全部变成单向流 * 应该在IGW查到70*2=140条日志，但是Microwave-IGW只有36条，Dire Dawa-IGW只有34条，并集为20条 * 从Old Airport出来的70条拨测访问，20条经过IGW接入是完整的（以单向流的形式Dire Dawa-IGW+Microwave-IGW分开） * 14个会话只有C2S，16个只有S2C * 拨测的70个会话，在IGW出现次数是20+14+16=50，有20个会话在IGW缺失，缺失率到28% * !image-2022-11-07-10-02-51-001.png|width=524,height=125! 结论 * 按概率，怀疑IGW侧C2S和S2C接入各缺失约50%，需要更大的测试样本   --- **yangwei** commented on *2022-12-06T15:55:43.880+0800*: * 背景 ** 前述测试server IP 172.217.169.238，属于AS15169，登记的掩码为23位 * 目标 ** 为验证流量在IGW的缺失，是否与AS域相关，拟扩大拨测范围，请[~liuju] 测试后更新下测试结果表 * 方法 ** 针对待测试IP，执行以下命令，重复10次，记录命令是否执行成功 {code:java} openssl s_client  -connect [测试IP]:443 -state {code} * ** 查询会话日志（查询条件 client IP == 196.188.136.150 && server IP == 测试IP），记录对应的IGW和PE日志数量，和流量方向（单向流or双向流）     ||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||备注|| |172.217.169.238| | |站点： SledIP： 会话数量： 双向流： C2S单向流： S2C单向流：|站点： SledIP： 会话数量： 双向流： C2S单向流： S2C单向流：|YouTube服务端拨测IP，Google AS15169| |172.217.169.254| | | | |Google IP 与172.217.169.238相同C段IP| |172.217.14.238| | | | |Google IP 相同ASN,临近C段的Google IP| |142.251.215.243| | | | |Google IP 相同ASN的Google IP| | | | | | | | |104.244.42.6| | | | |Twitter IP AS13414| |157.240.3.35| | | | |Facebook IP AS32934| | | | | | | | |175.27.8.138| | | | |Tencent IP AS45090|   --- **liuju** commented on *2022-12-06T20:53:24.205+0800*:     2022-12-06 拨测结果见下表，具体会话日志见附件   ||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.254|15:42:56--15:45:08|5|站点：old airport -pe  SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0| |与172.217.169.238相同C段IP| |172.217.14.238|15:54:21--15:57:13|5|站点：old airport -pe SledIP：10.231.11.5 会话数量：4 双向流：4 C2S单向流：0 S2C单向流：0|站点：0 SledIP：0 会话数量：0 双向流：0 C2S单向流：0 S2C单向流：0| |相同ASN,临近C段的Google IP| |142.251.215.243|16:03:22--16:04:29|5|站点：old airport-PE SledIP：10.231.11.2 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.2 会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.6 会话数量：2 双向流：0 C2S单向流：0 S2C单向流：2|相同ASN的Google IP| |172.217.169.238|16:14:32--16:16:23|5|站点：old airport-pe SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1| | |       --- **yangwei** commented on *2022-12-07T09:52:05.457+0800*: [~liuju] 看结果，像是PE日志都完整，而且流量100%经过， 怀疑IGW在丢流量或者日志，下次测试，把拨测次数增加到10次，并且附一下当时IGW有没有功能端bypass或者丢日志的描述。 --- **yangwei** commented on *2022-12-07T10:15:07.563+0800*: 新增Facebook、Twitter 、 Tencent IP各一个 --- **liuju** commented on *2022-12-08T21:03:16.385+0800*:     2022-12-08 拨测结果如下： 具体会话日志及拨测期间板卡监测详情见附件 查询拨测2022-12-08 09:28:00~~2022-12-08 10:25:15时间段内涉及到的NPB 的ddos bypass情况如下： 10.231.11.1 （有bypass 但是bypass期间没有拨测） 10.231.11.2(有bypss 但是bypass期间没有拨测) 10.231.11.3 (无bypass) 10.231.11.4 (无bypass) 10.231.11.5 (无bypass) ----------------- 10.225.11.1（有bypass 拨测期间一直都有ddos bypass） 10.225.11.2 (有bypass 拨测期间一直都有ddos bypass） 10.225.11.3 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.4 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.5  （有bypass 拨测期间一直都有ddos bypass） ----------------- 10.227.11.4  (无bypass) 10.227.11.5  (无bypass) 10.227.11.6  (无bypass) 10.227.11.9  (有bypss 但是bypass期间没有拨测) 10.227.11.10 (无bypass) ||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.238|9:28:01--9:33:52|10|站点：OAP-PE  SledIP：10.225.11.3 会话数量：14 双向流：14 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：5 双向流：0 C2S单向流：5 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：4 双向流：0 C2S单向流：0 S2C单向流：4|YouTube服务端拨测IP，Google AS15169| |172.217.169.254|9:37:10--9:39:05|10|站点：OAP-PE  SledIP：10.231.11.3 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3  会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点： SledIP： 会话数量： 双向流： C2S单向流： S2C单向流：|Google IP 与172.217.169.238相同C段IP| |172.217.14.238|9:41:57--9:47:11|10|站点：OAP-PE SledIP：10.231.11.3 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：6 双向流：0 C2S单向流：6 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.5 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Google IP 相同ASN,临近C段的Google IP| |142.251.215.243|9:49:54--9:53:28|10|站点：OAP-PE SledIP：10.231.11.2 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.2 会话数量：3 双向流：0 C2S单向流：3 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.6 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1|Google IP 相同ASN的Google IP| | | | | | | | | |104.244.42.6|10:25:50--11:21:03|10|站点：OAP-PE SledIP：10.231.11.1 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.1 会话数量：8 双向流：0 C2S单向流：8 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Twitter IP AS13414| |157.240.3.35|15:33:30--16:40:24|10|站点：OAP-PE SledIP：10.231.11.4 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.4  会话数量：4 双向流：0 C2S单向流：4 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.4 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Facebook IP AS32934| |175.27.8.138|10:08:09--10:25:14|10|站点：OAP-PE  SledIP：10.231.11.5 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.5 会话数量：9 双向流：0 C2S单向流：0 S2C单向流：9|Tencent IP AS45090| --- **chengsiyuan** commented on *2022-12-16T22:33:34.590+0800*: 2022-12-16 拨测结果如下： 具体会话日志及拨测期间板卡监测详情见附件 查询拨测2022-12-16 15:11:00~~2022-12-16 16:16:42时间段内涉及到的NPB 的ddos bypass情况如下： 10.231.11.1 （有bypass） 10.231.11.2（有bypss) 10.231.11.3 （有bypass) 10.231.11.4 （有bypass) 10.231.11.5 （无bypass) ----------------- 10.225.11.1（有bypass 拨测期间一直都有ddos bypass） 10.225.11.2 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.3 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.4 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.5  （有bypass 拨测期间一直都有ddos bypass） ----------------- 10.227.11.4  (无bypass) 10.227.11.5  (无bypass) 10.227.11.6  (有bypass) 10.227.11.9  (有bypss) 10.227.11.10 (有bypass)   ||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.238|15:11:48--15:13:13|5|站点：OAP-PE  SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1|YouTube服务端拨测IP| |104.244.42.65|15:16:54--15:45:01|5|站点：OAP-PE  SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3  会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量： 3 双向流：0 C2S单向流：0 S2C单向流：3|Twitter服务端拨测IP| |157.240.195.35|15:45:39--16:16:42|5|站点：OAP-PE SledIP：10.231.11.5 会话数量：40 双向流：40 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：10 双向流：0 C2S单向流：10 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量：34 双向流：0 C2S单向流：0 S2C单向流：34|Facebook服务端拨测IP|     --- **zhengchao** commented on *2022-12-19T10:34:29.006+0800*: [~doufenghu]   本周三前定位IGW Data Transporter丢日志的原因 --- **qidaijie** commented on *2022-12-20T23:14:50.586+0800*: 关于日志在IGW 存在丢失情况，排查如下： # 通过OLAP数据流监控，日志从Data Transporter汇聚到国家中心未有明显的日志丢失现象。但在MWV-IGW/ BOL-IGW Data Transporter，功能端向Kafka写入有较明显丢失情况，推断因Kafka磁盘IO利用率过高，影响功能端向Kafka写入日志的性能或延迟。 !OLAP数据流监控.png|thumbnail! # MWV-IGW/ BOL-IGW站点Kafka服务端日志没有ERROR信息，仅有个别WARN信息。 # MWV-IGW IO使用率在65%左右，平均每秒写入140MB；BOL-IGW IO抖动较大峰值在75%左右，平均每秒写入170MB。经过比对监控时间线，IO的抖动情况与功能端记录的丢日志监控基本吻合，下图为截取的12月17号BOL-IGW IO利用率和功能端写入BOL-IGW Kafka监控。 !功能端写入Kafka监控.png|thumbnail! !BOL-IGW IO使用率.png|thumbnail! # 在先前的优化处理中，MWV-IGW站点功能端关闭了部分日志字段的发送（OMPUB-684），修改后平均日志大小1.6K；日志写入相对更平稳，多写入了2.5-4K的日志。 !功能端日志情况记录-更新前.png|thumbnail! !功能端日志情况记录-更新后.png|thumbnail! 后续排查及处理建议： 1.从功能端出的写入异常监控图，凌晨0-7点未出现丢失日志，可在此阶段通过自动化脚本进行拨测。 2.在Kafka服务端未看到任何错误信息，需要功能端协助查看客户端具体的错误信息。 3.在IGW会话日志适当提高发送会话日志条件(已统计目前会话日志都大于5个包），或关闭DNS会话日志(当前占比40%)，为安全事件日志预留IO。 --- **yangwei** commented on *2022-12-25T17:45:42.400+0800*: * 现状（2022年12月25日） ** 流量缺失问题 *** 通过在低谷时段进行拨测（此时TSG健康状态较为良好，不存在Bypass，日志失败比例较低），发现YouTube和Facebook仍然存在流量缺失的情况 **** 按100次拨测，流量缺失率在5%-10%之间 **  TSG自身问题 *** 日志失败比例高  **** 经在京版模拟测试，相同硬件配置情况下的kafka broker，极限处理日志量为11w-12w tps（前提为对kafka broker参数进行优化，减少写磁盘和增加Batch Queue Size） **** 目前Bole和MWV功能端预计发送的总量均超过14w tps（非峰值时段），超过现场极限处理能力 **** 现场情况  ***** Bole和MWV日志发送失败现象严重，峰值日志（安全+会话）失败比例超过60% ***** Bole和和MWV功能端由于Self Protection触发的会话bypass比例逐步上升 *** 流量Bypass比例高 **** Bole和MWV流量再一次呈上涨趋势，抽样一台NPB观察，每秒新建会话数较两个月前，上涨 20%-30% ***** Bole峰值流量下（晚上21:30），TCP新建每秒已经超过6w CPS，此时功能端bypass比例接近50% ***** MWV峰值Bypass会话比例接近18% * 问题 ** {*}E21 IGW侧确实存在流量缺失现象，估测比例在5%-10%{*}，仅有缺失C2S侧流量时，将造成Deny失败 ** 由于TSG自身问题，业主工作时段拨测，会因为功能端处理能力过载造成Bypass的原因，{*}放大Deny失败的结果，比例高于实际的5%-10%{*} ** 加上日志发送失败的现象，如果仅以TSG作为排查工具链，将{*}给用户以流量缺失较实际更为严重的结论{*} * 解决方案 ** 日志失败 *** 功能端 关闭Bole和MWV的DNS会话日志（此前仅调整MWV单条日志的长度，降低了发送带宽，但是没有调整日志量），缓解kafka broker压力（调整后，预计日志发送量在11w tps） **** 具体操作方法已提交刘菊，视现场情况酌情进行调整 *** OLAP 调整两个站点kafka broker参数，提升接收性能（如果不调整参数，降低后的11w tps仍然过载） ** 功能端Bypass造成Deny效果不佳 *** 根据前述分析，目前性能瓶颈之一在于策略命中结果较多，造成扫描消耗CPU较大，但是指导用户对冗余策略条件进行合并，可操作性不大 *** 升级sapp，Bypass时，跳过常用端口（如443、80），从而一定程度上，优先保证Deny效果 **** 目前HTTP和SSL流量占比约50%，理论上仅对非HTTP和SSL会话进行bypass，仍然能够起到Self Protection的效果，具体效果需要更新后观察 **** 对应的sapp程序已发送给刘菊（MD5sum 5b43d015df8a8d77fee10e6a994ddc5a），视现场情况酌情进行调整 --- **yangwei** commented on *2022-12-26T15:35:18.398+0800*: 2022-12-26 10:33 Bole-IGW NPB04，单核使用已经超过85%，存在Bypass现象 !image-2022-12-26-15-34-15-331.png|width=590,height=337!   perf top -C 4 !image-2022-12-26-15-35-07-022.png|width=809,height=486!   --- **yangwei** commented on *2022-12-26T15:40:05.504+0800*: Bole-IGW 2022-12-25 11:05至2022-12-26 11:05 24小时的Live Traffic Chart   SSL占比（HTTPS+SSL）约49% HTTP占比约5.6% !image-2022-12-26-15-38-44-332.png|width=580,height=489! --- **yangwei** commented on *2022-12-26T15:58:51.441+0800*: Bole-IGW NPB04 扫描统计情况   !image-2022-12-26-15-55-35-726.png|width=659,height=457! 流量统计情况，原始流量7.8Gbps，每秒新建TCP 5.7w，UDP 2.9w，总计新建8.6w，平均每1Gbps流量每秒新建1.1w !image-2022-12-26-15-57-12-419.png|width=668,height=294! --- **liuju** commented on *2022-12-26T21:08:55.512+0800*:  2022-12-26 已根据研发提供的sapp（MD5sum 5b43d015df8a8d77fee10e6a994ddc5a）对BOLE-IGW 10.225.11.4做以下更新： 1、sapp进行升级； 2、关闭DNS transaction log； 编辑plug/business/tsg_conn_sketch/tsg_conn_sketch.inf，把下面这三行前面加上#注释了 [DNS] FUNC_FLAG=ALL FUNC_NAME=tsg_record_dns_entry 3、sapp添加了5个核。 目前/opt/tsg/sapp/etc/sapp.toml配置如下： worker_threads=48 bind_mask=[5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52] /opt/tsg/tfe/conf/tfe/tfe.conf配置如下： nr_worker_threads=1 --- ## Attachments **33431/142.251.215.243.xlsx** --- **33432/172.217.14.238.xlsx** --- **33430/172.217.169.238.xlsx** --- **33433/172.217.169.254.xlsx** --- **33576/2022-12-08.rar** --- **33578/2022-12-08-BOLE-IGW.rar** --- **33730/2022-12-16.zip** --- **33845/BOL-IGW+IO使用率.png** --- **33729/f83b09c2f64d5e7b483e286f8b10bbf.png** --- **31364/image-2022-09-26-09-45-16-214.png** --- **31528/image-2022-10-08-19-07-46-060.png** --- **32587/image-2022-11-07-10-02-51-001.png** --- **33908/image-2022-12-26-15-34-15-331.png** --- **33909/image-2022-12-26-15-35-07-022.png** --- **33910/image-2022-12-26-15-38-44-332.png** --- **33912/image-2022-12-26-15-55-35-726.png** --- **33913/image-2022-12-26-15-57-12-419.png** --- **33846/OLAP数据流监控.png** --- **33848/功能端日志情况记录-更新后.png** --- **33849/功能端日志情况记录-更新前.png** --- **33847/功能端写入Kafka监控.png** --- **33577/微信图片_20221208171911.png** ---