У меня есть работа Spark с очень длинными работами. Когда задачи запускаются, я могу перейти на вкладку «Исполнители» и увидеть всех моих исполнителей и их задачи. Я могу щелкнуть ссылку stderr, чтобы увидеть журналы для этих задач, которые помогают многому контролировать. Однако через несколько часов ссылка stderr перестает работать. Если вы нажмете на него, вы получите java.lang.Exception: Cannot find this log on the local disk.. Я впился в бит, и проблема, похоже, в том, что что-то решил gzip журналы. То есть я все же могу вручную найти журнал с помощью ssh-ing на рабочем узле и посмотреть в правильном каталоге (например, /mnt/var/log/hadoop-yarn/containers/application_1486407288470_0005/container_1486407288470_0005_01_000002/stderr.gz). Досадно, что это происходит, так как теперь я не могу контролировать свою работу из пользовательского интерфейса. Кроме того, файлы довольно маленькие, поэтому сжатие не кажется полезным (40k несжатым). Кажется, что есть много вещей, которые могут быть причиной этого: пряжа, задание logroller cron, конфигурация log4j в моем дистрибутиве пряжи/искры, AWS (поскольку EMR zips регистрирует и сохраняет их на S3) и т. Д., Поэтому Я надеюсь, что кто-то может указать мне в правильном направлении, поэтому мне не нужно искать тонну документов.Остановить журналы исполнителя Spark от получения gzipped
Я использую AWS EMR по адресу emr-5.3.0 без каких-либо пользовательских шагов начальной загрузки.
Итак, это прерывистый? –
Да. Это происходит только с длительными работами и не всегда случается со всеми исполнителями. –