Linux系统如何查看Tomcat日志文件？Tomcat日志文件再哪里？

Tomcat查看日志的方法命令

启动Tomcat服务后，项目出现bug、报错或者异常时候需要查看日志，那么Tomcat日志文件在哪里？
1. Tomcat日志文件路径

Tomcat的日志文件在Tomcat安装目录下的logs文件夹中，例如：Tomcat安装目录为 /usr/local/tomcat，则我的日志文件为：/usr/local/tomcat/logs 目录下面的catalina.out文件。
2. Tomcat查看日志catalina.out文件的方法

1）进入Tomcat的日志目录，执行命令： cd/usr/local/tomcat/logs

2）查看tomcat里面的catalina.out日志

3）查看日志执行命令：

① tail命令：查看文本的结尾内容；

tail catalina.out，查看文本catalina.out；

tail -5 catalina.out，查看文本后5行；

tail -f catalina.out，查看文本实时更新的内容；

② less命令：按照页面显示文本内容；

less catalina.out

pageup 向上翻一页 （向上整翻一页）

pagedown 向下翻一页 （向下整翻一页）

↑ 向上翻一行

↓ 向下翻一行

/关键字        向下搜索该字符

？关键字     向上搜索该字符

q 离开（类似quit退出）

③more命令：less与more相似，按照页面显示文本内容；

more catalina.out

空格键 代表向下翻页 （向下整翻一页）

Enter 下翻一行

/关键字    向下搜索该字符

b 回滚

q 离开

4）查看关键字：

/关键字   向下搜索该字符

？关键字  向上搜索该字符

5）翻页与翻行：

pageup 向上翻一页

pagedown、空格键  向下翻一页

↑ 、n  向上翻一行

↓、Enter 向下翻一行

6）结束查看当前日志：

q（类似quit退出）
3. linux–cat，grep，less快速定位日志查询命令

cat catalina.out | grep “ERROR” -C 1000 | less

-C    前后1000行

less 用法输入“/” 输入关键字查询想要内容，例：“/ERROR”

n键向前继续显示搜索结果

Shift+n键向后复看搜索结果

	

