admin/geedge-jira
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6a8bfef5778fc7ddd06fa05776bf1ecd0f61d4c4
geedge-jira/md/OMPUB-641.md

729 lines
22 KiB
Markdown
Raw Normal View History

first
2025-09-14 21:52:36 +00:00
# 【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**
---
Reference in New Issue Copy Permalink