总览

    在issue专栏, filter过滤器中搜索关键词。如： filter:

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

    如果是自行编译

    通常会出现的问题:

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

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

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

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

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

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

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

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

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

    • 方式1：如果执行日志中有显示，可以在管理台上查看到 如下图:
      engine-log
    • 方式2:如果方式1中没有找到，可以通过找到conf/linkis-cg-engineconnmanager.properties配置的的参数，该值就是引擎启动部署的目录，子目录按执行引擎的用户进行了隔离

    目录大体如下

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

    step2：查看引擎的日志

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

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