Apache Tomcat is the Java web server that implements many Java features like web site APIs, Java server pages, Java Servlets, etc. It’s an open-source software widely used in the industry. Tomcat sits on top of your application and is the entry point for reaching your application code. It is crucial to monitor its performance and make sure everything works, get notified when unexpected errors occur, and take action in real-time. Like other web servers, it also produces a lot of logs that are instrumental in troubleshooting.
The Apache Tomcat logs are information about your resources—what they are, who is accessing which ones, and at what time. In this article, I’ll show you how to look at Tomcat logs, their different types, log locations, and log rotation.
What Are Tomcat Logs?
Tomcat logs are the files that keeps information related to web server issues and server tasks in proper files in given locations. It’s important to understand logging on the Tomcat server because this tells you if there’s any issue with the server and if so, whether it’s functional or performance related. There can be multiple types of logs segregated into different file locations. Knowing these locations will help you debug issues faster.
Tomcat global logs, called Catalina logs, are some of the most important log types present. There are others too, like application logs and localhost logs. I’ll be discussing all of these and how they can help you. But before that, let’s look at the configuration needed to enable logging in Tomcat.
To collect Tomcat logs, you first need to enable logging. Logging in Tomcat is handled by the Java Utility Logging Implementation, also known as JULI. JULI is enabled by default, and you can perform this configuration using the logging configuration file option -Djava.util.logging.config.file=”logging.properties”:
- Globally:
${catalina.base}/conf/logging.properties.This file is specified by thejava.util.logging.config.filesystem property. If you don’t configure it, the default file will be${java.home}/lib/logging.propertiesin the JRE. - In the web application:
Use WEB-INF/classes/logging.properties.
If you don’t want to use JULI, there are other logging frameworks like log4j, log4j2, or Logback. Let’s take log4j as example.
To configure log4j for logging, just create a log4j.properties file and use log4j.jar. You can put the log4j.properties file into the $CATALINA_BASE/lib folder.
There are multiple options provided to configure the log4j logs. A few of the important ones are log4j.appender.CATALINA.File, which configures the location of the file; log4j.appender.CATALINA.Encoding can configure the encoding; and the UTF-8.log4j.appender.LOCALHOST.DatePattern option, which helps in configuring the log rotation based on date pattern.
For configuring Manager, Localhost, Host-Manager, and Catalina logs, the configuration parameters start with prefixes: log4j.appender.MANAGER for Manager, log4j.appender.HOST-MANAGER for Host Manager, log4j.appender.LOCALHOST for localhost, and log4j.appender.CATALINA for Catalina. You can see the exact instructions in the Tomcat documentation.
Tomcat Log Levels
As with any other logging framework, JULI also has log levels that define the severity of the log and the information it contains. JULI log levels consist of:
- SEVERE: Information pertaining to a serious problem
- WARNING: Could be an issue in the future
- INFO: Informational messages
- CONFIG: Configuration information (listed when log level is set to config)
- FINE: Trace logs
- FINER: More-detailed trace logs
- FINEST: Highest-detailed trace logs
These log levels are sorted in the order of the details that they feature. So, SEVERE has only very important information, while FINEST presents you with the most information. Please note that having a lot of information in your logging can have a performance impact on your disk’s I/O and increase your system’s load average.
Log levels can be set for different handlers from the logging.properties file found in $CATALINA_BASE/conf:
For example, set the com.xyz.foo logger to only log SEVERE # messages:
org.apache.catalina.startup.ContextConfig.level = SEVERE org.apache.catalina.startup.HostConfig.level = SEVERE org.apache.catalina.session.ManagerBase.level = SEVERE
Tomcat Logs Location
The location of your Tomcat logs can differ depending on your operating system or containerzied platform. Below are a few of those default locations:
- Linux: The log will be present by default at
/var/log/tomcat/*.log. In some cases, you will also find it at/opt/tomcat/logs. - Windows: In Windows, the logs will be present at the location where your software is, something like this:
C:program filesapache software foundationapache-tomcat{ver}logscatalina.out - Docker: By default, the logs will be printed to STDOUT and STDERR so that the logging agents on the nodes can get these logs and push them to a centralized place.
- Kubernetes: You can configure your logging agent to read the logs from the standard output and standard error from the containers.
You can easily change where your Tomcat logs are stored using the CATALINA_OUT variable.
Tomcat Log File Types
There are multiple log files that Tomcat produces for its different components. The most important are all the Catalina logs since you can easily find most information in these files.
Catalina Logs
Tomcat Catalina produces two types of Catalina log files: catalina.log and catalina.out.
Catalina.log
This is the global log file used to save information like server admin operations, for example, server stop, start, restart, deployment of a new application, and failure of a subsystem. If you want to make changes to this log format, do so in the java.util.logging.SimpleFormatter.format variable. You can configure the location of the file in the $CATALINA_OUT parameter, or it will be present by default at CATALINA_HOME/logs.
Catalina.out
The servlet and error logs will be written in the catalina.out log file. This file can also contain thread dumps and uncaught exceptions.
You can make changes to the format of catalina.out in the java.util.logging.SimpleFormatter.format variable. The location of this file is defined in the $CATALINA_OUT parameter or is present by default at CATALINA_HOME/logs.
Localhost Log
These are the logs that track the activity log of your web application, e.g., the transactions between the application server and clients. These log files are present in the Tomcat home directory inside the logs folder.
Localhost Access Log
There can be cases where the application server has to make a call to another service, i.e., outbound HTTP requests. The localhost access log keeps track of all these requests. Localhost access logs are also found in the same location as the localhost logs inside the log directory of the Tomcat home directory.
Access Log
Tomcat access logs can give you information about who has access to your application, what resources were accessed, the IP, queries, date, etc. These are some of the most important logs for traffic analysis and can be configured via the server.xml file inside the conf directory in the Tomcat home directory.
Manager Log
These logs keep information on all the activities performed by the Tomcat manager, including lifecycle management, application deployment, etc. These logs can be configured in the logging.properties configuration file present at TOMCAT_HOME/conf.
Log Rotation
There can be lots of logs produced by Tomcat. You need a way to archive the older ones so that your disk doesn’ get filled up. To achieve this, you have to hand over the Tomcat log rotation to the default log rotate engine in the operating system. For example, in the case of Linux, you can do this easily using logrotate. Simply create a file using the command:
touch /etc/logrotate.d/tomcat
And then put the following into the file; this can be tweaked per your needs for log rotation:
/{PATH_TO_CATALINA_FILE}/catalina*.* {
copytruncate
daily
rotate 7
compress
missingok
size 100M
}
This configuration will start the log rotation for you. You can also write similar files if you want to implement log rotation separately for different types of Tomcat logs.
How to View Tomcat Logs
There is no utility to look at Tomcat logs, so you have to rely on your operating system tools. For example, in the case of Linux, you can use less or tail commands to look at your logs:
less filename.log tail -f filename.log
Given that you generally have a lot of machines running as Tomcat servers, it’s a very tricky task to run these commands on all those machines and get the logs. You need to have a place where you can push these logs and query on top of it. This is centralized logging, which you need when you have a lot of machines and it is humanly impossible to look at all the logs.
How to Disable Tomcat Logging
Logging can be costly for disk IOPS if we don’t do it properly, so you may want to disable the logging of Tomcat in some cases. To do this, you’ll need to make changes in the logging.properties file. To do that, comment the block below in the logging.properties file:
handlers = 1catalina.org.apache.juli.AsyncFileHandler, 2localhost.org.apache.juli.AsyncFileHandler…
To disable the access log, you have to remove the following block from the server.xml file:
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
Apache Tomcat Log Analysis and Monitoring with Sematext
Sematext Logs is a log management solution that can get all your distributed logs for Apache Tomcat servers in one place. Sematext collects the logs from your Tomcat servers by installing a small agent on the host machine. It then starts collecting the data and sends it to Sematext collector servers, where the data will be available for you to view, analyze, or create dashboards from. Sematext has advanced features like auto-discovery, out-of-the-box dashboarding, alerting, anomaly detection, and communication support for different channels.
In addition, Sematext Logs is part of the Sematext Cloud observability solution, which includes a monitoring solution that can capture Tomcat metrics. When correlated with logs, these metrics present great value, enabling you to debug issues faster than before. For example, if you see any 5xx or 4xx issues, and there are logs for the same, it becomes easy to see why these errors are occurring.
Conclusion
When you’re running any application with Tomcat, it’s good to have visibility into what Tomcat and its different components are actually doing. To do this, you need access to logs and a way to look at them. Logs present you with information like if the servers are restarted, if there was any error, etc. You also want to have visibility on the type of traffic coming in and throughput.
Sematext provides a platform to achieve centralized logging and analysis to easily keep an eye on your application. With its advanced features like dashboarding, alerting, and anomaly detection, it becomes simple to monitor your Tomcat infrastructure.
Watch the video below to learn more about Sematext Logs or start a 14-day free trial to see how it can help your log management for Apache Tomcat web servers.
Author Bio
Gaurav Yadav
Gaurav has been involved with systems and infrastructure for almost 6 years now. He has expertise in designing underlying infrastructure and observability for large-scale software. He has worked on Docker, Kubernetes, Prometheus, Mesos, Marathon, Redis, Chef, and many more infrastructure tools. He is currently working on Kubernetes operators for running and monitoring stateful services on Kubernetes. He also likes to write about and guide people in DevOps and SRE space through his initiatives Learnsteps and Letusdevops.
Start Free Trial
How do I check the container log of tomcat?
I get this error from the catalina.out log:
SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal One or more listeners failed to start. Full details will be found in the appropriate container log file
But where can I find the «appropriate container log» that this log is referring to?
Thanks in advance.
kc2001
5,0384 gold badges50 silver badges90 bronze badges
asked Apr 14, 2016 at 8:34
You’ll find the referenced log file in the same directory containing the log referencing the other log file. With a default installation of Tomcat, the directory is $CATALINA_HOME/logs. The log file containing the information referenced will usually be the one named with the hostname on which Tomcat is running. On a simple server (e.g. development environment) this is localhost.<datestamp>.log. The additional error information can be found in this log file at the same timestamp as the noted reference in the referring log file.
answered Jul 6, 2017 at 12:47
dandan
7229 silver badges14 bronze badges
I bumped into the same issue while working on a web application.
Tomcat logs did not show full stack trace and application has more than one listeners, it may get challenging to figure out the issue.
After some browsing, below is what helped me find the error.
Create a file logging.properties with the following content, place it inside Apache-tomcatwebappsMyAppWEB-INFclasses and restart the Apache Tomcat server.
org.apache.catalina.core.ContainerBase.[Catalina].level=INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers=java.util.logging.ConsoleHandler
answered Feb 20, 2019 at 10:20
Nagaraja JBNagaraja JB
7298 silver badges17 bronze badges
2
I installed Tomcat6 on a Ubuntu 9.04 server using apt-get install tomcat6. I uploaded a WAR using the manager interface and tried to start the application but get a pretty generic error on the Web interface saying it couldn’t be started.
I am trying to find the logs to determine why my war won’t start (I suspect low memory as i’m on a small VPS) but I don’t know where they are.
/var/lib/tomcat6/logs is empty. My Tomcat splash page reliably informs me of the following;
Tomcat is installed with CATALINA_HOME in /usr/share/tomcat6
CATALINA_BASE in /var/lib/tomcat6,
following the rules from /usr/share/doc/tomcat6-common/RUNNING.txt.gz.
UPDATE
I tried running;
$ ps -ax
/usr/bin/jsvc -user tomcat6 -cp /usr/share/java/commons-daemon.jar:/usr/share/tomcat6/bin/bootstrap.jar -outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
But there is nothing in /var/log/syslog
Also runing
$ losof -p PID
didn’t show any log files…
$ for PID in $(pgrep jsvc);do sudo ls -l /proc/$PID/fd|grep ' 1 -> ';done
l-wx------ 1 root 500 64 2010-03-30 13:29 1 -> pipe:[301470406]
lrwx------ 1 root 500 64 2010-03-30 13:29 1 -> /dev/null
l-wx------ 1 root root 64 2010-03-30 13:29 1 -> pipe:[301470406]
Thanks,
Gav
Corey S.
2,4671 gold badge19 silver badges23 bronze badges
asked Mar 30, 2010 at 12:20
Very late to this discussion, but it appears that the 03catalina.policy file in both tomcat5.5 & tomcat6 doesn’t actually permit writing to logfiles.
The simplest solution is to change the JULI permissions to:
// These permissions apply to JULI
grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
permission java.security.AllPermission;
};
Obviously, there may be security issues I’m not aware of, but I really can’t be bothered to dig deeper — I’ve spent too long on this myself.
answered Jul 24, 2012 at 19:18
AuspexAuspex
2433 silver badges8 bronze badges
1
A neat trick is to run the command «lsof -p PID» where PID is the process id of your tomcat server. This command will give you a list of all files opened by the process, including the log file. See Wikipedia page.
answered Mar 30, 2010 at 13:23
dogbanedogbane
9545 silver badges8 bronze badges
3
By default check
/var/log/tomcat6/catalina.out
or something like that
and check logging properties in
/usr/share/tomcat6/conf/logging.properties
usually /usr/share/tomcat6/conf/ is symbolic link to /etc/tomcat6/
answered Mar 30, 2010 at 13:10
LanselotLanselot
1,2189 silver badges5 bronze badges
1
They should be at CATALINA_HOME/logs
I’ve seen it most often at /opt/tomcat/logs, but in your case it might be /usr/share/logs
answered Mar 30, 2010 at 13:35
BozhoBozho
8091 gold badge7 silver badges13 bronze badges
By default Tomcat logs are in /var/log/tomcat? and /var/lib/tomcat7/logs usually points to there.
As root, you may check them by:
tail -f /var/log/tomcat7/*.log /var/log/tomcat7/*.txt /var/log/tomcat7/*.out
If you still have any issues, try finding them via:
sudo lsof | grep -E "java.*(out|txt|log)$"
answered Apr 10, 2015 at 15:25
kenorbkenorb
6,3632 gold badges44 silver badges54 bronze badges
we can find logs like below for Windows.
C:Program FilesApache Software FoundationTomcat 9.0logs
also refer C:Program FilesApache Software FoundationTomcat 9.0conflogging-properties.
answered Jun 20, 2018 at 0:08
3
#Ansible: Compress tomcat access logs
@daily find /var/log/tomcat/*.txt -type f -mtime +0 -exec gzip {} ; 2> /dev/null
#Ansible: Delete tomcat access logs
@daily find /var/log/tomcat/*.txt.gz -type f -mtime +30 -exec rm {} ; 2> /dev/null
В настоящее время цикл разработки программного обеспечения идет огромными темпами. Все организации имеют базы кодов, содержащие огромное количество кодов, состоящих из связанных между собой веб-страниц. Есть много обстоятельств, когда система дает сбой или ведет себя неожиданно.
Чтобы проанализировать и отладить проблему, разработчики и системные администраторы просматривают файлы журнала, чтобы найти проблемы системы. На самом деле, когда система не работает, файлы журналов часто используются в качестве основного источника информации.
В каждой системе системные администраторы поддерживают все действия, связанные с запросами, полученными от различных пользователей, и сохраняют их в файле, который называется файлами журнала.
Для отладки системы мы можем обращаться к отдельным файлам журнала, чтобы получить представление о системе и перемещаться по различным временным меткам, чтобы узнать состояние системы.
В этой статье мы рассмотрим особенности этих журналов ниже: мы рассмотрим, что хранится в журналах доступа Apache, где их найти и как просматривать журналы доступа Apache Tomcat. Это заставляет системных администраторов отслеживать всю информацию и действия, происходящие в их системе.
Журналы доступа Apache — это один из видов файлов журналов, создаваемых HTTP-сервером Apache, как описано выше. Этот файл журнала отвечает за сохранение информации обо всех запросах, обрабатываемых сервером Apache Tomcat.
В результате, если кто-то посещает страницу вашего сайта, файл журнала доступа будет содержать информацию об этом.
Это знание полезно в нескольких ситуациях: если конкретный запрос не выполняется для каждого человека, пытающегося получить доступ к веб-странице, или в ситуации, когда возникает задержка в генерации ответа, мы можем пройти через сценарии SQL и оптимизировать их.
Если одна из страниц сайта является особенно распространенной, агрегирование данных из журналов доступа может выявить запрашиваемые ресурсы, что позволит компаниям повысить свою популярность, предлагая более релевантные материалы.
Как просмотреть журналы доступа Apache Tomcat?
Расположение журналов определяется операционной системой, в которой HTTP-сервер Apache настроен для выполнения программы. Дистрибутивы Linux запускают большую часть экземпляров HTTP-сервера Apache. Итак, в этой статье мы сконцентрируемся на том, где найти и просмотреть журналы доступа Apache Tomcat на машине Linux.
В случае ядра/операционной системы Ubuntu и Linux эти записи журнала можно найти в следующем месте:
/var/log/apache2/access.log
Некоторые дистрибутивы Linux могут иметь разные местоположения по умолчанию, но в большинстве случаев вам не придется далеко ходить. На директиву CustomLog можно ссылаться и обновлять ее на сервере Tomcat Apache.
Директива CustomLog также берет на себя ответственность за сохранение места, где он хранится, и указывает формат, в котором он должен быть сохранен.
Извлечение информации из журналов доступа Apache
Теперь мы опишем, как просматривать файлы журнала доступа и интерпретировать данные из них. Извлечение информации может помочь ИТ-специалистам и командам разработчиков использовать ее.
Чтение журналов доступа Apache
Чтобы разобраться в журналах доступа Apache, аналитик должен сначала рассмотреть формат, в котором хранятся журналы.
Как было сказано ранее, формат и место для доступа к журналам указываются в каталоге CustomLog. Ниже мы рассмотрим два распространенных формата журналов, которые широко используются для журналов доступа Apache.
Общий формат журнала (CLF)
CLF — это формат структурированного текстового файла для создания файлов журнала сервера, которые используются различными серверами веб-приложений. Популярный формат журнала можно использовать с HTTP-сервером Apache для создания журналов доступа, которые легко читать разработчикам и администраторам.
Некоторые системы анализа журналов могут легко использовать файлы журналов в формате CLF. Это структурированный формат, используемый многими веб-серверами. Ниже приведен тип записи журнала доступа, записанной в CLF:
127.0.0.1 - sccott [10/Nov/2020:13:55:35 -0700] "GET /server-status HTTP/1.1" 200 2326
Дефис: дефисы идентифицируют клиента во втором поле внутри файла журнала.
127.0.0.1: Client’s IP address.
«GET/server-status HTTP/1.1» — ресурс и тип ресурса, запрашиваемые пользователем.
200 - HTTP OK-response (status-code); 2326 - Response of HTTP request object's size
Комбинированный формат журнала (CLF)
CLF — еще один распространенный формат журналов доступа Apache. Этот формат почти такой же, как и в популярном формате журнала, но включает в себя еще несколько полей, чтобы предоставить более подробную информацию для отладки и подробного анализа. Ниже приведен тип записи журнала доступа, записанной в CLF:
27.0.0.1 - sccott [10/Dec/2019:13:55:36 -0700] "GET /server-status HTTP/1.1" 200 2326 "http://localhost/" "Mozilla/5.1 (Win NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
Поскольку видно, что начальные семь полей являются общими для описанного выше формата, больше полей в формате следующие:
"http://localhost/"
Это показывает адрес клиентской системы.
"Mozilla/5.1 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
User-Agent определяет информацию о браузере, используемом клиентом для доступа к ресурсу.
Директива CustomLog
Ранее мы заявляли, что директива CustomLog в файле конфигурации HTTP-сервера Apache используется для настройки журналов доступа Apache. Здесь мы можем посмотреть на пример конфигурации журналов, чтобы увидеть, насколько гибкими являются директивы пользовательских журналов:
LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
CustomLog /var/log/apache2/access.log combined
Выше мы использовали директиву Log Format для определения комбинированного LF, а директива CustomLog для определения местоположения, которое он хранит, вместе с ним определяет формат (combined) для журнала доступа, в котором он должен храниться.
Как видите, изменение местоположения или формата журнала доступа — простая процедура. Кроме того, использование директивы CustomLog дает нам несколько других преимуществ, о которых мы поговорим позже.
Журналы множественного доступа (MAL)
Нет никаких ограничений, которые мешали бы вам настроить MAL для вашего сервера Apache Tomcat. Таким образом, процесс, которому обычно следуют, очень прост, поскольку вам нужно создать больше директив Custom Logs для создания вашего персонализированного файла журнала:
LogFormat "%h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%{User-agent}i" agent
CustomLog /var/log/apache2/access.log combined
CustomLog /var/log/apache2/agent_access.log agent
Условные журналы
Также весьма вероятно, что запись в журналы доступа будет выполняться на условной основе. Это полезно для многих целей, например для исключения записей, относящихся к отдельным клиентам. Установка всех переменных среды и обращение к ним с ключевым словом «env» обычно зависит от того, как это достигается.
Вращение логов и логи piped
Файлы журнала, как и все остальное на компьютере, занимают место. А файлы журналов, такие как журналы доступа, могут быстро развиваться на загруженном сервере Tomcat. Следовательно, важно иметь протоколы для регулярной передачи или удаления старых файлов журналов. К счастью, HTTP-сервер Apache может сделать это с помощью плавных перезапусков и конвейерных процедур журналирования.
Перезапуск сервера Apache Tomcat работает хорошо, потому что он перезапускается без потери клиентских подключений.
Этот вид перезапуска заставляет Apache открываться и перезаписывать новые файлы журналов, не прерывая работу клиентов, разрешая обработку для сжатия или удаления ранее использованных файлов журналов для сохранения новых.
С другой стороны, протоколируемые процессы Pipe разрешают ротацию деталей журнала, не требуя повторного перезапуска сервера; например, HTTP-сервер Tomcat Apache включает программу под названием rotate-logs.
Вместо записи на диск в это приложение можно передать записи журнала доступа. Программное обеспечение rotate-logs позволяет вращать журналы в зависимости от времени или расстояния условно.
Заключение
Мы упомянули полную информацию о просмотре журналов доступа Apache Tomcat и извлечении данных из файлов журналов различных форматов. Разработчики и системные администраторы должны знать, как просматривать файлы журналов и получать навыки отладки, чтобы обеспечить их бесперебойную работу.
Таким образом, доступ к журналу Apache — это один из способов глубже погрузиться в систему с помощью сервера tomcat для отладки системы, перехода к любой временной метке и проверки состояния системы в соответствии с требованиями.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.