涉及到内部信息的部分，已经经过脱敏。
现象：
接到数据分析师的报障，说QA环境最近10天的game_client_log日志数据查不到，需要尽快解决，以便分析周末测试的数据。
排查过程：
1、检查flume
因为8月13日运维问过我关于flume和kafka的问题，而game_client_log数据确实是从8月13日开始停止收集了，所以我首先检查flume是否运行正常。
根据文档，可以知道在10.2.34.13,10.2.34.16,10.2.34.43这3台服务器上部署了flume，接下来使用hadoop用户分别登录这3台服务器，使用ps -ef | grep flume-conf-dev3.properties | grep -v grep命令检查flume进程是否存在；
检查发现flume进程正常之后，然后使用cat /usr/local/service/flume/logs/flume.log | grep -iw error命令检查flume的日志文件中是否有报错。
经过检查，flume运行正常。
2、检查HDFS中是否有flume保存的日志文件
登录Hue，检查HDFS的/xk/logs/dev3/game/1106862728/20200824/17/mobile_game_client/目录，有日志文件，抽查了最近几天的多个目录，都有日志文件，说明正常。
顺藤摸瓜往链路的下端排查。
3、检查Oozie的workflow运行情况
登录Hue，筛选近11天的失败的workflow，结果如下：
可以看到，失败的都是DEV3环境的3个workflow，状态都是KILLED，其中与本次故障相关的，是[DEV3]XA ODS ALL。点击这个workflow查看，其日志页面中并没有线索；
因为workflow是由Oozie调度的，所以打开Oozie的控制台(http://10.2.34.12:12000/oozie/)，到"Done Jobs“页面找相关的workflow，检查"Job Error Log"，并没有任何日志。
web控制台没有线索，就尝试去服务器上排查吧。Oozie是部署在2个MASTER节点（10.2.34.11，10.2.34.12）上的，用hadoop分别登录到这2个MASTER节点，cd到/data/emr/oozie/logs目录，发现只有当天的日志，更早的日志文件都没有了，检查/usr/local/service/oozie/conf/oozie-log4j.properties配置文件，发现MaxHistory设置的是默认的720小时，查看源码http://oozie.apache.org/docs/4.3.1/core/apidocs/src-html/org/apache/oozie/util/OozieRollingPolicy.html#line.68 并没有找到原因。在当天的error log中发现有1条日志如下：
2020-08-24 03:11:18,718 WARN LiteWorkflowInstance:523 - SERVER[10.2.34.11] USER[hadoop] GROUP[-] TOKEN[] APP[[DEV3]XA DB-ETL(SHOP)] JOB[0100809-200122102712537-oozie-hado-W] ACTION[0100809-20Kill] Workflow completed [KILLED], killing [2] running nodes
日志中并没有体现出workflow被KILLED的原因。
因为workflow设置的是从10.2.34.33上运行，所以我用hadoop用户登录该服务器，用/home/hadoop/xk5-bi-dev3/bin/run.sh db-etl-processor tshop txxx 2020-08-24 2020-08-24 命令手动执行workflow中的某个job，遇到如下报错：
com.microsoft.sqlserver.jdbc.SQLServerException: The TCP/IP connection to the host 10.251.140.5, port 1433 has failed. Error: "connect timed out. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port.".
OK，现在明朗了：因为SQLServer连接超时，所以DB相关的ETL workflow都失败了；ODS相关的workflow中是先执行DB ETL再执行LOG ETL的，见下图，报错之后整个workflow被KILL了，所以game_client_log没有被收集到。
解决方法：
检查该SQLServer服务器的安全组策略，发现没有允许ERM服务器网段访问；与运维沟通后，确认是他们修改过安全组设置。
在更正了这个问题之后，workflow被KILLED的问题就没有再出现了。