第一反映是他的实时任务没有成功创建，因为之前两周他的实时任务曾多次因为数据源有问题而缺失中间的segment。但是他反映其任务全部发送成功。
想到从HDFS（所有PEON启动的realtime日志都会存在druid.indexer.logs.directory=hdfs://ns1/user/druid/localStorage/middle中，在$DRUID_HOME/config/middleManager/runtime.properties中）上找一下相关日志，如果日志存在，那么实时任务已经跑过那么就不是用户的问题了，缺失时间段的日志全部存在，这下可以肯定是任务本身有问题了。
联想到是本地空间不够，2.140的/tmp路径易满，同时发现2.140的middleManager启动时候尚未加-Djava.io.tmpdir=/data0/druid/tmp 参数，这样的话该参数的值默认为/tmp。后来通过查日志，发现所有失败任务的确全都是跑在2.140上的。
正确启动middleManager的指令应该是nohup java -Djava.io.tmpdir=/data0/druid/tmp -Xmx1g -Xms1g -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Duser.timezone=UTC -Dfile.encoding=UTF-8 -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -classpath config/_common/:config/middleManager/:/usr/local/hadoop-2.4.0/etc/hadoop:lib/* io.druid.cli.Main server middleManager >> /data0/druid/middlemanager/middle.log 2>>/data0/druid/middlemanager/middle_error.log &
解决方法：
1) 先使用接口<MiddleManager_IP:PORT>/druid/worker/v1/disable把2.140这个middleManager给disable掉，效果是：该middleManager不会再接收新任务，等跑完现有的实时任务后，便可以重启。（具体指令是：curl http://<MiddleManager_IP>:<MiddleManager_Port>/druid/worker/v1/disable -H "Content-Type:application/json" -X POST ）。所有槽位72个，目前峰值占用槽位53个，2.140提供槽位15个，因此他自己disabled之后没有影响。
2) Disable之后使用接口 <MiddleManager_IP:PORT>/druid/worker/v1/enabled 查看其状态，发现已经是disabled，同时经过几个整点后，发现也确实没有再接收新的任务。（验证disable的具体指令是： curl http://<MiddleManager_IP>:<MiddleManager_Port>/druid/worker/v1/enabled -H "Content-Type:application/json" -X GET ，返回结果{"<MiddleManager_IP>:<MiddleManager_Port>":false} ,证明没有enabled ）
3) 等该middleManager上所有任务结束后，杀掉该进程，使用正确的启动方式启动，指定-Djava.io.tmpdir=/data0/druid/tmp
4) 再次启动middleManager进程就能自动变为enabled。若不重启，需要使用接口 <MiddleManager_IP:PORT>/druid/worker/v1/enable 将middleManager进行enable，这样就能正常工作（具体指令 curl http://<MiddleManager_IP>:<MiddleManager_Port>/druid/worker/v1/enable -H "Content-Type:application/json" -X POST）
与Peon写入本地的路径相关的配置项
$DRUID_HOME/config/middleManager/runtime.properties文件中
Property
Description
Default
生产集群配置
druid.indexer.task.baseDir Base temporary working directory. /tmp /data0/druid/index
druid.indexer.task.baseTaskDir Base temporary working directory for tasks. /tmp/persistent/tasks /data0/druid/index/persistent/tasks
druid.indexer.task.hadoopWorkingPath Temporary working directory for Hadoop tasks. /tmp/druid-indexing 无，默认。目前不使用该功能
druid.indexer.runner.javaOpts -X Java options to run the peon in its own JVM. -Djava.io.tmpdir默认为/tmp -Djava.io.tmpdir=/data0/druid/tmp（部分）
druid.segmentCache.locations [{"path": "/data0/druid/indexCache", "maxSize"\: 5000000000000}]
4. 关于PEON启动的参数 — 紧接上一个问题
在$DRUID_HOME/config/middleManager/runtime.properties中，
已经有如下配置：
druid.indexer.runner.javaOpts=-server -Xmx6g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Duser.timezone=UTC -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/data0/druid/tmp。该参数指定PEON的启动参数。
很奇怪的是，明明已经指定 -Djava.io.tmpdir=/data0/druid/tmp，可为什么在启动middleManager时候没有加入 -Djava.io.tmpdir=/data0/druid/tmp就写入默认/tmp呢？如果该参数指定的值没被加载的话，那么启动的PEON的内存就应该和middleManager一样大是1G而不是看有的将近10G。
后来看Runtime Configuration（http://druid.io/docs/0.8.2/configuration/indexing-service.html），发现对参数druid.indexer.runner.javaOpts的解释：“-X Java options to run the peon in its own JVM.”。才发现该参数中指定的值只加载 -X参数，-D就忽略了，也就印证了之前的现象。
关于这个现象的代码解释：
原因在 io.druid.indexing.overlord.ForkingTaskRunner中，Line 177 - Line 200
Override task specific javaOpts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Object taskJavaOpts = task.getContextValue(
"druid.indexer.runner.javaOpts"
);
if (taskJavaOpts != null) {
Iterables.addAll(
command,
new QuotableWhiteSpaceSplitter((String) taskJavaOpts)
);
}
for (String propName : props.stringPropertyNames()) {
for (String allowedPrefix : config.getAllowedPrefixes()) { // "com.metamx","druid","io.druid","user.timezone","file.encoding","java.io.tmpdir","hadoop"
这是将middleManager的启动参数中，先读入 $DRUID_HOME/config/middleManager/runtime.properties中druid.indexer.runner.javaOpts 定义的参数，再读入以AllowedPrefixes开头的配置项的内容读出并作为Fork出的Peon的参数，该类的代码采用反射无法追下去，但是可以看到props的类型是JAVA原生的Properties，猜测这个就是JVM参数，也就是MiddleManager运行参数。由于JVM同名参数后出现的覆盖前面出现的，这么做的结果就是$DRUID_HOME/config/middleManager/runtime.properties中druid.indexer.runner.javaOpts对应的 -D参数全部被覆盖，也就符合官网说的-X Java options to run the peon in its own JVM。这么做是方便传递参数？保证系统稳定？毕竟middleManager这时候已经起来了，这时候参数是可以用的？
Comments