总览

建议的排查基本优先级可以按照：社区issue专栏搜索关键词—>在社区查阅《Q\&A问题总结》文档—>定位系统日志—>社区用户群咨询交流—>定位源码远程debug

在issue专栏, filter过滤器中搜索关键词。如： filter:is:issue spark3 总览 - 图1

将issue中常见的问题以及解决方案整理成文档，放在了官网页面《 常见问题 》

如果是自行编译

通常会出现的问题:

  • 编译前，未执行mvn -N install, 导致linkis自身依赖没法获取
  • 升级部分依赖组件后，导致函数报错 如使用spark3

定位异常的手段: 可以在mvn 运行命令后面加上 -e 参数 如mvn clean install -e

如果出现报错，又不清楚具体是执行什么命令报错，可以加 -x 参数sh -x bin/install.sh，将shell脚本执行过程日志打印出来，方便定位问题

所有微服务的日志文件统一放入了logs目录，日志目录层级如下：

  1. ├── logs 日志目录
  2. │   ├── linkis-cg-engineconnmanager-gc.log
  3. │   ├── linkis-cg-engineconnmanager.log
  4. │   ├── linkis-cg-engineconnmanager.out
  5. │   ├── linkis-cg-engineplugin-gc.log
  6. │   ├── linkis-cg-engineplugin.log
  7. │   ├── linkis-cg-engineplugin.out
  8. │   ├── linkis-cg-entrance-gc.log
  9. │   ├── linkis-cg-entrance.log
  10. │   ├── linkis-cg-entrance.out
  11. │   ├── linkis-cg-linkismanager-gc.log
  12. │   ├── linkis-cg-linkismanager.log
  13. │   ├── linkis-cg-linkismanager.out
  14. │   ├── linkis-cli
  15. │   │   ├── linkis-client.hadoop.log.20220409162400037523664
  16. │   │   ├── linkis-client.hadoop.log.20220409162524417944443
  17. │   ├── linkis-mg-eureka-gc.log
  18. │   ├── linkis-mg-eureka.log
  19. │   ├── linkis-mg-eureka.out
  20. │   ├── linkis-mg-gateway-gc.log
  21. │   ├── linkis-mg-gateway.log
  22. │   ├── linkis-mg-gateway.out
  23. │   ├── linkis-ps-cs-gc.log
  24. │   ├── linkis-ps-cs.log
  25. │   ├── linkis-ps-cs.out
  26. │   ├── linkis-ps-data-source-manager-gc.log
  27. │   ├── linkis-ps-data-source-manager.log
  28. │   ├── linkis-ps-data-source-manager.out
  29. │   ├── linkis-ps-metadatamanager-gc.log
  30. │   ├── linkis-ps-metadatamanager.log
  31. │   ├── linkis-ps-metadatamanager.out
  32. │   ├── linkis-ps-publicservice-gc.log
  33. │   ├── linkis-ps-publicservice.log
  34. │   └── linkis-ps-publicservice.out

包含计算治理、公共增强、微服务管理三大微服务模块。每个微服务下包含linkis-xxx-gc.log、linkis-xxx.log、`linkis-xxx.out三个日志。 分别对应服务的GC日志、服务日志、服务的System.out日志。

通常情况下，启动某个微服务出错时，可以在log目录查看对应服务 查看详细日志排查问题

但因为服务之间是存在相互调用，linkis的微服务比较多，若对系统不熟悉，有时候无法定位到具体哪个模块出现了异常，可以通过全局日志搜索方式，拉取关键异常信息，进行排查

  1. tail -f log/* |grep -5n exception(或则tail -f log/* |grep -5n ERROR)  
  2. less log/* |grep -5n exception(或则less log/* |grep -5n ERROR)

如果某个接口请求报错，可以根据接口的返回加过中定位出现问题的微服务， 一般情况下可以根据URL规范进行定位，Linkis接口中的URL都遵循着一定的设计规范， 即/api/rest_j/v1/{applicationName}/.+的格式，通过applicationName可以定位应用名，部分应用本身是一个微服务， 这时候应用名和微服务名相同，部分应用归属于某个微服务，此时应该通过应用名查找归属的微服务， 去对应的微服务下查看log日志，下面给出微服务和应用名的对应关系。

请求路径中的ApplicationName服务的提供方
/api/rest_j/v1/linkisManager/linkis-cg-linkismanager
/api/rest_j/v1/entrance/linkis-cg-entrance
/api/rest_j/v1/bml/linkis-ps-publicservice
/api/rest_j/v1/configuration/linkis-ps-publicservice
/api/rest_j/v1/jobhistory/linkis-ps-publicservice
/api/rest_j/v1/filesystem/linkis-ps-publicservice
/api/rest_j/v1/variable/linkis-ps-publicservice
/api/rest_j/v1/microservice/linkis-ps-publicservice
/api/rest_j/v1/errorcode/linkis-ps-publicservice
/api/rest_j/v1/udf/linkis-ps-publicservice
/api/rest_j/v1/datasource/linkis-ps-publicservice
/api/rest_j/v1/metadatamanager/linkis-ps-metadatamanager
/api/rest_j/v1/data-source-manager/linkis-ps-data-source-manager
/api/rest_j/v1/engineplugin/linkis-engineconn-plugin
/api/rest_j/v1/contextservice/*(暂未使用到)linkis-ps-cs

对于请求异常的定位，可以根据上表的对应关系，去对应的服务日志中进行查看

step1:找到EngineConn的启动部署目录

  • 方式1：如果执行日志中有显示，可以在管理台上查看到 如下图:
    engine-log
  • 方式2:如果方式1中没有找到，可以通过找到conf/linkis-cg-engineconnmanager.properties配置的wds.linkis.engineconn.root.dir的参数，该值就是引擎启动部署的目录，子目录按执行引擎的用户进行了隔离
  1. # 如果不清楚taskid，可以按时间排序后进行选择 ll -rt /appcom/tmp/${执行的用户}/${日期}/${引擎}/  
  2. cd /appcom/tmp/${执行的用户}/${日期}/${引擎}/${taskId}  
  3. 例如一个Spark 引擎的启动目录如下:
  4. /appcom/tmp/hadoop/20210824/spark/6a09d5fb-81dd-41af-a58b-9cb5d5d81b5a

目录大体如下

  1. conf -> /appcom/tmp/engineConnPublickDir/6a09d5fb-81dd-41af-a58b-9cb5d5d81b5a/v000002/conf #引擎的配置文件  
  2. engineConnExec.sh #生成的引擎的启动脚本  
  3. lib -> /appcom/tmp/engineConnPublickDir/45bf0e6b-0fa5-47da-9532-c2a9f3ec764d/v000003/lib #引擎依赖的包  
  4. logs #引擎启动执行的相关日志

step2：查看引擎的日志

  1. less logs/stdout  
  2. less logs/stderr

step3：尝试手动执行脚本(如果需要)
可以通过尝试手动执行脚本，进行调试

  1. sh -x engineConnExec.sh

对于按上述排查方式排查后，仍然没解决的问题，可以通过需求帮助指引方式进行反馈和需求帮助

通常情况下，对源码远程debug是定位问题最有效的方式，但相对查阅文档来说，需要用户对源码结构有一定的了解， 这里建议您在远程debug前查阅《 Linkis源码层级结构详解 》,对项目的源码结构进行初步的了解， 有一定程度上的熟悉之后，可以参考《 如何DebugLinkis 》一文 调试对应微服务下的代码。