日志是程序员居家旅行必备，哦不对，是定位问题，修复bug，甚至是验证应用是否正常的必备利器。甚至很多时候，我们做一次部署仅仅是为了加一行log。虽然现在有各种各样的问题诊断工具，但是在定位线上问题时，我们很多时候还是希望有打印良好的log。
打印良好的log很重要，但是知道我们需要的log在哪里也很重要。因为各种各样的原因，我们经常会将log打到不同的文件中，这样就导致了出问题找几个日志文件的情况。
这不，默认情况下tomcat就会生成几个日志文件：catalina.out, catalina.{yyyy-MM-dd}.log, localhost.{yyyy-MM-dd}.log。(嗯，这里说的是默认情况下，这些都是可以配置修改的)。
这几个不同的日志文件里的内容也不尽相同，查问题也要看不同的日志文件，如果没找到文件，甚至都无法了解真正的问题是什么。
我们先来看看这几个日志都是怎么产生的，然后来了解一下什么样子的东西会出现在哪个日志文件。
catalina.out
catalina.out其实是tomcat的标准输出(stdout)和标准出错(stderr)，这是在tomcat的启动脚本里指定的，如果没有修改的话stdout和stderr会重定向到这里。所以我们在应用里使用System.out打印的东西都会到这里来。另外，如果我们在应用里使用其他的日志框架，配置了向Console输出的，则也会在这里出现。比如以logback为例，如果配置ch.qos.logback.core.ConsoleAppender则会输出到catalina.out里。
cataliana.{yyyy-MM-dd}.log和localhost.{yyyy-MM-dd}.log
这两个日志都是通过logging.properties配置的(默认情况下，启动脚本里指定了java.util.logging.config.file和java.util.logging.manager两个变量)。一个典型的logging.properties可能如下所示:
handlers= 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler1catalina.org.apache.juli.FileHandler.level = INFO1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs1catalina.org.apache.juli.FileHandler.prefix = catalina.2localhost.org.apache.juli.FileHandler.level = FINE2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs2localhost.org.apache.juli.FileHandler.prefix = localhost.java.util.logging.ConsoleHandler.level = INFOjava.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatterorg.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFOorg.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler
这个文件大致的意思是，root输出到catalina和console。而这里的catalina按照配置对应的是catalina.{yyyy-MM-dd}.log，这里的console最终会输出到catalina.out。这就是我们看到catalina.{yyyy-MM-dd}.log和catalina.out的日志很多都是一样的原因。
配置文件中还有一个localhost，所有logname或parent logname为org.apache.catalina.core.ContainerBase.[Catalina].[localhost]的都会输出到localhost.{yyyy-MM-dd}.log文件。而这个logname又代表着什么呢？在tomcat中有一个server.xml的配置文件，其中有这么一个片段:
<Engine name="Catalina" defaultHost="localhost"><Host name="localhost"  appBase="webapps"unpackWARs="false" autoDeploy="false">Host>
Engine>
我们可以这么简单的理解: 一个Tomcat进程对应着一个Engine，一个Engine下可以有多个Host(Virtual Host)，一个Host里可以有多个Context，比如我们常常将应用部署在ROOT下还是webapps里其他目录，这个就是Context。
这其中Engine对应着tomcat里的StandardEngine类，Host对应着StandardHost类，而Context对应着StandardContext。这几个类都是从ContainerBase派生。这些类里打的一些跟应用代码相关的日志都是使用ContainerBase里的getLogger，而这个这个logger的logger name就是: org.apache.catalina.core.ContainerBase.[current container name].[current container name]...
而我们一个webapp里listener, filter, servlet的初始化就是在StandardContext里进行的，比如ROOT里有一个listener初始化出异常了，打印日志则logger name是org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/]。这其中Catalina和localhost是上面xml片段里的Engine和Host的name，而[/]是ROOT对应的StandardContext的name。所以listener, filter, servlet初始化时的日志是需要看localhost.{yyyy-MM-dd}.log这个日志的。比如现在我们使用Spring，Spring的初始化我们往往是使用Spring提供的一个listener进行的，而如果Spring初始化时因为某个bean初始化失败，导致整个应用没有启动，这个时候的异常日志是输出到localhost中的，而不是cataina.out中。所以有的时候我们应用无法启动了，然后找catalina.out日志，但最后也没有定位根本原因是什么，就是因为我们找的日志不对。但有的时候catalina.out里也有我们想要的日志，那是因为我们的应用或使用的一些组件自己捕获了异常，然后将其打印了，这个时候如果恰好这些日志被我们配置成输出到console，则这些日志也会在catalina.out里出现了。
总结
那么总结起来，catalina.out即标准输出和标准出错，所有输出到这两个位置的都会进入catalina.out，这里包含tomcat运行自己输出的日志以及应用里向console输出的日志。catalina.{yyyy-MM-dd}.log是tomcat自己运行的一些日志，这些日志还会输出到catalina.out，但是应用向console输出的日志不会输出到catalina.{yyyy-MM-dd}.log。localhost.{yyyy-MM-dd}.log主要是应用初始化(listener, filter, servlet)未处理的异常最后被tomcat捕获而输出的日志，而这些未处理异常最终会导致应用无法启动。
最后想想，这里分几个日志文件其实不利于问题查找，为啥不干脆都输出到catalina.out里呢？我想tomcat作为通用容器本身，可能考虑到Engine下有多个Host，每个Host的日志还是要输出到不同的文件。而实际中我们往往是单容器，单Host，甚至是只有一个ROOT的Context。所以对于这种情况，我觉得是可以将所有日志都输出到catalina.out方便查问题，特别是那些还不知道初始化失败应该去看localhost日志的同学。嗯，可以和运维商量一下。
	

转 https://my.oschina.net/u/937713/blog/150563

webAppRootKey是在java web项目的web.xml配置文件中表示项目的唯一标示，在Eclipse调试Web项目时，项目的路径是一个临时路径，不在真正的路径下，可以通过log4j日志的方式打印出属性值，来看看临时项目路径在哪里，可以用System.getProperty("web.sample.root")；如果web.xm 内没有设置webAppRootKey项，是为默认设置，那么webAppRootKey就是缺省的"webapp.root"。 


由于我的两个项目都没有设置这个webAppRootKey值，所以两个webRootKey都是默认缺省值。发生错误


解决办法： 


在启动出现错误的工程web.xml增加如下语句便可

<context-param>

<param-name>webAppRootKey</param-name>

<param-value> app.root </param-value>

</context-param>

自己创建的一个springboot项目需要打成war包部署到tomcat（打成war包的步骤有很多，这里不写了），在我启动tomcat的时候查看日志发现启动报错，日志显示错误原因是spring容器无法加载到加了@Service注解的类，所以这里需要考虑哪里会扫描到这个类并且加入到spring容器，而springboot项目加载@Service注解的配置就是启动类上面的注解@SpringBootApplication(scanBasePackage={"com.你的包名"})，而我的项目启动报错的原因是写成了@SpringBootApplication(scanBasePackage="com.你的包名")，导致启动报错。

 

2019/03/07 第一次编辑