启动TDH服务失败如何定位问题以及一些相关的常见问题
本篇贴文主要围绕TDH服务出现服务启动失败的问题时该如何解决展开，希望可以给读者一些问题定位、排查方面的思路。
友情链接：
- kubernetes 运维常用命令--pod篇
https://community.transwarp.cn/thread?topicId=284
- 如何根据错误信息定位出现问题的发生阶段以及错误类别
https://community.transwarp.cn/thread?topicId=264
概览
当在8180页面上发现服务不健康（红色或者黄色）或者未启动（灰色）时，常见的办法是去启动（或者重启）问题服务，服务启动失败时需要检查两个方面：
1.容器相关的服务是否正常
2.服务本身的进程启动情况
步骤一 检查集群基础的服务是否健康
TDH服务的健康依赖于许多的基础组件，当发现启动服务失败时候，请首先检查这些基础服务的健康状态，一般包括transwarp-manager-agent/tos/guardian/许可证等服务
如果有不健康的可以首先通过页面来启动它，需要注意的是节点页面上必须要能显示硬件信息才证明是健康的，如下图所示
如果没有显示硬件信息的话则需要ssh登录到对应的服务器上，手动启动一下agent进程：
systemctl restart transwarp-manager-agent
步骤二 查看页面上报错的原因
任何一个操作失败的时候，在页面上都会给出对应的输出，所以排查的第一步就是点击“查看”这些输出中的报错：
比如上图中的输出就是在提示连接对应节点的10208端口失败了，接下来只要找到这个端口对应的进程把它启动即可。
当然现实往往不会很完美，当遇到的是启动服务失败的情况时，页面上的输出往往不会如此直接指向错误的根源：
步骤三 查看服务的后台pod状态及日志
自TDH发布5.x版本以后，所有服务都是容器化的，所以当服务启动失败时候，先检查它的容器pod状态是否正常，比如如果是inceptor服务启动失败，那么可以在后台执行：
kubectl get pod -owide | grep quark1
结果中的状态必须是running、健康探针必须是1/1时这个pod才是健康的，否则就需要去查看这个pod的日志，命令一般是两条：
- kubectl logs <podid>
- kubectl describe pod <podid>
两条命令输出的日志侧重点并不相同，根据结果中的错误信息往往能够对服务启动的原因可以有初步的判定。
步骤四 查看服务的日志
如果从pod的日志里还是无法找到错误，可以直接去检查服务的日志。分为以下两种情况：
- 第一种情况：Pod没有起来，显示0/1，那么首先应该根据上一步的输出结果查到问题pod所在的节点
登录到对应的服务器之后，可以到这个路径下查找日志：/var/log/服务名。例如quark服务的路径一般都是/var/log/quark1/ （服务名称最后数字是安装的时候决定的）
- 第二种情况：如果pod起来了显示的是1/1那么则没有节点的限制（进入pod内就会切换到server所在节点），同样是到对应路径下查找日志：/var/log/服务名。
一般来说，该目录下往往会有多个角色的日志，具体需要查看哪一个文件呢？
一个角色的名字往往都是有一致性的，从pod名跟文件名就可以得出其关联，比如：
另外TDH服务保留日志的时间比较久、日志文件数往往是有多个，因此需要注意日志文件中的时间。
一些服务启动失败的常见问题
- 页面显示配置TOS失败
- 页面显示配置Quark失败
- workflow在启动过程中显示通过TOS 启动Server失败
- dashboard安装完了，状态显示不可用，重启失败
- 启动zookeeper服务时，通过TOS启动server报错
登录后可回答问题
.jpg)
