你是不是也遇到过这种情况一个Hive批任务在集群上正常跑着但是你的终端窗口全被INFO日志刷屏了一屏接一屏想找一条真正的WARN或者ERROR得靠滚动条慢慢扒拉半天。我第一次认真调Hive日志的时候就是在这么一大堆英文日志里翻来翻去找问题翻到最后才发现任务本身根本没出错纯粹是被INFO级别的无用输出干扰了判断。后来我把Hive运行时的INFO日志显示关掉之后不管是排查问题还是日常跑批都清爽了不少。这篇就专门聊聊Hive运行日志里INFO级别这些事包括它们到底从哪来、怎么临时关、怎么永久关以及我在实际改动过程中踩过的坑。1. 这些INFO日志是从哪儿冒出来的1.1 Hive日志和普通Java日志的“血缘关系”Hive本质上是跑在JVM上的一个大数据分析工具它的日志框架沿用了Java生态里非常典型的log4j体系。Hive本身不产生日志它只是通过Logger接口把运行过程中的各种状态暴露出来真正的输出行为由log4j统一控制。一个日志从产生到显示中间要经过三层Logger代码里调用logger.info(xxx)的地方Hive源码里到处都有这种调用比如解析SQL、生成执行计划、提交MR任务等环节都会打日志。级别过滤log4j根据你配置的级别阈值来决定某条日志是否放行。级别从低到高一般是TRACE、DEBUG、INFO、WARN、ERROR、FATAL。如果你把阈值设成WARN那INFO和DEBUG的记录直接被丢掉不再往下走。Appender输出通过过滤的日志交给Appender决定是打印到控制台、写入文件还是发到远程。Hive默认同时配置了控制台Appender和文件Appender。你看到的满屏INFO日志本质就是“Logger产生太多INFO记录 rootLogger的阈值正好允许INFO放行 控制台Appender把它们全打出来了”三个条件缺一不可。1.2 Hive日志其实有两条独立线路在实际排查过程中不少人会把两条日志线路搞混导致改了半天发现“好像没生效”。这里务必要分清楚客户端日志hive CLI或beeline启动时的日志包括SQL解析、执行计划生成、连接HiveServer2的过程。这些日志由$HIVE_HOME/conf下的log4j配置文件控制默认输出到/tmp/当前用户名/hive.log和终端控制台。任务日志提交到YARN上的MapReduce/Tez/Spark任务运行日志由YARN的日志聚合机制管理。你在ResourceManager界面上看到的Container日志属于这一类受mapreduce.map.log.level、mapreduce.reduce.log.level等参数控制。本文主要是讲客户端/服务端进程的INFO日志显示问题但第5部分我会专门提一下任务日志级别因为它经常和Hive日志配置纠缠在一起。1.3 Hive默认配置文件到底长什么样早期Hive2.1.0之前使用log4j 1.x配置文件叫hive-log4j.properties。后来Hive升级到Log4j2配置文件改成了log4j2.properties。这个版本差异非常重要我后面专门开一节讲踩坑。默认情况下配置文件里和日志级别直接相关的是这么几行# hive-log4j.propertiesHive 2.x早期及之前 hive.root.loggerINFO,console hive.log.dir/tmp/${user.name} hive.log.filehive.log如果是Log4j2格式# log4j2.propertiesHive 2.1.0之后 rootLogger.level INFO rootLogger.appenderRef.console.ref console注意这个hive.root.logger并不只是一个简单属性Hive启动时会把它解析成log4j的root logger配置。INFO,console的意思是“rootLogger级别为INFO输出到console这个Appender”。默认配置文件里还有DRFA、RFA等文件Appender定义但我们目前只需要关心console和INFO这两个词的组合逻辑。2. 临时任务怎么快速压掉INFO输出2.1 一次性会话用--hiveconf最省事如果你只是临时跑一条比较重的SQL不想永久改动集群配置直接在命令行加一个参数就行hive --hiveconf hive.root.loggerWARN,console -f your_script.sql我这里把INFO换成了WARN这样INFO级别的日志就被过滤掉了控制台只输出WARN以上的内容。实际跑完任务后该输出的结果集、运行统计、执行状态依然正常显示不会说日志级别调高就把关键信息也吞了。有人会问为什么不直接用--hiveconf hive.log.levelWARN我实际测试下来的结果是在某些Hive版本里hive.log.level会被log4j配置引用为rootLogger的level值但在另一些版本里hive.root.logger里的级别优先级更高你改了hive.log.level控制台照样刷INFO。所以追求稳定的话直接改hive.root.logger最保险。2.2 进入CLI之后再关有时候你已经启动了hive命令行不想退出重开。这种情况下也可以在当前会话里设置set hive.root.loggerWARN,console;但这里要提醒一句set命令对已经初始化完成的日志系统未必实时生效。log4j的Appender一般在Hive进程启动时就构建好了你在CLI里跑set很可能只是改了一个Hive配置项并没有重新配置日志系统。我的经验是进入CLI之后再设置经常无效所以更靠谱的做法是启动时就带上--hiveconf参数。如果你用的是beeline连接HiveServer2情况有些不同。beeline客户端的日志输出相对克制很多INFO日志在服务端侧客户端看到的并不多。beeline中可以用!set verbose true/false控制一些输出细节但如果你想彻底压掉客户端日志还是在启动命令上加参数更可靠beeline -u jdbc:hive2://node01:10000/default --hiveconf hive.root.loggerWARN,console2.3 在脚本里统一封装如果是经常要跑的批处理脚本不建议每次手敲参数。可以在你的shell脚本里定义公共变量#!/bin/bash HIVE_CMDhive --hiveconf hive.root.loggerWARN,console $HIVE_CMD -e select * from your_table;这样所有任务都走同一套日志级别配置以后想调整级别也只需要改一个变量。我在公司内部的数据平台脚本里基本都这么写维护成本非常低。3. 改配置文件一劳永逸的完整步骤3.1 先确认你用的是哪个配置文件这是整个改造过程中最关键的一步。Hive的日志配置文件根据版本和部署模式有不同的名字常见的组合如下版本/场景配置文件日志框架Hive 2.1.0之前hive-log4j.propertiesLog4j 1.xHive 2.1.0及之后log4j2.propertiesLog4j 2.xHiveServer2独立进程hiveserver2-log4j2.properties或同前缀propertiesLog4j 2.x / 1.x在动手改之前先到$HIVE_HOME/conf目录下看一眼实际存在的文件别拿网上旧教程套全新版本。我在一堆生产环境上就遇到过有人拿2.0版的教程去改3.1版的配置改完完全没有反应。3.2 改log4j2.propertiesHive 3.x最常用如果你用的是Hive 3.x版本日志配置文件是log4j2.properties用文本编辑器打开后找到rootLogger.level# 原始配置 status error name HiveLogging appender.console.type Console appender.console.name console appender.console.target SYSTEM_ERR appender.console.layout.type PatternLayout appender.console.layout.pattern %d{ISO8601} %-5p [%t] %c{2}: %m%n rootLogger.level INFO rootLogger.appenderRef.console.ref console rootLogger.appenderRef.DRFA.ref DRFA这里只需要改一行rootLogger.level WARN如果你用的是Hive 2.x早期对应的hive-log4j.properties文件修改的是hive.root.loggerINFO,console改成hive.root.loggerWARN,console这两类文件的改动方式不一样但核心逻辑都一样把rootLogger的级别从INFO提到WARN让INFO和DEBUG日志在源头被丢弃。3.3 更推荐的做法控制台不要INFO但文件保留INFO我在生产环境调完一轮之后形成了一个我个人很推荐的做法把控制台的INFO关掉但文件Appender里保留INFO。什么意思就是让日志完整写到文件里方便排查但终端窗口别刷屏。在hive-log4j.properties里你可以这样改hive.root.loggerINFO,DRFA注意我的写法级别还是INFO但Appender从console换成了DRFA。DRFA在默认配置里是DailyRollingFileAppender按天滚动写文件。这样控制台几乎不输出日志但/tmp/用户名/hive.log文件里还是完整记录了INFO级别以上的内容。在log4j2.properties里则要把console这个appenderRef去掉或者把console换成文件AppenderrootLogger.level INFO rootLogger.appenderRef.DRFA.ref DRFA很多老手在实际运维时都是这么干的因为完全把级别提到WARN虽然控制台干净了但遇到疑难问题想回看日志发现文件里也只有WARN很多关键线索已经丢了。控制台和文件解耦是日志配置里非常核心的一个思路。3.4 顺手把日志目录从/tmp挪走Hive默认把日志写在/tmp/${user.name}/hive.log。这个默认值在测试环境无所谓生产环境却很坑/tmp目录会被系统定时清理有时候日志没来得及排查就被删了还有多用户共用服务器时/tmp下不同用户的日志文件还可能互相干扰权限。我一般会在hive-site.xml里显式指定日志目录property namehive.log.dir/name value/data/hive/logs/value /property注意这个配置项写在hive-site.xml里是在Hive启动时读入的随后会传给log4j作为变量解析。提前把目录建好并给足权限再配合前面的Appender配置日志管理会顺畅很多。4. 关掉INFO之后常见的“不生效”怎么排查4.1 我改的就是这个文件为什么还是刷INFO这是最高频的疑问。先别急着怀疑配置格式按下面这个顺序排查一遍大部分问题都能定位到第一确认当前Hive进程是不是新起的。日志配置在进程启动阶段加载你改完文件之后原来挂着的Hive CLI或HiveServer2进程不会自动感知变化。CLI每次启动都是新进程影响不大但HiveServer2是长驻服务改完配置必须重启才生效。第二确认有没有环境变量覆盖了配置。Hive启动时会读取HIVE_OPTS这个环境变量如果你在~/.bashrc或hive-env.sh里加了类似export HIVE_OPTS-Dhive.root.loggerDEBUG,console的内容那命令行参数甚至配置文件的设置都可能被它压掉。排查方式很简单echo $HIVE_OPTS echo $HADOOP_OPTS如果输出里有-Dhive.root.logger...之类的值先把环境变量清掉再试。第三确认你用的是CLI还是HiveServer2。如果你改的是hive-log4j.properties但实际业务都是通过beeline连HiveServer2跑的那客户端日志真正读的是hiveserver2-log4j2.properties或HiveServer2进程的JVM参数。两边各改各的别改错对象。第四检查软链。有些发行版在$HIVE_HOME/conf目录下没有独立的log4j2.properties而是有一个指向其他位置的软链文件。用ls -l看一下文件属性如果是指向/etc/hive/conf之类的公共配置目录光改$HIVE_HOME/conf下的文件没用需要改真正指向的那个目标文件。4.2 为什么set hive.root.loggerWARN不生效这个我在第2节提过再展开说一遍。set命令修改的是Hive的配置会话变量但log4j框架在JVM启动时就已经用初始配置生成了Logger层级和Appender实例。Hive并没有在运行时监听这个配置项的变更并实时刷新log4j。换句话说你看到的“设置成功”只是Hive层面的一个假象日志框架层面根本没有收到通知。我验证过几次确认“启动参数 配置文件 set命令”这个优先级基本是稳定的。所以不要在运行时指望靠set来关INFO一定要回到启动命令或配置文件上去改。4.3 排查时怎么确认当前真实生效的日志级别有些时候你改来改去不确定到底哪份配置生效了有一个比较粗暴但有效的验证方式hive --hiveconf hive.root.loggerWARN,console -e select 1;如果这条命令执行时控制台不再刷INFO说明至少命令行这个入口的日志是走hive.root.logger这套逻辑的。然后再跑一个不带参数的普通hive命令做对比看有没有INFO刷出来。两次对比就能快速判断是配置没改对还是被其他配置覆盖了。还有一种更彻底的办法临时把你的hive-log4j.properties或log4j2.properties重命名备份重启Hive CLI如果日志系统正常降级到默认配置并打印警告说明你的配置文件确实被加载了如果没有变化说明你改的文件根本不是Hive加载的那个。4.4 权限和目录也会导致看似“不生效”日志文件写不写、写到哪和配置项hive.log.dir、hive.log.file强相关。如果你把hive.log.dir指定到了一个不存在的目录Hive启动时会尝试创建目录但如果目录创建失败日志文件也写不出来控制台反而显得很“正常”。这种情况下你以为配置生效了其实是文件日志没落地控制台日志被其他方式压住了。建议在改动配置后主动去看一眼目标日志文件是否在持续写入ls -l /data/hive/logs/hive.log tail -f /data/hive/logs/hive.log确认文件在动再判断级别是否真的生效。尤其是多个用户共用一套Hive环境时目录权限问题非常隐蔽经常出现“A用户正常、B用户不写日志”的情况本质就是B用户对日志目录没有写权限。5. 日志级别调整之外顺手做对的几个配置5.1 别把WARN和ERROR一起误杀把INFO关掉之后建议至少保留WARN和ERROR级别。很多人在调日志时容易走极端出于“日志太多了烦人”的想法直接把级别调到ERROR甚至FATAL最后任务出错时一点线索都没有。我的习惯是控制台一级调到WARN文件里保持INFO如果某个任务连WARN都不需要再单独针对该任务覆盖级别。这样既保证日常清爽又不影响问题排查。对于线上正在跑的批任务WARN级别通常已经能暴露大部分隐患比如分区覆盖警告、数据倾斜提示、配置冲突信息等这些往往比INFO有价值得多。5.2 日志文件的滚动与保留策略日志文件不滚动的话时间一长体积会很吓人。早期Hive的hive-log4j.properties里有DRFA和RFA两种Appender区别在于Appender滚动方式常用参数适用场景DRFA按天滚动DailyRollingFileAppender长期运行服务每天一个日志文件RFA按大小滚动MaxFileSize、MaxBackupIndex任务密集单文件增长过快实际配置示例log4j.appender.DRFAorg.apache.log4j.DailyRollingFileAppender log4j.appender.DRFA.File${hive.log.dir}/${hive.log.file} log4j.appender.DRFA.DatePattern.yyyy-MM-dd log4j.appender.RFAorg.apache.log4j.RollingFileAppender log4j.appender.RFA.File${hive.log.dir}/${hive.log.file} log4j.appender.RFA.MaxFileSize256MB log4j.appender.RFA.MaxBackupIndex10这里有一个坑要提DailyRollingFileAppender的MaxFileSize参数实际上不会真正触发按大小滚动因为按天滚动模式下日期变更才是滚动条件。如果你想严格按照文件大小滚动应该用RFA而不是DRFA。之前我见过有人把DRFA配了MaxFileSize日志涨到几个GB也不滚动误以为配置没生效其实就是Appender选错了。5.3 YARN任务日志的级别也要单独看Hive提交的MR任务运行期间的具体mapper/reducer日志不会显示在你的Hive CLI终端里它们被打到了YARN的Container日志中。如果你发现某个任务跑得很慢或者报错需要在YARN Web UI上查看对应Application的logs这时候INFO级别可能才是关键。Hive会话里可以这样单独调整任务日志级别set mapreduce.map.log.levelWARN; set mapreduce.reduce.log.levelWARN;这两个参数只影响YARN侧任务运行日志不影响Hive客户端日志。我建议在hive-site.xml里统一把MR任务日志级别设为WARN既减少日志量又避免日志落盘压力。注意这个参数对Tez引擎不同Tez引擎的日志级别通过tez.task.log.level控制需要分别处理。5.4 临时排查问题时要懂得“反向操作”关掉INFO是为了日常清爽但如果你真的在排查一个复杂的SQL问题INFO甚至DEBUG反而能帮你定位到具体是哪个Stage卡住、哪条数据触发了异常。这种时候不要犹豫临时开回DEBUGhive --hiveconf hive.root.loggerDEBUG,console -f debug_query.sql或者修改log4j2.properties重启HiveServer2把rootLogger.level暂时调成DEBUG。但务必记得DEBUG日志的量级可能是INFO的几十倍大任务开DEBUG不仅会刷屏还会拖慢执行速度严重时甚至把磁盘写满。用完一定要改回来。5.5 常用Hive日志配置项速查最后整理一份我在实际工作中经常用到的配置项方便你直接参考配置项作用推荐值hive.root.loggerrootLogger级别与输出目标WARN,console 或 INFO,DRFAhive.log.dir日志文件目录/data/hive/logshive.log.file日志文件名hive.loghive.log4j.file指定log4j配置文件路径默认$HIVE_HOME/conf下hive.server2.logging.operation.log.locationHS2操作日志目录/data/hive/operation_logsmapreduce.map.log.levelMR任务日志级别WARNmapreduce.reduce.log.levelMR任务日志级别WARNtez.task.log.levelTez任务日志级别WARN这里有一个容易被忽略的小点hive.server2.logging.operation.log.location它专门管理HiveServer2执行操作时的日志位置。如果你通过beeline连接HS2时发现任务日志很乱可以单独把这个目录独立出来跟CLI日志分开存。我在实际项目中见过一个很经典的场景数仓跑批任务每天凌晨定时调度Hive日志文件默认写在/tmp/调度用户/hive.log结果某天系统清理临时目录时把这个日志文件删了任务失败后想排查发现日志早没了。后来我把日志目录统一挪到独立磁盘路径同时配置了按大小滚动和保留10份历史再配合WARN展示级别的瘦身操作整个日志体系才算真的稳定下来。关掉INFO显示只是第一步把日志这家伙关进合理的“笼子”后续排查问题你才会真正省心。
你是不是也遇到过这种情况一个Hive批任务在集群上正常跑着但是你的终端窗口全被INFO日志刷屏了一屏接一屏想找一条真正的WARN或者ERROR得靠滚动条慢慢扒拉半天。我第一次认真调Hive日志的时候就是在这么一大堆英文日志里翻来翻去找问题翻到最后才发现任务本身根本没出错纯粹是被INFO级别的无用输出干扰了判断。后来我把Hive运行时的INFO日志显示关掉之后不管是排查问题还是日常跑批都清爽了不少。这篇就专门聊聊Hive运行日志里INFO级别这些事包括它们到底从哪来、怎么临时关、怎么永久关以及我在实际改动过程中踩过的坑。1. 这些INFO日志是从哪儿冒出来的1.1 Hive日志和普通Java日志的“血缘关系”Hive本质上是跑在JVM上的一个大数据分析工具它的日志框架沿用了Java生态里非常典型的log4j体系。Hive本身不产生日志它只是通过Logger接口把运行过程中的各种状态暴露出来真正的输出行为由log4j统一控制。一个日志从产生到显示中间要经过三层Logger代码里调用logger.info(xxx)的地方Hive源码里到处都有这种调用比如解析SQL、生成执行计划、提交MR任务等环节都会打日志。级别过滤log4j根据你配置的级别阈值来决定某条日志是否放行。级别从低到高一般是TRACE、DEBUG、INFO、WARN、ERROR、FATAL。如果你把阈值设成WARN那INFO和DEBUG的记录直接被丢掉不再往下走。Appender输出通过过滤的日志交给Appender决定是打印到控制台、写入文件还是发到远程。Hive默认同时配置了控制台Appender和文件Appender。你看到的满屏INFO日志本质就是“Logger产生太多INFO记录 rootLogger的阈值正好允许INFO放行 控制台Appender把它们全打出来了”三个条件缺一不可。1.2 Hive日志其实有两条独立线路在实际排查过程中不少人会把两条日志线路搞混导致改了半天发现“好像没生效”。这里务必要分清楚客户端日志hive CLI或beeline启动时的日志包括SQL解析、执行计划生成、连接HiveServer2的过程。这些日志由$HIVE_HOME/conf下的log4j配置文件控制默认输出到/tmp/当前用户名/hive.log和终端控制台。任务日志提交到YARN上的MapReduce/Tez/Spark任务运行日志由YARN的日志聚合机制管理。你在ResourceManager界面上看到的Container日志属于这一类受mapreduce.map.log.level、mapreduce.reduce.log.level等参数控制。本文主要是讲客户端/服务端进程的INFO日志显示问题但第5部分我会专门提一下任务日志级别因为它经常和Hive日志配置纠缠在一起。1.3 Hive默认配置文件到底长什么样早期Hive2.1.0之前使用log4j 1.x配置文件叫hive-log4j.properties。后来Hive升级到Log4j2配置文件改成了log4j2.properties。这个版本差异非常重要我后面专门开一节讲踩坑。默认情况下配置文件里和日志级别直接相关的是这么几行# hive-log4j.propertiesHive 2.x早期及之前 hive.root.loggerINFO,console hive.log.dir/tmp/${user.name} hive.log.filehive.log如果是Log4j2格式# log4j2.propertiesHive 2.1.0之后 rootLogger.level INFO rootLogger.appenderRef.console.ref console注意这个hive.root.logger并不只是一个简单属性Hive启动时会把它解析成log4j的root logger配置。INFO,console的意思是“rootLogger级别为INFO输出到console这个Appender”。默认配置文件里还有DRFA、RFA等文件Appender定义但我们目前只需要关心console和INFO这两个词的组合逻辑。2. 临时任务怎么快速压掉INFO输出2.1 一次性会话用--hiveconf最省事如果你只是临时跑一条比较重的SQL不想永久改动集群配置直接在命令行加一个参数就行hive --hiveconf hive.root.loggerWARN,console -f your_script.sql我这里把INFO换成了WARN这样INFO级别的日志就被过滤掉了控制台只输出WARN以上的内容。实际跑完任务后该输出的结果集、运行统计、执行状态依然正常显示不会说日志级别调高就把关键信息也吞了。有人会问为什么不直接用--hiveconf hive.log.levelWARN我实际测试下来的结果是在某些Hive版本里hive.log.level会被log4j配置引用为rootLogger的level值但在另一些版本里hive.root.logger里的级别优先级更高你改了hive.log.level控制台照样刷INFO。所以追求稳定的话直接改hive.root.logger最保险。2.2 进入CLI之后再关有时候你已经启动了hive命令行不想退出重开。这种情况下也可以在当前会话里设置set hive.root.loggerWARN,console;但这里要提醒一句set命令对已经初始化完成的日志系统未必实时生效。log4j的Appender一般在Hive进程启动时就构建好了你在CLI里跑set很可能只是改了一个Hive配置项并没有重新配置日志系统。我的经验是进入CLI之后再设置经常无效所以更靠谱的做法是启动时就带上--hiveconf参数。如果你用的是beeline连接HiveServer2情况有些不同。beeline客户端的日志输出相对克制很多INFO日志在服务端侧客户端看到的并不多。beeline中可以用!set verbose true/false控制一些输出细节但如果你想彻底压掉客户端日志还是在启动命令上加参数更可靠beeline -u jdbc:hive2://node01:10000/default --hiveconf hive.root.loggerWARN,console2.3 在脚本里统一封装如果是经常要跑的批处理脚本不建议每次手敲参数。可以在你的shell脚本里定义公共变量#!/bin/bash HIVE_CMDhive --hiveconf hive.root.loggerWARN,console $HIVE_CMD -e select * from your_table;这样所有任务都走同一套日志级别配置以后想调整级别也只需要改一个变量。我在公司内部的数据平台脚本里基本都这么写维护成本非常低。3. 改配置文件一劳永逸的完整步骤3.1 先确认你用的是哪个配置文件这是整个改造过程中最关键的一步。Hive的日志配置文件根据版本和部署模式有不同的名字常见的组合如下版本/场景配置文件日志框架Hive 2.1.0之前hive-log4j.propertiesLog4j 1.xHive 2.1.0及之后log4j2.propertiesLog4j 2.xHiveServer2独立进程hiveserver2-log4j2.properties或同前缀propertiesLog4j 2.x / 1.x在动手改之前先到$HIVE_HOME/conf目录下看一眼实际存在的文件别拿网上旧教程套全新版本。我在一堆生产环境上就遇到过有人拿2.0版的教程去改3.1版的配置改完完全没有反应。3.2 改log4j2.propertiesHive 3.x最常用如果你用的是Hive 3.x版本日志配置文件是log4j2.properties用文本编辑器打开后找到rootLogger.level# 原始配置 status error name HiveLogging appender.console.type Console appender.console.name console appender.console.target SYSTEM_ERR appender.console.layout.type PatternLayout appender.console.layout.pattern %d{ISO8601} %-5p [%t] %c{2}: %m%n rootLogger.level INFO rootLogger.appenderRef.console.ref console rootLogger.appenderRef.DRFA.ref DRFA这里只需要改一行rootLogger.level WARN如果你用的是Hive 2.x早期对应的hive-log4j.properties文件修改的是hive.root.loggerINFO,console改成hive.root.loggerWARN,console这两类文件的改动方式不一样但核心逻辑都一样把rootLogger的级别从INFO提到WARN让INFO和DEBUG日志在源头被丢弃。3.3 更推荐的做法控制台不要INFO但文件保留INFO我在生产环境调完一轮之后形成了一个我个人很推荐的做法把控制台的INFO关掉但文件Appender里保留INFO。什么意思就是让日志完整写到文件里方便排查但终端窗口别刷屏。在hive-log4j.properties里你可以这样改hive.root.loggerINFO,DRFA注意我的写法级别还是INFO但Appender从console换成了DRFA。DRFA在默认配置里是DailyRollingFileAppender按天滚动写文件。这样控制台几乎不输出日志但/tmp/用户名/hive.log文件里还是完整记录了INFO级别以上的内容。在log4j2.properties里则要把console这个appenderRef去掉或者把console换成文件AppenderrootLogger.level INFO rootLogger.appenderRef.DRFA.ref DRFA很多老手在实际运维时都是这么干的因为完全把级别提到WARN虽然控制台干净了但遇到疑难问题想回看日志发现文件里也只有WARN很多关键线索已经丢了。控制台和文件解耦是日志配置里非常核心的一个思路。3.4 顺手把日志目录从/tmp挪走Hive默认把日志写在/tmp/${user.name}/hive.log。这个默认值在测试环境无所谓生产环境却很坑/tmp目录会被系统定时清理有时候日志没来得及排查就被删了还有多用户共用服务器时/tmp下不同用户的日志文件还可能互相干扰权限。我一般会在hive-site.xml里显式指定日志目录property namehive.log.dir/name value/data/hive/logs/value /property注意这个配置项写在hive-site.xml里是在Hive启动时读入的随后会传给log4j作为变量解析。提前把目录建好并给足权限再配合前面的Appender配置日志管理会顺畅很多。4. 关掉INFO之后常见的“不生效”怎么排查4.1 我改的就是这个文件为什么还是刷INFO这是最高频的疑问。先别急着怀疑配置格式按下面这个顺序排查一遍大部分问题都能定位到第一确认当前Hive进程是不是新起的。日志配置在进程启动阶段加载你改完文件之后原来挂着的Hive CLI或HiveServer2进程不会自动感知变化。CLI每次启动都是新进程影响不大但HiveServer2是长驻服务改完配置必须重启才生效。第二确认有没有环境变量覆盖了配置。Hive启动时会读取HIVE_OPTS这个环境变量如果你在~/.bashrc或hive-env.sh里加了类似export HIVE_OPTS-Dhive.root.loggerDEBUG,console的内容那命令行参数甚至配置文件的设置都可能被它压掉。排查方式很简单echo $HIVE_OPTS echo $HADOOP_OPTS如果输出里有-Dhive.root.logger...之类的值先把环境变量清掉再试。第三确认你用的是CLI还是HiveServer2。如果你改的是hive-log4j.properties但实际业务都是通过beeline连HiveServer2跑的那客户端日志真正读的是hiveserver2-log4j2.properties或HiveServer2进程的JVM参数。两边各改各的别改错对象。第四检查软链。有些发行版在$HIVE_HOME/conf目录下没有独立的log4j2.properties而是有一个指向其他位置的软链文件。用ls -l看一下文件属性如果是指向/etc/hive/conf之类的公共配置目录光改$HIVE_HOME/conf下的文件没用需要改真正指向的那个目标文件。4.2 为什么set hive.root.loggerWARN不生效这个我在第2节提过再展开说一遍。set命令修改的是Hive的配置会话变量但log4j框架在JVM启动时就已经用初始配置生成了Logger层级和Appender实例。Hive并没有在运行时监听这个配置项的变更并实时刷新log4j。换句话说你看到的“设置成功”只是Hive层面的一个假象日志框架层面根本没有收到通知。我验证过几次确认“启动参数 配置文件 set命令”这个优先级基本是稳定的。所以不要在运行时指望靠set来关INFO一定要回到启动命令或配置文件上去改。4.3 排查时怎么确认当前真实生效的日志级别有些时候你改来改去不确定到底哪份配置生效了有一个比较粗暴但有效的验证方式hive --hiveconf hive.root.loggerWARN,console -e select 1;如果这条命令执行时控制台不再刷INFO说明至少命令行这个入口的日志是走hive.root.logger这套逻辑的。然后再跑一个不带参数的普通hive命令做对比看有没有INFO刷出来。两次对比就能快速判断是配置没改对还是被其他配置覆盖了。还有一种更彻底的办法临时把你的hive-log4j.properties或log4j2.properties重命名备份重启Hive CLI如果日志系统正常降级到默认配置并打印警告说明你的配置文件确实被加载了如果没有变化说明你改的文件根本不是Hive加载的那个。4.4 权限和目录也会导致看似“不生效”日志文件写不写、写到哪和配置项hive.log.dir、hive.log.file强相关。如果你把hive.log.dir指定到了一个不存在的目录Hive启动时会尝试创建目录但如果目录创建失败日志文件也写不出来控制台反而显得很“正常”。这种情况下你以为配置生效了其实是文件日志没落地控制台日志被其他方式压住了。建议在改动配置后主动去看一眼目标日志文件是否在持续写入ls -l /data/hive/logs/hive.log tail -f /data/hive/logs/hive.log确认文件在动再判断级别是否真的生效。尤其是多个用户共用一套Hive环境时目录权限问题非常隐蔽经常出现“A用户正常、B用户不写日志”的情况本质就是B用户对日志目录没有写权限。5. 日志级别调整之外顺手做对的几个配置5.1 别把WARN和ERROR一起误杀把INFO关掉之后建议至少保留WARN和ERROR级别。很多人在调日志时容易走极端出于“日志太多了烦人”的想法直接把级别调到ERROR甚至FATAL最后任务出错时一点线索都没有。我的习惯是控制台一级调到WARN文件里保持INFO如果某个任务连WARN都不需要再单独针对该任务覆盖级别。这样既保证日常清爽又不影响问题排查。对于线上正在跑的批任务WARN级别通常已经能暴露大部分隐患比如分区覆盖警告、数据倾斜提示、配置冲突信息等这些往往比INFO有价值得多。5.2 日志文件的滚动与保留策略日志文件不滚动的话时间一长体积会很吓人。早期Hive的hive-log4j.properties里有DRFA和RFA两种Appender区别在于Appender滚动方式常用参数适用场景DRFA按天滚动DailyRollingFileAppender长期运行服务每天一个日志文件RFA按大小滚动MaxFileSize、MaxBackupIndex任务密集单文件增长过快实际配置示例log4j.appender.DRFAorg.apache.log4j.DailyRollingFileAppender log4j.appender.DRFA.File${hive.log.dir}/${hive.log.file} log4j.appender.DRFA.DatePattern.yyyy-MM-dd log4j.appender.RFAorg.apache.log4j.RollingFileAppender log4j.appender.RFA.File${hive.log.dir}/${hive.log.file} log4j.appender.RFA.MaxFileSize256MB log4j.appender.RFA.MaxBackupIndex10这里有一个坑要提DailyRollingFileAppender的MaxFileSize参数实际上不会真正触发按大小滚动因为按天滚动模式下日期变更才是滚动条件。如果你想严格按照文件大小滚动应该用RFA而不是DRFA。之前我见过有人把DRFA配了MaxFileSize日志涨到几个GB也不滚动误以为配置没生效其实就是Appender选错了。5.3 YARN任务日志的级别也要单独看Hive提交的MR任务运行期间的具体mapper/reducer日志不会显示在你的Hive CLI终端里它们被打到了YARN的Container日志中。如果你发现某个任务跑得很慢或者报错需要在YARN Web UI上查看对应Application的logs这时候INFO级别可能才是关键。Hive会话里可以这样单独调整任务日志级别set mapreduce.map.log.levelWARN; set mapreduce.reduce.log.levelWARN;这两个参数只影响YARN侧任务运行日志不影响Hive客户端日志。我建议在hive-site.xml里统一把MR任务日志级别设为WARN既减少日志量又避免日志落盘压力。注意这个参数对Tez引擎不同Tez引擎的日志级别通过tez.task.log.level控制需要分别处理。5.4 临时排查问题时要懂得“反向操作”关掉INFO是为了日常清爽但如果你真的在排查一个复杂的SQL问题INFO甚至DEBUG反而能帮你定位到具体是哪个Stage卡住、哪条数据触发了异常。这种时候不要犹豫临时开回DEBUGhive --hiveconf hive.root.loggerDEBUG,console -f debug_query.sql或者修改log4j2.properties重启HiveServer2把rootLogger.level暂时调成DEBUG。但务必记得DEBUG日志的量级可能是INFO的几十倍大任务开DEBUG不仅会刷屏还会拖慢执行速度严重时甚至把磁盘写满。用完一定要改回来。5.5 常用Hive日志配置项速查最后整理一份我在实际工作中经常用到的配置项方便你直接参考配置项作用推荐值hive.root.loggerrootLogger级别与输出目标WARN,console 或 INFO,DRFAhive.log.dir日志文件目录/data/hive/logshive.log.file日志文件名hive.loghive.log4j.file指定log4j配置文件路径默认$HIVE_HOME/conf下hive.server2.logging.operation.log.locationHS2操作日志目录/data/hive/operation_logsmapreduce.map.log.levelMR任务日志级别WARNmapreduce.reduce.log.levelMR任务日志级别WARNtez.task.log.levelTez任务日志级别WARN这里有一个容易被忽略的小点hive.server2.logging.operation.log.location它专门管理HiveServer2执行操作时的日志位置。如果你通过beeline连接HS2时发现任务日志很乱可以单独把这个目录独立出来跟CLI日志分开存。我在实际项目中见过一个很经典的场景数仓跑批任务每天凌晨定时调度Hive日志文件默认写在/tmp/调度用户/hive.log结果某天系统清理临时目录时把这个日志文件删了任务失败后想排查发现日志早没了。后来我把日志目录统一挪到独立磁盘路径同时配置了按大小滚动和保留10份历史再配合WARN展示级别的瘦身操作整个日志体系才算真的稳定下来。关掉INFO显示只是第一步把日志这家伙关进合理的“笼子”后续排查问题你才会真正省心。
