Dr.Elephant实战常见问题及解决方法

通过之前一系列的文章叙述，想必大家都对dr.elephant有了一个较为清晰的了解。通过自己线上经验的积累，以及和一些读者的交流，我汇总了一些大家在实战中遇到的问题和解决方案。

常规问题

由于在和读者交流的过程中，发现大家技术水平参差不齐，本着科普性文章的初衷，这里先讲一些比较基础的要点，大佬们可以忽略，直接跳过。

在打包时，需要对照自己的Hadoop或者Spark版本，修改compile.conf文件中的版本号。否则有可能出现采集不到集群作业信息的情况。
最好将自己Hadoop集群的相关配置文件都拷贝到dr.elephant的app-conf目录下。
统一自己Hadoop集群的环境变量。

数据库问题

Database ‘default’ is in an inconsistent state!

启动失败并出现这个报错，一般是play框架的evolution问题，解决方法如下：

停止dr.elephant并确保进程已kill
删除原来的数据库并重新建库
配置app-conf/elephant.conf中jvm_props="-Devolutionplugin=enabled -DapplyEvolutions.default=true"，开启evolution，使其能够自动初始化表结构。

Specified key was too long; max key length is 767 bytes [ERROR:1071, SQLSTATE:42000]

这是一个较为常见的错误了，官方的历史遗留问题导致，根据报错可以看出是由于索引长度超过mysql允许的最大长度导致。解决方法如下：

conf/evolutions/default目录下的1.sql和5.sql中，增加索引长度的截取为100。

evolutions/default/1.sql
create index yarn_app_result_i4 on yarn_app_result (flow_exec_id(100));
create index yarn_app_result_i5 on yarn_app_result (job_def_id(100));
create index yarn_app_result_i6 on yarn_app_result (flow_def_id(100));
evolutions/default/5.sql
-- flow_definition table
change to UNIQUE KEY flow_def_id (flow_def_id(100))
-- job_definition table
change to UNIQUE KEY job_def_id (job_def_id(100))
-- job_execution table
change the index length like below:
create index index_je_job_exec_id on job_execution (job_exec_id(100));
create index index_je_job_exec_url on job_execution (job_exec_url(100));

或者修改mysql的my.cnf配置文件，添加innodb_large_prefix=1，然后重启MySQL，使其自身支持较大索引
此外，建议mysql直接使用5.6及以上的版本，避免一些不必要的问题

作业信息采集问题

dr.elephant的核心原理就是通过采集作业信息日志，来进行一系列的分析，算法推荐等功能。
主要分为hadoop的MapReduce，和spark作业信息采集。

hadoop

采集原理

MapReduce作业信息有两种拉取方式可选，在app-conf/FetcherConf.xml进行配置。

<fetcher>
  <applicationtype>mapreduce</applicationtype>
  <classname>com.linkedin.drelephant.mapreduce.fetchers.MapReduceFetcherHadoop2</classname>
   <params>
    <sampling_enabled>false</sampling_enabled>
   </params>
</fetcher>
 
<fetcher>   
<applicationtype>mapreduce</applicationtype>
  <classname>com.linkedin.drelephant.mapreduce.fetchers.MapReduceFSFetcherHadoop2</classname>
    <params>
    <sampling_enabled>false</sampling_enabled>            
     <history_log_size_limit_in_mb>500</history_log_size_limit_in_mb>
     <history_server_time_zone>PST</history_server_time_zone>
    </params>
</fetcher>

通过源码分析，由于源码过长，这里就不贴出来了，直接讲源码逻辑，发现两个Fetcher类分别是：

MapReduceFetcherHadoop2：通过API从yarn history server获取作业信息日志

MapReduceFSFetcherHadoop2：通过读取HDFS和YARN的配置文件，读取mapreduce.jobhistory.done-dir等相关配置，直接读取HDFS上YARN的历史作业信息日志。每个作业对应.jhist和.xml两个文件

# *.xml文件里面记录的是相应作业运行时候的完整参数配置
hdfs dfs -cat /mr-history/done/2019/11/01/000000/job_1477464172237_0052_conf.xml
# *.jhist文件里存放的是具体Hadoop作业运行的详细信息
hdfs dfs -cat /mr-history/done/2019/11/01/000000/job_1477464172237_0052-1477984365827-ocdp-QuasiMonteCarlo-1477984395977-4-1-SUCCEEDED-default-1477984370174.jhist

问题点

为什么采集不到作业信息，界面上没有任何显示？
- 注意dr.elephant打包前Hadoop version配置和被采集集群的版本信息是否对应上了，否则会出现采集不到的情况。
- 查看history_log_size_limit_in_mb配置大小是否小于实际单个日志文件大小，导致无法拉取日志。
- 检查drelephant.analysis.fetch.initial.windowMillis配置时间，这个配置为初始化时间拉取时间窗口，即拉取当前时间之前多久的历史作业。如果当前时间到时间窗口之前没有历史作业，则会出现无作业信息的情况。
- drelephant.analysis.retry.interval配置为拉取间隔时间，这个配置过大，也会导致长时间不拉取作业，而无作业信息。
运行一段时间后，为什么作业信息延迟严重？
- drelephant.analysis.thread.count作业分析线程数影响着分析效率，设置的过小很容易延迟
- 以上采集不到作业信息问题的几个排查点，也比较容易造成延迟情况，需要自己根据作业数量，进行一个评估设置

spark

采集原理

Spark作业信息同样有两种拉取方式可选，在app-conf/FetcherConf.xml进行配置。

<fetcher>
    <applicationtype>spark</applicationtype>
    <classname>com.linkedin.drelephant.spark.fetchers.FSFetcher</classname>
    <params>
      <event_log_size_limit_in_mb>500</event_log_size_limit_in_mb>
      <event_log_location_uri>webhdfs://localhost:50070/system/spark-history</event_log_location_uri>
    </params>
</fetcher>
<fetcher>
    <applicationtype>spark</applicationtype>
    <classname>com.linkedin.drelephant.spark.fetchers.SparkFetcher</classname>
    <params>
      <use_rest_for_eventlogs>true</use_rest_for_eventlogs>
      <should_process_logs_locally>true</should_process_logs_locally>
    </params>
</fetcher>

通过源码分析，由于源码过长，这里就不贴出来了，直接讲源码逻辑，发现两个Fetcher类分别是：

FSFetcher：直接通过hdfs拉取spark的历史日志
SparkFetcher：通过SHS REST API拉取spark的eventlogs，需要spark版本在1.5.0以上。此外还可以支持backfill功能，但仅适用于2.3.0以上版本。

问题点

MapReduce作业正常采集并分析，为什么spark作业没有分析数据？
- 首先参照上面hadoop版本打包问题检查，打包前是否同样在配置文件中修改为正确的spark版本
- 检查hdfs上spark eventlogs存放目录是否产生了日志文件，以及程序是否有相应的操作权限
- 如果使用了老版本的dr.elephant，则还需要注意spark是否开启了spark.eventLog.compress，导致产生的spark日志为snappy格式，使得dr.elephant无法识别。老版本可以通过增加配置进行识别
  1
  2
  <event_log_dir>/spark- history</event_log_dir>
  <spark_log_ext>.snappy</spark_log_ext>
为什么部分spark作业缺失，dr.elephant没有显示所有作业？
- 同上Hadoop问题点，可能出现了延迟问题
- SHS可能没有配好spark日志聚合，解决办法另行找SHS日志聚合资料，这里不再多说

以上是个人在实战中遇到的一些问题及解决方法，后续如果还有其他问题我也会及时更新，或者大家还遇上啥坑了也可以和我交流讨论。