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

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

1.常规问题

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

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

2.数据库问题

2.1.Database ‘default’ is in an inconsistent state!

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

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

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

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

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

3.作业信息采集问题

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

3.1.hadoop

3.1.1.采集原理

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

3.1.2.问题点

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

3.2.spark

3.2.1.采集原理

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 以上版本。

3.2.2.问题点

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

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