Настройка ведения журнала Hadoop, чтобы избежать слишком большого количества файлов журнала

У меня возникла проблема с Hadoop, производящим слишком много файлов журнала в $HADOOP_LOG_DIR/userlogs (файловая система Ext3 допускает только 32000 подкаталогов), которая похожа на ту же проблему в этом вопросе: Ошибка в Hadoop MapReduce

Мой вопрос: кто-нибудь знает, как настроить Hadoop для свертывания журнала или иным образом предотвратить это? Я пытаюсь избежать установки свойств "mapred.userlog.retain.hours" и/или "mapred.userlog.limit.kb", потому что я хочу сохранить файлы журнала.

Я также надеялся настроить это в log4j.properties, но, глядя на источник Hadoop 0.20.2, он записывает непосредственно в logfiles вместо фактического использования log4j. Возможно, я не понимаю, как он полностью использует log4j.

Приветствуются любые предложения или разъяснения.

Ответ 1

К сожалению, не существует настраиваемого способа предотвратить это. Каждая задача для задания получает один каталог в истории/пользовательских журналах, в котором будут храниться выходные файлы stdout, stderr и syslog. Часы удержания помогут сохранить слишком много из накопившихся, но вам нужно написать хороший инструмент для поворота журнала, чтобы автоматически настроить их.

У нас была и эта проблема, когда мы писали на NFS-mount, потому что все узлы имели бы один и тот же каталог history/userlogs. Это означает, что одной работы с 30 000 задач будет достаточно, чтобы разбить FS. Логгирование локально - это действительно путь, когда ваш кластер фактически начинает обработку большого количества данных.

Если вы уже регистрируетесь локально и все еще можете обрабатывать 30 000 задач на одном компьютере менее чем за неделю, то вы, вероятно, создаете слишком много небольших файлов, что приводит к появлению слишком большого числа mappers для каждого задания.

Ответ 2

У меня была такая же проблема. Перед запуском Hadoop установите переменную среды "HADOOP_ROOT_LOGGER = WARN, консоль".

export HADOOP_ROOT_LOGGER="WARN,console"
hadoop jar start.jar

Ответ 3

Настройка hadoop для использования log4j и установки

log4j.appender.FILE_AP1.MaxFileSize=100MB
log4j.appender.FILE_AP1.MaxBackupIndex=10

как описано в эта страница wiki не работает?

Глядя на исходный код LogLevel, похоже, что hasoop использует запись в сообществах, и он попытается использовать log4j по умолчанию, или jdk logger, если log4j не находится в пути к классам.

Btw, можно изменить уровни журналов во время выполнения, взгляните на руководство .

Ответ 5

Я также столкнулся с той же проблемой... Hive производит много журналов, и когда диск node заполнен, больше контейнеров не может быть запущено. В Yarn в настоящее время нет возможности отключить ведение журнала. Одним файлом, особенно огромным, является файл syslog, который генерирует GBs журналов за несколько минут в нашем случае.

Конфигурирование в "yarn-site.xml" свойство yarn.nodemanager.log.retain-seconds до небольшого значения не помогает. Установка "yarn.nodemanager.log-dirs" на "файл:///dev/null" невозможна, потому что нужен каталог. Удаление записи (chmod -r/logs) тоже не сработало.

Одним из решений может быть каталог "null blackhole". Проверить здесь: https://unix.stackexchange.com/info/9332/how-can-i-create-a-dev-null-like-blackhole-directory

Другое решение для нас - отключить журнал до запуска заданий. Например, в Hive, начиная с script с помощью следующих строк:

set yarn.app.mapreduce.am.log.level=OFF;
set mapreduce.map.log.level=OFF;
set mapreduce.reduce.log.level=OFF;