#hadoop #cascading #mapr
#hadoop #каскадирование #mapr
Вопрос:
Когда наши каскадные задания обнаруживают ошибку в данных, они генерируют различные исключения… Они попадают в журналы, и если журналы заполняются, кластер перестает работать. есть ли у нас какой-либо конфигурационный файл для редактирования / настройки, чтобы избежать подобных сценариев?
мы используем MapR 3.1.0 и ищем способ ограничить использование журналов (системные журналы / журналы пользователей), без использования централизованного ведения журнала, без настройки уровня ведения журнала, и нас меньше беспокоит, сохраняет ли он первые N байтов, или последние N байтов журналов и разногласий остаются частью.
На самом деле мы не заботимся о журналах, и нам нужны только первые (или последние) несколько мегабайт, чтобы выяснить, что пошло не так. Мы не хотим использовать централизованное ведение журнала, потому что на самом деле мы не хотим хранить журналы / не хотим тратить накладные расходы на их репликацию. Кроме того, поправьте меня, если я ошибаюсь: user_log.retain-size , имеет проблемы при повторном использовании JVM.
Любая подсказка / ответ будут с благодарностью приняты!!
Спасибо,
Шринивас
Ответ №1:
Вероятно, это должно быть на другом сайте StackExchange, поскольку это скорее вопрос DevOps, чем вопрос программирования.
В любом случае, вам нужно, чтобы ваш DevOps настроил logrotate и настроил его в соответствии с вашими потребностями. Или отредактируйте XML-файлы log4j в кластере, чтобы изменить способ ведения журнала.
Комментарии:
1. ITYM «вы можете просто передать эту проблему своему традиционному системному администратору, который задокументирует ответ, чтобы другие могли его найти». В магазине DevOps разработчики могут работать над определением ротации журналов и т. Д. И Делиться своими ответами здесь.
2. Это справедливое замечание @dannyman, я предполагаю, что грань между операционными системами и разработчиками была размыта благодаря DevOps, и, следовательно, линия относительно того, что должно или не должно быть на SO, была размыта.