记一次grafana无法连接zabbix数据源现象 grafana添加zabbix数据源，test等待一段时间之后出现P

现象

grafana添加zabbix数据源，test等待一段时间之后出现Post "https://zabbix.example.com/api_jsonrpc.php": net/http: TLS handshake timeout提示，zabbix版本为5.x，zabbix插件版本为4.2.4。

排查

打开grafana数据源，打开浏览器F12，点击数据源test，发现报错

error: "Internal Server Error"
message: "Post "https://zbx-5.example.com/api_jsonrpc.php": net/http: TLS handshake timeout"

使用postman直接访问zabbix 5 api发现可以正常访问

curl --location --request POST 'https://zbx-5.example.com/api_jsonrpc.php' \
--header 'Content-Type: application/json-rpc' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
        "user": "username",
        "password": "password"
    },
    "id": 1,
    "auth": null
}'

是不是版本的问题呢？找一个可以通过grafana正常访问的zabbix 3.x版本的zabbix作为数据源，通过postman使用相同的参数进行访问，发现也可以正常访问，证明与版本没有关系

curl --location --request POST 'https://zbx-3.example.com/api_jsonrpc.php' \
--header 'Content-Type: application/json-rpc' \
--data-raw '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {
        "user": "username",
        "password": "password"
    },
    "id": 1,
    "auth": null
}'

打开wireshark，设置ip.addr == <zabbix_ip>，开启抓包；本地ping发现可以正常抓到包；数据源模式调为browser(从本地发送请求，而不是通过grafana)模式,点击test；发现wireshark并没有抓到包；怀疑browser设置无效，请求继续从grafana服务器后端转发到数据源，所以在grafana端也开启抓包tcpdump host zbx-5.example.com;返回数据源点击test；发现grafana端有抓到对应的包，所以应该是插件或者某些其他原因，此数据源无法直接使用browser模式直接通过本地浏览器访问；相同的方式抓一次可以正常访问的数据源zbx-3的数据包
分析正常的zbx-3的数据包
分析异常的zbx-5，发现tcp previous segment not captured
参照networkengineering.stackexchange.com/questions/5…和www.pianshen.com/article/770… 进行分析，用No.6数据包的seq减去No5的seq: 726784969-726783521=1448，表示
为什么客户端通过grafana发送给zbx-3的请求协议是TLSv1.2，而发送给zbx-5的请求协议是TLSv1？并且直接从浏览器访问zbx-5可以正常访问，且使用的是TLSv1.3，是否因为zabbix-v5不支持TLSv1呢？如何指定grafana client的TLS版本呢？暂时无法验证
谷歌搜索wireshark tcp previous segment not captured "continuation data"发现网页forums.he.net/index.php?t…，发现可能是mtu查看可以正常访问的主机发现网卡的mtu都是1500，为什么grafana eth0的mtu是1442呢？(因为openstack集群的mtu默认设置是1442，所以上面的虚拟机网卡默认mtu就是1442，为什么openstack的默认mtu要设置为1442，暂时不知)会不会是mtu不同导致的呢？docker0的mtu与eth0的mtu值不同导致的呢？
验证猜想: 修改/etc/docker/daemon.json文件，重启docker服务，发现容器内可以正常curl
```
{
  "mtu": 1442
}
```
问题得到解决

深层原因分析

为什么docker0的mtu与eth0的mtu不同会导致部分https网站(tls)无法访问。并非所有的https网站都不能访问，因为访问zbx-3是正常的，应该是与这台zbx-5的tls配置有关，有待深入查。