1.端口号被占用（.BindException）
不论是Flink，还是Kafka,Zk，hadoop之类的，正常启动，jps进程却未显示错误，先查看启动日志。例如：
直接查看某个端口号被哪个进程占用，注意一定要加sudo，不然只能查看当前用户下该端口号被占用的进程。
sudo netstat -nap | grep 端口号
之后会显示占用该端口号的进程pid，java左边的即为占用该端口号的进程pid。
tcp 0 0 172.20.104.219:9001 0.0.0.0:* LISTEN 8490/java
然后杀掉该进程。
sudo kill -9 8490
此时即可正常启动。
2.Hibench框架测量的延迟吞吐所有结果均为0
当收集到的每个分区都是0条结果的时候，生成的数据csv表格数据出了时间以外全为0，第一时间应该想到的是kafka的问题。
先用jps查看集群中所有节点的kafka进程是否都存活（注意：一半以上的kafka节点都存活时候，整个kafka集群才能正常工作，这也就是为什么kafka集群的节点数目一般布置为单数个的原因。）
如果kafka集群正常工作，可以查看kafka日志（建议kafka后台启动），看看也没有错误或者异常。
如果也没有，可能是设置了定期或者定时删除kafka日志，此时有可能导致刚刚kafka产生的数据流，立即被删除掉。该配置项在kafka的config/server.properties目录下，如图所示：
将光标所在的那一行注释掉即可。
Kafka有两种日志清理策略，定期删除或者日志达到一定数量后删除，这两个条件哪一个先满足，都会进行日志的清理。
如果不是kafka的问题，那就是测量的流式框架的问题了，这里我测的Flink benchmark，由于更改了Flink-conf.yaml导致收集到的吞吐和延迟均为0，所以使用默认的flink-conf.yaml即可，重启Flink即可。
Hibench测量数据全为0，可能是flink没有成功提交job，也就是Hibench 运行流式程序的第三步：
bin/workloads/streaming/identity/flink/run.sh
这一部分报错的话不会立即报错，因为hadoop里的yarn-site.xml设置有最大提交次数，所有需要等待一段时间才会出现出错的日志。查看flink的master的启动日志，可以看到出错的原因。
常见的错误有：分配的slots不足。此时需要增加flink-conf.yaml里的taskmanager.numberOfTaskSlots或者减少并行度。还有一种错误，就是Flink的TaskManager没有正常启动，此时查看flink的slave的启动日志，注意slave日志数字下标最大的为最新产生的那个日志，查看slave的日志或者master的日志即能解决问题。
重启Flink即可解决错误。
重新运行Hibench上的应用程序，即能正常收集p99 latency或者throughput了。
3.Hadoop集群无缘无故多了一个NodeManager
在hadoop上运行jar包时候会一直卡个running job xxxxxxxxx那一步。
然后检查hadoop的启动日志，发现yarn-resourcemanager中有报未知的主机名字异常（Unknown hostname exception）。
此时执行
yarn node -list
发现多了一个nodemanager，但是slaves文件中却没有该主机名字，这是为什么呢？看了这篇博主的文章，恍然大悟。
委任和解除节点（datanode和nodemanager）
创建include和exclude文件，更改yarn-site.xml和hdfs-site.xml，然后这样添加的新节点安全性就比较高了。
4.Kafka自动宕机
同一集群不同kafka节点的broker.id必须不同，否则启动时候就必定会宕机。使用守护进程的方式启动（好多博客这样说，但感觉没什么用）。更换kafka的版本（如果好多方法试过之后仍然宕机，建议你换一个版本，比如kafka_2.11-2.3.5.Hadoop启动时候需要输入密码
没有配置ssh免密登录，需要注意的是，本机ssh本机也是需要配置免密登录的（感觉这个操作真的蠢）。
本机与本机的免密登录，与其余ssh免密登录几乎没有什么不同，唯一需要注意的是，将自己的公钥（id_rsa.pub），追加到自己的需要授权的文件下（authorized_keys）。即可完成本机与本机的免密登录。
这几个文件都在~/.ssh目录下，其中.ssh为隐藏目录。
