Nebula-meta报transport frame is too large

  • nebula 版本:3.1.0
  • 部署方式:分布式 集群
  • 安装方式:RPM
  • 是否上生产环境:Y
  • 硬件信息
    • 磁盘 14T ssd
    • CPU、内存信息:36C,512G
  • 问题的具体描述
  • 相关的 meta / storage / graph info 日志信息(尽量使用文本形式方便检索)
    事件的经过是这样的。。。。
    生产环境由于客户侧执行安全扫描,具体步骤为,通过安全扫描服务器向被扫描机器开放的端口发送tcp请求,发送内容为执行脚本,脚本原始大小为80Kb.
    通过查看nebula-meta日志发现一共发送了6次,均没有返回报文,最终进程down掉
    由于内外网原因,无法截图,详细信息如下:

[GeneratedCodeHelp.cpp:201] received invalid message from client: No version identiffier …old protocol client in strict mode? sz=119572586

[GeneratedCodeHelp.cpp:134] received invalid message from client: No version identiffier …old protocol client in strict mode? sz=119572586
[GeneratedCodeHelp.cpp:93] invalid message from client in function process
[HeaderServerChannel.cpp 100] Received invalid request from client: apache::thirft::transport::TTransportException: Header transport frame is too large :1881163860 (hex 0x70204854,ascii ‘p HT’) (transport apache::thirft::PreReceivedDataAsyncTransportWrapper, address :: *****,port *****)

你的意思是向服务端口发送异常的请求,期望端口返回怎样的报文?

是客户侧的安全扫描执行的tcp请求,我找到了另外一个帖子应该和我这个是同一个情况安全扫描时服务宕机

如果是这个的话,新版本已经 fix 了,你可以用最新的版本试试

是从哪个版本开始修复的?我们当前用的3.1.0,要想修复需要整体重新升级还是有补丁包?

可以考虑升级到最新版本:

哪个版本已修改了?前一段我这边有个3.6.0的五节点集群两个主节点(启动meta的)宕了,meta、graph、storage的日志中都没看到异常,因为没权限查看操作系统日志未查出原因。有人说应该是因为安全扫描(刚做过安全扫描),当时我觉得有点牵强,看来真有这可能。

我瞅了下,3.2 应该已经合入了,3.6.0 估计是另外的问题