背景介绍

某日收到工单，用户反馈在6.8.2版本的kibana中，对在Discovery中查询到的数据想导出到CSV文件，点击"生成CSV"按钮无响应，如下图所示：

image

从浏览器中看到点击按钮发起的请求失败了，什么也没返回，比较奇怪。

问题追踪

1. 这应该是kibana的问题！

从浏览器的Source中可以看到有报错，kibana对于收到的响应没有正确的处理，js代码报错，第一直觉是和客户使用的中文版的kibana有关，之前出现过中文版的kibana，在报告名称为中文时无法生成CSV，所以凭借经验就觉得这肯定是kibana的问题。

image

所以紧跟着，尝试对其它的index pattern，生成CSV报告，发现不管报告标题是不是中文的，都可以执行成功；然后发现客户创建的namespace命名空间也是中文的，尝试重建了一个英文的namespace, 发现可以执行成功；切换到客户的namespace下，对其它的index pattern创建报告，也都可以执行成功；十分诡异的问题，单单就这一个index pattern有问题？

之后查找kibana的日志，发现没有错误日志，不仅如此，在点击"生成CSV"按钮后请触发HTTP请求的日志都没有，这就奇怪了，难道请求没有发送过来？然而其它的成功创建CSV报告的请求，都可以正常响应并且kibana的日志中也有记录，这是哪里出问题了？

2. 莫非是浏览器的问题？

在浏览器中反复发起请求，查看网络调用，发现发起的请求的响应是net:ERR_CONNECTION_CLOSED, 之前没有注意到这个错误，只以为是kibana向某些远端地址发起请求加载资源时，因为网络不通导致的请求失败。仔细查看这个错误，应该是http请求被对端关闭掉了。

再次查看错误请求的URL和参数，发现错误请求的URL非常长，如下所示：

image

URL之所以这么长，是因为客户使用了script_field对索引的字段名称重写为中文，之后尝试选择少量的字段导出，发现可以正常创建报告，逐渐增加字段到一定程度后，就报错了？ 问题逐渐清晰，肯定是哪里有限制，导致http请求发送不出去或者是请求被拒绝掉了。难道是浏览器有限制？通过Google，查看到chrome浏览器对GET请求的URL长度限制为8182个字符，POST请求是没有限制的，POST请求一般都取决于服务器端的限制。而查看错误的请求的URL长度，发现只有不到7000个字符，所以，应该不是浏览器的问题，那是哪里的问题呢？

3. 可能是负载均衡器的问题了

因为kibana的域名对应着一个负载均衡实例(使用的是腾讯云CLB)，该负载均衡实例的七层HTTP请求转发本身是通过NGINX实现，所以会不是是触发了NGINX的什么限制呢？还是Google发现有人因为在NGINX中使用了HTTP2导致服务器无法正常返回，连接被关闭：neterr-connection-closed-error-at-chrome-with-http2-0-nginx, 然后去确认负载均衡实例的配置，发现默认开启了HTTP2.0, 直接关闭HTTP2.0， 发现生成CSV的请求正常了，问题找到了。

那具体是触发了NGINX的什么限制呢？可能是HTTP请求headers长度的限制，因为URL长度过长的时候，才会触发。
通过查找资料，发现NGINX的HTTP2模块中，配置http2_max_field_size默认大小为4K, http2_max_header_size默认为16K, 应该是就是触发了http2_max_field_size的限制，因为异常请求的URL长度达到了接近7000个字符。

但是使用HTTP1.1协议，就没有触发限制，发现NGINX的ngx_http_core_module中，对请求行和请求header的大小由参数client_header_buffer_size控制，默认为1K, 当请求行或者header的长度超过1K时，则由large_client_header_buffers参数控制内存分配，默认为"4 8K", 请求行或者header的大小不能超过8K, 总的请求行和header大小不能超过4*8K;如果请求行大小超过8K, 则返回414错误，某个请求header大小超过8K, 则会返回400错误。因为错误请求的URL大小不到8K, 所以在使用HTTP1.1协议时，没有触发限制。

问题最终得到解决，可以在开启HTTP2.0时，调大http2_max_field_size参数到8K，避免触发该限制。

经验总结

经验往往是有用的，但是执迷于经验可能会导致走弯路，所以还是得具体问题具体分析，注意问题的细节特点，从而快速的解决问题。