标签：flume 10.2 workflow 检查 hadoop 排查 oozie 日志
涉及到内部信息的部分，已经经过脱敏。
现象：
接到数据分析师的报障，说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的问题就没有再出现了。
标签：flume,10.2,workflow,检查,hadoop,排查,oozie,日志 来源： https://www.cnblogs.com/dba-john/p/13560169.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。