监控系统 telnet 3306端口引起的 [Note] Got an error reading communication packets

问题描述：

最近一段时间数据库日志每隔5分钟报 [Note] Got an error reading communication packets
tail -f mysqld.log

问题分析：

这个报错出现的频率这么规律，初步猜测是定期脚本执行或者监控系统连接引起的可能性比较大
由于日志里能提供的信息很少，而引起该报错的可能原因也很多，首先想到的是先定位连接的客户端，然后再来分析可能的原因，于是通过查询数据库来定位问题
performance_schema.host_cache表提供对主机缓存内容的访问，其中包含客户端主机名和IP地址信息,也包括最后一次错误时间

tail -f mysqld.log

select * from performance_schema.host_cache\G

从10.10.10.1发出的LAST_ERROR_SEEN时间和mysqld.log中的时间正好吻合，于是尝试从10.10.10.1这个IP去定位问题
该IP对应的是一个监控系统，里面配置了对数据库的监控，很奇怪，别的mysql数据库也配置了监控，但是没有哪个数据库有报这个错误的
1.于是手动发起对这个数据库的监控查询，发现数据库日志并没有增加报错日志，查看这个监控对象的轮询间隔，是10分钟，和这个报错的时间间隔也对不上。
2.继续查看该监控系统的配置，发现对这个服务器还有一个TELNET 3306的监控，而且轮询间隔还是5分钟

手动发起轮询，每轮询一次，日志就报一次错，很明显这个报错就是这个telnet 端口操作引起的。
正常情况下，数据库已经做了监控，不需要进行telnet 3306的监控，这个监控对象是另一个应用的同事添加的，经过沟通，删除该监控对象后问题解决

问题解决后，为了进一步排查是否和监控系统有关，又写了各telnet 3306的脚本进行测试，也顺便贴出来
写一个telnet IP 3306的脚本，提交后台执行，就可以看到mysqld.log日志报错，performance_schema.host_cache表也能看到最新的报错连接

tail -f mysqld.log

如果直接执行telnet ip 3306,不是提交后台执行，报的是另一种错误

结论：
经过排查该报错是由于监控系统对服务器执行 telnet ip 3306的监控所引起的
有时引起报错的原因非常多，特别是这种和连接有关的问题，如果需要一个个去排查，可能会耗费比较多的时间，如果先定位是哪个客户端连接引起的，然后再去结合这个客户端的特点再去分析问题，可能会更加容易定位问题