共计 1523 个字符，预计需要花费 4 分钟才能阅读完成。
明天的精选问题，说难必定是不难，然而典型不典型呢——还是挺典型的。而且，置信大家也不是总有精力去浏览干燥的技术文字，所以正如文章的封面一样，明天的主题是分享一个轻松的 TDengine 的应用案例。
事件的通过是这样的：一位用户在华为云服务上用两个节点的内网搭建了一个 TDengine 集群，集群能够失常工作。除了这个集群之外，该用户还有另一个独自的华为云服务器，他们不属于同一内网，且分属于两个华为云账号。在这台服务器下面，有一个单机版的 TDengine 在运行。
有一天，他忽然发现，在本地应用 jdbc-restful 形式去连贯单机的 TDengine 是 OK 的，连贯集群却会报错——timed out。
事实上，对于 jdbc-restful 这种连贯形式而言，不管 TDengine 是单机还是集群都应该是通明的，不存在什么非凡的区别，因为它只是连贯 6041 这个 HTTP 服务端口，由运行这个服务端口的主机提供 taosd 服务（单机或集群 )。
所以，一个 OK 一个不 OK 的状况是很诡异的。发现群里有这样的问题，咱们立马达到战场开始排查。
对于云服务器呈现的外网连贯问题，咱们的第一反馈其实就是平安组的端口策略配置。所以，咱们先让用户登陆了集群节点所在的华为云后盾，并发来平安组配置的截图。在确认了平安组策略没问题之后，咱们才开始了其余操作。
一开始，咱们试着把内网 ip 的集群换成了外网 ip。这一换不要紧，整个集群过后就不能工作了。并且呈现了相熟的：“unable to establish connection”。
遇到这种状况，查看节点间的端口连贯状况是必须的操作。但咱们 telnet 外网 IP 加端口 6041 后发现果然不通，而换成了 telnet 内网 ip 加端口 6041 就一切正常了。
这下咱们就很蛊惑了。
难道是外网 ip 的问题？可是查看了下，这些 ip 都是弹性 ip，也就是都绑定在云服务器上的 ip。那么既然如此，telnet 外网 IP+6041 怎么可能连贯不通呢？
正在束手无策的时候，咱们忽然想到了平安组配置后是须要关联到服务器实例上的，否则是不会失效的。于是咱们连忙回到后盾做了查看——果然，这个用户尽管配置了规定，然而因为首次应用云服务对于操作并不相熟。所以，这套平安组规定并没有关联到这两台集群的服务器。
而单机节点能够连贯的起因很简略——在另一个华为云账号平安组的策略关联上了。
这才是以上诡异事件的真正起因——是不是有一点啼笑皆非，表象：云服务上的 TDengine 只有单机能够对外服务，集群却不行？事实：集群和单机分属两个账号，集群的平安组配置完并没有关联到实例上。
就像上面这个图片一样：远远望去可怕的水怪，不过是一只可恶的长颈鹿。（动图）
因为 TDengine 的生态正在逐步完善中，与各大平台或组件的交互也会越来越频繁，所以遇到的问题品种也会越来越多。很多问题其实都是一些十分不起眼的操作导致，这就须要咱们十分粗疏地排查咱们的场景了。就比方这次的问题，是典型的“细节决定成败（keng ren）”。
最终，咱们用了一下午的工夫，把问题解决了。又用了断断续续的半天才把前因后果全副摸清楚。期间，曾帮忙解决 docker 集群连贯问题（https://mp.weixin.qq.com/s/PJ629gbF1_m3U2_S85Wbeg）的大佬 @freemine 再次轻轻路过帮忙定位问题起因，非常热心。
最终，解决问题，大快人心。
别看说起来轻描淡写，然而过后单方在只能靠文字沟通的状况下效率并不高，排查起来是比拟耗时耗力的。就比方：“他们（集群和单机）不属于同一内网且分属于两个华为云账号”这个信息就是起初反推 root cause 的时候才得悉的。
但不论如何，咱们都会持续为 TDengine 用户们保驾护航的。
