Путь к файлу Ubuntu 18.10 Tomcat8 catalina.out

Кажется, что запись в catalina.out была прервана в 18.10. tomcat8 регистрирует в catalina.out через rsyslog, как вы можете видеть в /etc/rsyslog.d/tomcat8.conf пакета

$template TomcatFormat,"[%timegenerated:::date-year%-%timegenerated:::date- 
month%-%timegenerated:::date-day% %timegenerated:::date- 
hour%:%timegenerated:::date-minute%:%timegenerated:::date-second%] 
[%syslogseverity-text%]%msg%\n"

:programname, startswith, "tomcat8" {
  /var/log/tomcat8/catalina.out;TomcatFormat
  stop
}

К сожалению, похоже, что разрешения на Ubuntu 18.10 для rsyslog не являются правильными для этой работы. Я нашел это в моем системном журнале:

rsyslogd: файл '/var/log/tomcat8/catalina.out': ошибка открытия: в доступе отказано [попытка v8.32.0 http://www.rsyslog.com/e/2433 ]

Это заставляет rsyslog отправлять все журналы tomcat8 в /var/log/syslog

Как побочный эффект, это заставляет его думать, что на catalina.out есть "бессмысленный" логротат. Вероятно, он по-прежнему будет работать.

Убедитесь, что у системного журнала группы есть права на запись в файл catalina.out, а затем перезапустите rsyslog. Ведение журнала должно вести себя нормально с этого момента.

Один (наивный) способ обеспечить это разрешение:

sudo service tomcat8 stop
sudo touch /var/log/tomcat8/catalina.out
sudo chown tomcat8:syslog /var/log/tomcat8 -R
sudo chmod g+rwx /var/log/tomcat8
sudo chmod g+rw /var/log/tomcat8 -R
sudo chmod g+s /var/log/tomcat8 -R
sudo service rsyslog restart
sudo service tomcat8 start

(это в основном комментарий - но его немного долго, чтобы публиковать в разделе комментариев - и я ненавижу ответы, в которых просто говорится: "Я сделал это, и это сработало")

Ведение журнала Tomcat9 похоже на беспорядок в Ubuntu 18.10.

У меня также есть журналы веб-доступа, записываемые в / var/log/tomcat9.

Хотя я вижу файлы, описанные @Christina, там нет упоминания о файлах localhost_access_log.YYYY-MM-DD.txt.

Хотя файлы catalina*.out названы с указанием даты, то есть даты создания файлов, они не меняются.

Однако что-то потом их сжимает. Оказывается, это задание cron (/etc/cron.daily/tomcat9). Это соответствует именованию файлов, используемому в конфигурации ведения журнала Tomcat, но не заставляет Tomcat очищать и закрывать журналы.

Файлы журнала принадлежат пользователю tomcat (подразумевая, что они не поддерживаются rsyslog), и когда я проверяю с помощью fuser дескрипторы открытых файлов имеет tomcat, а не rsyslog.

Мне кажется, что ошибки в разрешении на создание отчетов / var / log / syslog, в котором отказано для rsyslog, являются отвлекающим маневром - существует конфигурация rsyslog, но конфигурация Tomcat по умолчанию не отправляет журналы в syslog. Действительно, поскольку он использует java.util.logging, он не может напрямую отправлять данные системного журнала в rsyslog.

Сценарий logrotate также не работает / не имеет отношения к тому, как tomcat9 настроен для ведения журнала. Он использует неправильный шаблон файла и ничего не делает, чтобы сообщить tomcat, чтобы он очистил / повторно открыл свои файлы журнала.

Таким образом, у нас есть три различных механизма для управления журналами в пакете, ни один из которых не обеспечивает решения для ротации журналов и фактически нарушает целостность ваших файлов журналов.

Поскольку я планирую реализовать агрегацию журналов, вместо того, чтобы исправлять файловый механизм, я решил пойти вниз по корню отправки данных в syslog. Сборка Tomcat по умолчанию в Ubuntu использует java.util.logging для обеспечения возможности ведения журнала. Хотя он поддерживает ведение журнала на основе сетевых сокетов, он не реализует протокол сообщений системного журнала. Однако процессом tomcat управляет systemd, и конфигурация tomcat по умолчанию отправляет сообщения журнала в stdout, а также в файлы, поэтому я внес поправки/lib/systemd/system/tomcat9.service чтобы добавить эти строки:

StandardOutput=syslog
StandardError=syslog

Обратите внимание, что уже есть запись для SyslogIdentifier=tomcat.

Это помещает данные в rsyslog. Следующий шаг - вывести его из rsyslog в файл. Я добавил новый файл (/etc/rsyslog.d/10-symcbean.conf), содержащий:

$CreateDirs on

template(name="myfile" type="string"
     string="/var/log/apps/%programname%.log")

if ($programname startswith "tomcat") then {
     action(type="omfile" dynaFile="myfile")
     stop
}

(здесь строка "начинается с" относится к "SyslogIdentifier" в конфигурации systemd).

Я также создал каталог /var/log/apps, принадлежащий tomcat: syslog (пользователю tomcat не нужен доступ к этому каталогу для стандартных журналов, которые теперь обрабатываются rsyslog, но я буду писать туда и свои журналы сборки мусора).

Тогда это был просто вопрос перезапуска rsyslog и tomcat, и я увидел те же записи журнала, которые появились в /var/log/apps/tomcat.log, что и записывались в / var/log/tomcat9. Следующим шагом будет удаление напрямую записанных журналов в / var / log / tomcat9 путем редактирования /var/lib/tomcat9/conf/logging.properties следующим образом:

# handlers = 1catalina.org.apache.juli.AsyncFileHandler, 2localhost.org.apache.juli.AsyncFileHandler, java.util.logging.ConsoleHandler
handlers =  java.util.logging.ConsoleHandler

# .handlers = 1catalina.org.apache.juli.AsyncFileHandler, java.util.logging.ConsoleHandler
.handlers =  java.util.logging.ConsoleHandler

Мне не нужны журналы веб-доступа, поскольку HTTP-трафик передается через прокси-сервер nginx, который обрабатывает необходимые журналы. Для них я закомментировал запись в conf/server.xml.

Последняя часть головоломки - включить ротацию журналов. Это новый файл в /etc/logrotate.d, содержащий:

/var/log/apps/tomcat*.log
{
        rotate 20
        su syslog syslog
        create 0644 syslog syslog
        daily
        dateext
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

(подстановочный знак в имени файла позволяет использовать разные потоки журналов / несколько файлов журналов).