tomcat假死与异常监控
tomcat常见的错误与解决方案小结
tomcat常见的错误与解决⽅案⼩结⼀、tomcat启动时错误问题1:The JAVA_HOME environment variable is not defined This environment variable is needed to run this program;解决:没有在tomcat的配置⽂件.bash_profile中设置环境变量JAVA_HOME,具体设置⽅法为:加⼊如下⼏⾏:JAVA_HOME=/home/tomcat/j2sdk1.4.2_08(具体值要以实际的jdk安装路径为准)export JAVA_HOMECLASSPATH=/home/tomcat/j2sdk1.4.2_08/lib/tools.jar:/home/tomcat/j2sdk1.4.2_08/lib/dt.jarexport CLASSPATH问题2:Error occurred during initialization of VM Could not reserve enough space for object heap解决:在tomcat的bin⽬录下,catalina.sh⽂件的tomcat内存参数配置过⼤,超过机器可⽤内存总数造成,修改到适当的值即可,修改的参数为:JAVA_OPTS="-Xms50m -Xmx60m"问题3:tomcat启动时报某个⽬录没有权限,启动失败,或者不能执⾏某些jsp页解决:tomcat需要tomcat⽤户具有⼀些⽬录和⽂件的相应权限, 所有⽬录应该具有读写执⾏(浏览)的权限,jsp,class⽂件应该最少具有读权限, ⼀些⽂件需要写权限,下⾯是已知的需要读写权限⽂件的列表:$CATALINA_HOME/logs下所有⽂件$CATALINA_HOME/work下所有⽂件$CATALINA_HOME/publish/main/count.txt⽂件$CATALINA_HOME/publish/chatroom/resource下的所有.xml⽂件所有上传图⽚⽬录都需要写权限。
程序监控方法
程序监控方法
程序监控是一个广泛的概念,涉及对计算机程序运行状况的监测和管理。
以下是几种常见的程序监控方法:
1. 日志监控:通过收集和分析程序的运行日志,可以了解程序的运行状态、性能指标、错误信息等。
常见的日志监控工具包括ELK(Elasticsearch、Logstash、Kibana)等。
2. 性能监控:通过监控程序的性能指标,如CPU使用率、内存占用率、磁盘I/O等,可以了解程序的资源消耗情况,及时发现性能瓶颈并进行优化。
常见的性能监控工具包括Prometheus、Grafana等。
3. 异常检测:通过分析程序的运行数据,自动检测异常行为,如程序崩溃、数据泄露等。
常见的异常检测工具包括Sentry、Datadog等。
4. 代码分析:通过静态或动态分析程序代码,发现潜在的错误、安全漏洞等问题。
常见的代码分析工具包括SonarQube、FindBugs等。
5. 依赖监控:通过监控程序所依赖的其他服务或资源,如数据库、外部API 等,确保程序的正常运行。
常见的依赖监控工具包括Dynatrace、New Relic等。
以上是一些常见的程序监控方法,实际应用中可以根据具体情况选择合适的监控工具和方法,以保障程序的稳定性和可靠性。
监控tomcat的几种方法
Tomcat 监控方法方法1:.使用tomcat自带的status页具体方法:步骤1:修改%tomcat安装路径%\conf \tomcat-users文件,配置admin设置权限。
在步骤2:完成后,启动tomcat,输入:http://localhost:8080--(IP,端口号,可远程访问)点击status,输入账号,密码(manager,1234),进入status,时时刷新页面,查看当前tomcat 状态。
或者直接访问:http://localhost:8080/manager/status页面。
备注1:若希望整个服务器的性能数据以一个单行的xml文件形式表示,则进入如下界面:http://localhost:8080/manager/status?XML=true备注2:若服务器中存在几个项目,单独对某个项目进行监控,则需要另行增加代码。
步骤3:上面得到的只是当前情况下的性能数据,要获得一个阶段的性能数据,必须设定采样频率,定时读取,将数据汇总并分析。
步骤4:对得到的数据得出图表。
参考以下示例:通过Linux自带的Bash来实现,绘制图表采用的是Gnuplot。
下列代码生成html的报表只是方法2:使用JDK自带工具,Jconsole具体方法:步骤1:.编辑%tomcat安装路径%\bin\catalina.bat文件。
添加下列内容:set JAVA_OPTS= -Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=10004-Dcom.sun.management.jmxremote.ssl=false-Dcom.sun.management.jmxremote.authenticate=false步骤2:启动tomcat,进入JDK安装路径\jdk1.5.0_22\bin 下双击打开Jconsole文件,显示Jconsole连接页面。
tomcat告警规则 -回复
tomcat告警规则-回复在本文中,我们将详细探讨Tomcat的告警规则。
Tomcat是一个开源的Java Servlet容器,用于实现Java Servlet和JavaServer Pages(JSP)规范。
它是Java开发人员广泛使用的Web服务器,因其稳定性和灵活性而备受赞誉。
为了保持Tomcat服务器的稳定运行,及时发现和解决问题至关重要。
Tomcat提供了告警规则,通过这些规则,我们可以在服务器遇到问题时接收到警报,并迅速采取行动。
接下来,我们将一步一步回答关于Tomcat告警规则的问题。
第一步:了解Tomcat告警规则的基础知识Tomcat的告警规则是指一系列配置项,用于定义在服务器发生特定事件或达到特定条件时要触发的告警行为。
通过这些规则,我们可以设置服务器的告警级别、触发条件和报警方式等。
第二步:配置Tomcat告警规则要配置Tomcat的告警规则,我们需要修改Tomcat的配置文件。
主要的配置文件是`logging.properties`和`logging.xml`。
对于不同的Tomcat 版本,可能会有所不同,但大致的步骤是相同的。
1. 打开`logging.properties`文件,该文件位于Tomcat的`conf`目录下。
2. 找到关于日志的配置项,一般以`handlers`开头。
在这里,我们可以指定要使用的处理程序,以及每个处理程序的级别和格式。
3. 设置告警级别。
可以选择的级别包括`SEVERE`、`WARNING`、`INFO`、`CONFIG`、`FINE`等。
根据需求,我们可以将级别设置为`WARNING`或更高,以便只接收到重要的告警信息。
4. 配置处理程序。
我们可以选择使用内置的处理程序,如`java.util.logging.ConsoleHandler`或`org.apache.juli.FileHandler`,也可以自定义处理程序。
设置处理程序的目标和格式,以便更好地满足我们的需求。
tomcat安全规范(tomcat安全加固和规范)
tomcat安全规范(tomcat安全加固和规范)tomcat是⼀个开源Web服务器,基于Tomcat的Web运⾏效率⾼,可以在⼀般的硬件平台上流畅运⾏,因此,颇受Web站长的青睐。
不过,在默认配置下其存在⼀定的安全隐患,可被恶意攻击。
以下是⼀些安全加固的⽅法:版本安全升级到最新稳定版,出于稳定性考虑,不建议进⾏跨版本升级。
服务降权不要使⽤root⽤户启动tomcat,使⽤⽤普通⽤户启动Tomcat,集群内⽤户名统⼀UID端⼝保护1 更改tomcat管理端⼝8005 ,此端⼝有权限关闭tomcat服务,但要求端⼝配置在8000~8999之间,并更改shutdown执⾏的命令2 若 Tomcat 都是放在内⽹的,则针对 Tomcat 服务的监听地址都是内⽹地址3 修改默认的ajp 8009端⼝为不易冲突(⼤于1024),但要求端⼝配置在8000~8999之间禁⽤管理端1 删除默认$CATALINA_HOME/conf/tomcat-users.xml⽂件,重启tomcat将会⾃动⽣成新的⽂件2 删除$CATALINA_HOME/webapps下载默认的所有⽬录和⽂件3 将tomcat应⽤根⽬录配置为tomcat安装⽬录以外的⽬录隐藏Tomcat的版本信息针对该信息的显⽰是由⼀个jar包控制的,该jar包存放在$CATALINA_HOME/lib⽬录下,名称为 catalina.jar,通过 jar xf 命令解压这个 jar 包会得到两个⽬录 META-INF 和 org ,修改 org/apache/catalina/util/ServerInfo.properties ⽂件中的 serverinfo 字段来实现来更改我们tomcat的版本信息关闭war⾃动部署默认 Tomcat 是开启了对war包的热部署的。
为了防⽌被植⼊⽊马等恶意程序,因此我们要关闭⾃动部署。
修改实例:<Host name="localhost" appBase=""unpackWARs="false" autoDeploy="false">⾃定义错误页⾯编辑conf/web.xml,在</web-app>标签上添加以下内容:<error-page><error-code>404</error-code><location>/404.html</location></error-page><error-page><error-code>500</error-code><location>/500.html</location></error-page>屏蔽⽬录⽂件⾃动列出编辑conf/web.xml⽂件<servlet><servlet-name>default</servlet-name><servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class><init-param><param-name>debug</param-name><param-value>0</param-value></init-param><init-param><param-name>listings</param-name><param-value>false</param-value></init-param><load-on-startup>1</load-on-startup></servlet><param-value>false</param-value>这⾥false为不列出,true为充许列出多虚拟主机强烈建议不要使⽤ Tomcat 的虚拟主机,推荐每个站点使⽤⼀个实例。
基于windows服务监控tomcat服务,防止tomcat死掉
安装tomcat监控服务安装tomcat监控服务的目的是为了随时监测tomcat的运行状况,若出现内存溢出或其它不能提供正常服务的情况,系统自动能重启tomcat服务,由此减少开发服务人员的工作量,也能提高服务质量。
安装设置分为以下四个步骤:一、创建监控页面在项目系统里添加一个提供监控系统访问的页面monitor.jsp,只需输出一句代码,代码如下:<%String s=”ok”;out.println(s.length());%>二、修改tomcat配置若是系统自动安装的服务,可直接跳过这一步。
但是需确定服务名称,以便在以后的步骤使用,如下图:服务名称若是手动为tomcat设置服务,请按以下步骤进行:1、进入tomcat目录下的bin目录,用记事本打开service.bat文件,找到setSERVICE_NAME=TOMCA TXX这一句,把后面的值改成自己对tomcat设置的服务名,把PR_DISPLAYNAME的值设置为显示的服务名称,这个是在系统管理的服务里面中列表里显示的名字。
如设置信访系统,则设置为这样:Set SERVICE_NAME=xfglSet PR_DISPLAYNAME=tomcat xfgl保存。
2、在运行里输入“CMD ”,进入命令控制台,使用cd 命令转到tomcat 目录下的bin 目录,运行service.bat install 命令,把tomcat 设置为系统启动服务。
3、进入控制面板->管理工具->服务,在服务列表中找到“tomcat xfgl ”一项,双击弹出窗口,把启动类型改为“自动”,确定保存。
三、 设置监控脚本文件新建一个vbs 脚本文件,用于访问tomcat 服务下的一个jsp 页面monitor.jsp 。
脚本代码如下:该脚本的目的是定时访问monitor.jsp 页面,判断页面返回的状态码,若状态不为200,则表示该页面未正常返回,可能是tomcat 服务出了问题,随后自动重启tomcat服务,并记录日志,把日志记录在C盘,日志文件以tomcat服务名和当前日期命名。
tomcat假死与异常监控
tomcat假死与异常监控tomcat假死与异常监控在开发的tomcat服务应用中,经常会遇到tomcat假死情况,除了每次出现假死时找出原因外,有时候由于业务的重要性,需要及时发现服务异常并及时解决。
所以本人就想通过Linux定时任务定时监控的方式来预防这个问题,一旦发现及时通知告警并重启服务,然后才通过日志查明原因从根本上解决。
1)tomcat假死状态处于假死状态时,后台日志不在生成,服务链接没有响应,但tomcat的进程是存在的,所以若要监控是否处于假死状态可以从日志和服务链接方面入手,但由于检测日志比较麻烦,本人选择的是通过选择某个服务链接获取其访问状态码http_code,若状态码不正常则确认为tomcat服务异常。
例如:url=“http://localhost/….”code=$(curl -o /dev/null --retry 3 -s -w %{http_code} $url) echo “${code}”上面脚本中url变量为选择的适合的监控链接,code就是该链接正常时应该返回的返回码,正常是为200,有时候由于浏览器缓存可能返回302等也是正常的,所以建议最好选择那种后台的链接能够返回200的,这样检测起来比较方便。
2)tomcat异常监控在tomcat运行日志中,经常会出现一些异常,对于有些异常我们可以不用管,但例如数据库链接异常、内存溢出异常等,这些异常会直接导致服务不能正常使用,所以需要对这些类型的异常进行监控,同样的本人也是通过Linux脚本实时检查tomcat运行日志的方式来检测服务状态。
脚本如下:errormessage1="/doc/261950289.html,ng.OutOfMemoryError"ifcat ${tomcatpath}/logs/catalina.out |grep "$errormessage1">/dev/null thenrestartFlag="yes"其实就是通过cat |grep 的方式来查找异常特征字符串是否在运行日志文件中存在,存在则代表出现了该类异常,当然这是需要程序对该类异常做了处理的(捕捉到并输出到控制台)。
前端异常监控解决方案
前端异常监控解决方案
《前端异常监控解决方案》
在前端开发中,异常是无法避免的。
无论是网络问题、服务器故障还是客户端代码错误,都可能导致用户的体验变差甚至应用不可用。
因此,前端异常监控解决方案成为了每个开发团队都必须重视的问题。
前端异常监控解决方案主要包括以下几个方面:
1. 实时监控:通过实时监控工具,追踪并记录应用的异常情况,以便开发人员能够及时发现和定位问题。
2. 报警机制:当异常出现时,需要及时地通知到相关人员。
因此,报警机制是异常监控解决方案中至关重要的环节。
3. 异常分类和分析:不同类型的异常需要采取不同的处理方式,因此需要对异常进行分类和分析,以便更好地解决问题。
4. 异常处理:当异常出现时,需要采取相应的处理方式,例如降级处理、自动恢复、重试机制等,以保证应用的稳定性和用户体验。
5. 性能优化:有些异常可能是由于性能问题导致的,因此需要对应用的性能进行监控和优化,以减少异常的发生。
当前,市面上已经有很多前端异常监控解决方案可以选择,例
如Sentry、Bugsnag、Raygun等。
这些工具提供了实时监控、报警机制、异常分类和分析、异常处理等功能,可以帮助开发团队更好地管理和解决前端异常问题。
总的来说,前端异常监控解决方案对于保障应用的稳定性和用户体验至关重要。
通过建立完善的前端异常监控体系,可以帮助开发团队及时发现和解决异常问题,提升应用的质量和用户满意度。
软件开发中的异常处理和日志监控
软件开发中的异常处理和日志监控在软件开发中,异常处理和日志监控是两个非常重要的方面。
异常是指程序运行过程中出现的不正常情况,例如代码出错、服务器崩溃等。
而日志则是记录程序运行过程中的各种事件,包括错误信息、用户操作、性能指标等等。
异常处理和日志监控可以帮助程序开发者及时发现和解决问题,提高程序的可靠性和稳定性。
一、异常处理在软件开发中,异常处理指针对程序运行过程中可能出现的各种异常情况,编写相应的代码进行处理。
一般来说,程序在遇到异常情况时会停止执行,抛出异常信息给开发者。
开发者则需要根据异常信息找到问题所在,并进行相应的处理。
异常处理的主要目的是保证程序的可靠性和健壮性。
如果程序没有进行异常处理,一旦出现异常情况,可能会导致程序崩溃或者数据丢失等严重后果。
一般来说,异常处理可以通过以下几种方式进行:1. try-catch语句:try-catch语句是一种常见的异常处理方式。
其基本语法结构如下:try{//执行可能出现异常的代码}catch(Exception e){//处理异常}try-catch语句的作用是在执行可能出现异常的代码块时,如果出现了异常就会跳转到catch语句块中进行处理。
需要注意的是,catch语句可以针对不同类型的异常进行不同的处理,可以根据异常类型进行分别处理。
2. throws语句:throws语句也是一种处理异常的方式。
其语法结构如下:public void method() throws Exception{//执行可能出现异常的代码}在throws语句中,需要在方法名后面添加throws关键字,并且在方法参数括号之后声明需要抛出的异常类型。
当方法中执行的代码出现异常时,就会抛出异常给调用该方法的代码进行处理。
3. finally语句:finally语句是在try-catch语句块中可选的一个语句块。
其基本语法结构如下:try{//执行可能出现异常的代码}catch(Exception e){//处理异常}finally{//无论是否出现异常都会执行的代码}finally语句块中的代码无论是否出现异常,都会被执行。
tomcat告警规则
tomcat告警规则
Tomcat告警规则(Alarm Rules)用于监控Tomcat服务器的运行状态,并在出现异常或错误时发出告警。
以下是一些常见的Tomcat告警规则:
1.CPU使用率告警:监控Tomcat服务器的CPU使用率,当CPU
使用率超过一定阈值时发出告警。
2.内存使用率告警:监控Tomcat服务器的内存使用情况,当内
存使用率超过一定阈值时发出告警。
3.线程数告警:监控Tomcat服务器的线程数,当线程数超过一
定阈值时发出告警。
4.连接数告警:监控Tomcat服务器的连接数,当连接数超过一
定阈值时发出告警。
5.错误日志数量告警:监控Tomcat服务器日志中错误日志的数
量,当错误日志数量超过一定阈值时发出告警。
以上是一些常见的Tomcat告警规则,根据实际需求,还可以定制其他的告警规则。
在配置告警规则时,需要设置阈值和告警方式(如邮件、短信等),以便在异常或错误发生时及时收到告警信息。
tomcat exception invoking method
tomcat exception invoking method题目:Tomcat异常调用方法的解决方法引言:Tomcat是一个广泛使用的Java应用服务器,但在使用过程中,我们可能会遇到异常调用方法的问题。
这种情况常常发生,如果不及时解决,会影响网站的正常运行。
本文将一步一步地回答关于Tomcat异常调用方法的解决方法,帮助读者快速排除问题并恢复正常运作。
一、了解异常调用方法的背景Tomcat作为一个Java应用服务器,主要用于运行和管理Java Servlet 和JavaServer Pages。
而异常调用方法可以发生在多个环节,包括应用程序、代码配置或者Tomcat本身的配置等。
当调用方法异常时,Tomcat 无法正常处理请求,这会导致网站响应缓慢甚至崩溃。
二、排除常见问题1. 检查Tomcat日志Tomcat日志记录了服务器的活动和错误情况。
首先,查看Tomcat日志,尤其是最近的错误日志,以了解潜在的问题。
通常,错误消息包含了异常调用方法的相关信息,如出现的位置、原因和堆栈跟踪等。
2. 检查应用程序代码异常调用方法常常源于应用程序的代码错误。
对于Java开发人员而言,通过仔细检查代码,包括方法调用过程、参数传递和异常处理等,可以迅速确定问题所在。
常见的问题包括空指针异常、方法不存在等。
修复这些代码问题是解决异常调用方法的关键。
3. 检查依赖项和配置文件某些异常调用方法是由于缺少依赖项或配置文件引起的。
首先,确保所有依赖项都已正确安装和配置。
然后,检查系统环境变量和配置文件的设置是否正确。
特别要注意相关路径、文件访问权限以及对外部资源的引用等。
三、解决常见问题1. 更新Tomcat版本如果异常调用方法是由于Tomcat本身的问题导致的,考虑将Tomcat版本更新到最新稳定版。
新版本通常修复了旧版本的已知问题,并提供更好的稳定性和性能。
2. 修复编码错误当代码存在编码错误时,Tomcat在执行方法调用时可能会出现异常。
prometheus tomcat 指标
prometheus tomcat 指标以下是Tomcat指标,Prometheus可以收集它们来监控Tomcat应用的性能和健康状况:
请求处理时间:这个指标可以显示处理每个请求所花费的时间。
如果这个指标异常高,可能意味着服务器正在遭受性能问题。
错误率:这个指标表示请求失败的百分比。
如果错误率持续升高,可能表明应用程序有错误或者服务器资源不足。
活跃线程数:这个指标显示当前活跃的线程数。
如果这个数字持续超过服务器的处理能力,可能会导致性能问题。
连接数:这个指标显示当前打开的连接数。
如果连接数持续过高,可能表明服务器正在遭受资源瓶颈。
Tomcat会话数:这个指标显示当前活动的Tomcat 会话数。
如果会话数持续过高,可能表明服务器正在遭受资源瓶颈。
Tomcat连接器状态:这个指标显示Tomcat连接器的状态,例如已建立连接数、已关闭连接数等。
Tomcat JSP编译时间:这个指标显示Tomcat JSP 编译所花费的时间。
如果编译时间过长,可能表明应用程序存在性能问题。
Tomcat类加载时间:这个指标显示Tomcat类加载所花费的时间。
如果加载时间过长,可能表明应用程序存在性能问题。
以上是常见的Tomcat指标,Prometheus可以收集这些指标并进行可视化展示,帮助管理员监控和诊断Tomcat应用的性能和健康状况。
tomcat数据备份、日常维护和常见问题处理方法
tomcat数据备份、日常维护和常见问题处理方法### Tomcat数据备份、日常维护和常见问题处理方法#### 导语Tomcat作为一款流行的Java Servlet容器,被广泛应用于Web应用的开发与部署中。
对于保障Tomcat服务的高可用性和数据安全性,定期进行数据备份、日常维护以及掌握常见问题的处理方法是至关重要的。
本文将详细阐述这三个方面的实践指南。
#### 一、Tomcat数据备份数据备份是防止数据丢失的关键措施,以下为Tomcat数据备份的常规步骤:1.**备份目录选择**:- **数据目录**:通常需要备份Tomcat的数据目录,如`/path/to/tomcat/data`,该目录下可能存放了应用的数据库文件或用户上传的文件。
- **配置文件**:备份Tomcat的配置文件,包括`server.xml`、`context.xml`、`web.xml`等,这些文件通常位于Tomcat安装目录下的`conf`文件夹中。
- **应用文件**:备份部署在Tomcat上的应用文件,通常是WAR包或者应用解压后的文件夹。
2.**备份方法**:- 使用命令行工具如`cp`或`rsync`进行文件复制。
- 利用定时任务(如`cron`)实现定期自动备份。
- 对于数据库,使用相应的数据库备份工具(如mysqldump、pg_dump)进行备份。
3.**备份频率**:- 根据数据的重要性和更新频率确定备份频率,对于频繁变动的数据,应实现实时或定时近实时的备份。
#### 二、Tomcat日常维护日常维护可以确保Tomcat服务器健康稳定地运行。
1.**更新与升级**:- 定期检查Tomcat版本,更新到最新版以获得安全修复和性能改进。
- 在升级前确保备份数据,并测试新版本兼容性。
2.**日志检查**:- 定期查看Tomcat的日志文件,如`catalina.out`,监控错误和异常。
- 分析日志中反复出现的错误,找出问题根源并进行修复。
TOMCAT假死报告
问题描述在tomcat上,压力测试(并行50,串行100,即5000次)的JAVA程序B44。
压测完毕后(压测试程序已执行完,tomcat也没有任何程序再跑)tomcat就假死了(访问tomcat没反应,无法显示该页)。
然后,再过两分钟,tomcat又能正常访问了。
一切自动恢复正常。
分析问题先后进行了多次测试,发现以下问题:●与写日志的线程无关。
因为,改成了线程池也结果相同。
●与写日志无关。
因为,不写日志也结果相同。
●与程序无关,我写了个最简单的JSP,压测也是这样。
●与程序的运行时间有关,如果这个程序要运行好几百毫秒(如:M04),反而不会假死。
●如果,用APACHE分发到多个TOMCAT,则会产生APACHE假死,而TOMCAT不会假死。
●如果有硬件负载均衡器分发到多个TOMCAT。
估计也会产生与APACHE分发,相同的结果。
●与运行的web server无关。
因为,在weblogic上运行也结果相同。
●与内存无关,因为压测的过程中,内存变化不大。
●与机器性能无关,先后在多次性能不同的机器上进行了测试,效果都相同。
●与web server分配的堆栈大小无关,改大后反而报内存不足。
●最后,发现非常关键的一点假死时,除了用IE访问地址报“无法打开该网页”外,压测的程序都抛出同一例外信息“.BindException: Address already in use:connect”。
●最终,得出大概原因是短时间内new socket操作很多,而socket.close()操作并不能立即释放绑定的端口,而是把端口设置为TIME_WAIT状态,过段时间(默认240s)才释放,(用netstat -na看到有好几千行被调用的端口为TIME_WAIT),最后系统资源耗尽(windows上是耗尽了pool of ephemeral ports ,这段区间在1024-5000之间; )解决办法1)调高web服务器的最大连接线程数,即打开tomcat的server.xml文件,设置Connector的以下参数:minProcessors="70" maxProcessors="2000"acceptCount="2000"2)修改运行web服务器的机器的操作系统网络配置,即在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters中增加以下两个DWORD参数:MaxUserPort=fffe TcpTimedWaitDelay=1e 最后,重新启动计算机。
Promethues如何监控Tomcat
Promethues如何监控TomcatPromethues 监控tomcat 主要用的模块l Promethus 负载抓取/存储指标信息、并提供查询功能l grafana 数据可视化l JMX exporter 提供JMX中JVM相关的metrics1、利用JMX exporter,在Java进程内启动一个小型的Http server2、配置Prometheus抓取那个Http server提供的metrics。
3、配置Grafana连接Prometheus,配置Dashboard。
一、下载一个tomcat,下载jmx_exporterl 1、获取jmx_exporter有2种方法,自己编译获取jar包,获取现成的jar包wget /maven2/io/prometheus/jmx/jmx_prometheus_javaag ent/0.12.0/jmx_prometheus_javaagent-0.12.0.jar或者编译git clone https:///prometheus/jmx_exportercd jmx_exportermvn packagel 2、安装tomcatwget/apache/tomcat/tomcat-8/v8.5.51/bin/apache-tomcat-8.5.51.tar.gztar zxvf apache-tomcat-8.5.51.tar.gzmv apache-tomcat-8.5.51 /usr/localt/tomcat_testl 3、配置文件下载wgethttps:///prometheus/jmxexporter/blob/master/exam pleconfigs/tomcat.ymltomcat.yml的内容如下---lowercaseOutputLabelNames: truelowercaseOutputName: truerules:- pattern: 'Catalina<type=GlobalRequestProcessor, name=\"(\w+-\w+)-(\d+)\"><>(\w+):'name: tomcat_$3_totallabels:port: "$2"protocol: "$1"help: Tomcat global $3type: COUNTER- pattern: 'Catalina<j2eeType=Servlet, WebModule=//([-a-zA-Z0-9+&@#/%?=~_|!:.,;]*[-a-zA-Z0-9+&@#/%=~_|]),name=([-a-zA-Z0-9+/$%~_-|!.]*), J2EEApplication=none, J2EEServer=none><>(requestCount|maxTime|processingTime|e rrorCount):'name: tomcat_servlet_$3_totallabels:module: "$1"servlet: "$2"help: Tomcat servlet $3 totaltype: COUNTER- pattern: 'Catalina<type=ThreadPool, name="(\w+-\w+)-(\d+)"><>(currentThreadCount|currentThreadsBusy|keepAliveC ount|pollerThreadCount|connectionCount):'name: tomcat_threadpool_$3labels:port: "$2"protocol: "$1"help: Tomcat threadpool $3type: GAUGE- pattern: 'Catalina<type=Manager, host=([-a-zA-Z0-9+&@#/%?=~_|!:.,;]*[-a-zA-Z0-9+&@#/%=~_|]), context=([-a-zA-Z0-9+/$%~_-|!.]*)><>(processingTime|sessionCounter|rejectedSessions|expir edSessions):'name: tomcat_session_$3_totallabels:context: "$2"host: "$1"help: Tomcat session $3 totaltype: COUNTERl 4、收集数据4-1、Tomcat收集数据mkdir /usr/local/tomcat_test/jmx/cp jmx_prometheus_javaagent-0.12.0.jar /usr/local/tomcat_test/jmx/cp tomcat.yml /usr/local/tomcat_test/jmx/修改配置文件vim /usr/local/tomcat_test/bin/catalina.shJAVA_OPTS="-javaagent:/usr/local/tomcat_test/jmx/jmx_prometheus_javaagen t-0.12.0.jar=39081:/usr/local/tomcat_test/jmx/tomcat.yml"4-2、JAR包运行(案例,关键文件jmxprometheusjavaagent-0.3.0.jar和tomcat.yml)java-javaagent:./jmx_prometheus_javaagent-0.3.0.jar=9151:tomcat.yaml -jar yourJar.jarl 5、测试是否收集到数据curl -s http://localhost:39081/ | more[root@Prometheus promethus]# curl -s http://localhost:39081/ | more# HELP jmx_exporter_build_info A metric with a constant '1' value labeled with the version of the JMX exporter.# TYPE jmx_exporter_build_info gaugejmx_exporter_build_info{version="0.12.0",name="jmx_prom etheus_javaagent",} 1.0# HELP jmx_config_reload_success_total Number of times configuration have successfully been reloaded.# TYPE jmx_config_reload_success_total counterjmx_config_reload_success_total 0.0# HELP jmx_config_reload_failure_total Number of times configuration have failed to be reloaded.# TYPE jmx_config_reload_failure_total counterjmx_config_reload_failure_total 0.0# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.# TYPE process_cpu_seconds_total counterprocess_cpu_seconds_total 3.99# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.# TYPE process_start_time_seconds gaugeprocess_start_time_seconds 1.582290765496E9# HELP process_open_fds Number of open file descriptors.# TYPE process_open_fds gaugeprocess_open_fds 74.0二、配置promethus 采集数据l 1、文件引用(本文采用) /usr/local/prometheus/prometheus.yml- job_name: 'tomcat'file_sd_configs:- files: ['/usr/local/prometheus/conf/tomcat.yml']refresh_interval: 180s/usr/local/prometheus/conf/tomcat.yml/tomcat.yml- targets:- 114.67.116.119:39081labels:idc: test_idcservice: tomcat_testl 2、直接配置scrape_configs:- job_name: 'java'static_configs:- targets: ['114.67.116.119:39081']l 3、重载配置文件kill-hup `ps -ef |grep prometheus|grep -v grep|awk '{print $2}'`或者kill -9 PID/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.ymll 4、查看promethus界面,tomcat的监控是否发现三、grafana 数据可视化导入模板 8563名称对应 promethus.yml的job名称展示tomcat监控大屏。
zabbix使用jmx监控tomcat
zabbix使⽤jmx监控tomcat监控原理:当Zabbix-Server需要知道java应⽤程序的某项性能的时候,会启动⾃⾝的⼀个Zabbix-JavaPollers进程去连接Zabbix-JavaGateway请求数据,⽽ZabbixJavagateway收到请求后使⽤"JMXmanagementAPI"去查询特定的应⽤程序,⽽前提是应⽤程序这端在开启时需要"-Dcom.sun.management.jmxremote"参数来开启JMX远程查询就⾏。
Java程序会启动⾃⾝的⼀个简单的⼩程序端⼝12345向Zabbix-JavaGateway提供请求数据。
从上⾯的原理图中可以看出,配置Zabbix监控Java应⽤程序的关键点在于:配置Zabbix-JavaGateway、让Zabbix-Server能够连接Zabbix-JavaGateway、Tomcat开启JVM 远程监控功能等1、zabbix server安装Zabbix-Java-gatewayJava-gateway不安装在zabbix-server上也可以,仅仅是作为⼀个采集器![root@zabbix ~]# yum install -y zabbix-java-gateway[root@zabbix ~]# java -versionopenjdk version "1.8.0_171"OpenJDK Runtime Environment (build 1.8.0_171-b10)OpenJDK 64-Bit Server VM (build 25.171-b10, mixed mode)2、配置zabbix sever端[root@zabbix ~]# vim /etc/zabbix/zabbix_java_gateway.confLISTEN_IP="0.0.0.0" #监听地址LISTEN_PORT=10052 #监听端⼝PID_FILE="/var/run/zabbix/zabbix_java.pid"#PID_FILE⽂件START_POLLERS=5 #开启的⼯作线程数[root@zabbix ~]# systemctl start zabbix-java-gateway.service[root@zabbix ~]# systemctl enable zabbix-java-gateway.service[root@zabbix ~]# vim /etc/zabbix/zabbix_server.confJavaGateway=127.0.0.1 #java_gateway的地址JavaGatewayPort=10052 #java_gateway的端⼝StartJavaPollers=5 #采集进程数,与java_gateway配置相同[root@zabbix ~]# systemctl restart zabbix-server.service #重启zabbix-server注意:如果是编译安装zabbix server需要加上--enable-java以⽀持jmx监控,如果之前的zabbix server没加,那么请重新编译安装,参考编译参数./configure --prefix=/user/local/zabbix --enable-server --enable-agent --enable-java --enable-ipv6 --with-mysql=/application/mysql-5.5.49/bin/mysql_config --with-net-snmp --with-libcurl --with-libxml2 --with-openipmi --with-unixodbc --with-openssl3、客户端配置配置tomcat开启jmx remote,配置zabbix-agent客户端Tomcat JMX,即tomcat的远程调⽤脚本[root@tomcat ~]# vim /application/tomcat/bin/catalina.sh#!/bin/shCATALINA_OPTS="-Dcom.sun.management.jmxremote #开启远程监控-Dcom.sun.management.jmxremote.authenticate=false #关闭权限认证-Dcom.sun.management.jmxremote.ssl=false #远程ssl验证为false-Djava.rmi.server.hostname=192.168.1.7 #部署了tomcat的主机地址-Dcom.sun.management.jmxremote.port=12345" #远程监控端⼝[root@tomcat ~]# vim /etc/hosts #设置本地host解析,不然会报错,12345端⼝⽆法查看,报错信息可在catalina⽇志中查看10.0.0.7 tomcat[root@tomcat ~]# /application/tomcat/bin/shutdown.sh #重启tomcat[root@tomcat ~]# /application/tomcat/bin/startup.sh[root@tomcat ~]# netstat -lntupActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 2647/mysqldtcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1774/sshdtcp6 0 0 :::8009 :::* LISTEN 5946/javatcp6 0 0 :::55404 :::* LISTEN 5946/javatcp6 0 0 :::8080 :::* LISTEN 5946/javatcp6 0 0 :::22 :::* LISTEN 1774/sshdtcp6 0 0 :::12345 :::* LISTEN 5946/javatcp6 0 0 :::53819 :::* LISTEN 5946/javatcp6 0 0 127.0.0.1:8005 :::* LISTEN 5946/javaudp6 0 0 :::5353 :::* 5946/javaudp6 0 0 :::33848 :::* 5946/java4、测试4.1 Jconsole测试JConsole是jdk安装之后在windows下的⼀款监控测试⼯具,⾸先下载windows下的jdk应⽤程序并安装,安装好后在安装路径下即C:\Program Files\Java\jdk1.8.0_171\bin找到jconsole程序并打开新建连接连接成功后界⾯如下查看某个监控项的具体信息,监控对象的名字ObjectName与zabbix中的对应,可以利⽤此在zabbix中⾃定义监控项,创建模板如4.2 命令⾏测试在有java环境的机器上下载cmdline-jmxclient-0.10.3.jar包进⾏测试[root@zabbix tools]# java -jar cmdline-jmxclient-0.10.3.jar - 192.168.1.7:12345 ng:type=Memory NonHeapMemoryUsage 06/26/2018 14:44:55 +0800 org.archive.jmx.Client NonHeapMemoryUsage:committed: 117006336init: 2555904max: -1used: 113687744成功取到值!5、在zabbix的web界⾯添加主机添加主机,选择jmx接⼝,输⼊tomcat主机的ip地址为主机链接模板,模板选择需要适合当前的tomcat版本,其中的Template JMX Tomcat模板较⽼,不适合监控tomcat8.0以上版本,导⼊新版模板稍等⽚刻等待主机的jmx连接成功变为绿⾊5、查看最新数据⾄此,zabbix监控tomcat完成!博主原创⽂章,转载请务必注明出处。
tomcat日志类型
tomcat日志类型
Tomcat的日志类型主要包括以下几种:
1.应用日志:主要记录应用事件的,针对应用级别的排错比较有用,比如应用性能比较慢。
2.服务器日志:和console日志是相同的,不同之处在于,服务器日志是保存在文件中的,可以随时查看。
3.控制台日志:记录了tomcat的启动和加载器的顺序的详细信息,该日志文件叫做catalina.out。
在排查服务器启动、应用的部署错时比较有用。
4.访问日志:记录所有进入Tomcat服务器的HTTP请求。
这些日志包含有关请求的详细信息,如客户端IP地址、请求的时间戳、请求方法、请求的URL、HTTP状态码等。
5.错误日志:记录在处理请求过程中发生的错误和异常。
这些日志包含有关错误的详细信息,如错误的时间戳、错误类型、异常堆栈跟踪等。
6.Catalina日志:记录Tomcat服务器的启动、关闭以及关键组件(如Servlet、过滤器等)的初始化和销毁过程。
这些日志提供有关服务器运行状态的信息。
7.安全日志:记录与安全相关的事件和活动,如用户认证、授权失败等。
这些日志帮助管理员监视和审计服务器的安全性。
8.应用程序日志:这些日志由部署在Tomcat上的应用程序生成,用于记录应用程序自身的日志信息。
应用程序日志可以包括调试信息、业务日志、应用程序错误等。
这些日志可以帮助管理员更好地了解Tomcat服务器的运行状态,及时发现并解决问题。
Tomcat假死原因分析
Tomcat假死原因分析最近监控服务发现有台tomcat 的应⽤出现了⽆法访问的情况,由于已做了集群,基本没有影响线上服务的正常使⽤。
下⾯来简单描述该台tomcat当时具体的表现:客户端请求没有响应,查看服务器端tomcat 的java 进程存活,查看tomcat 的catalina.log ,没有发现异常,也没有error ⽇志.查看localhost_access.log 也没有最新的访问⽇志,该台tomcat 已不能提供服务。
根据前⾯的假死表象,最先想到的是⽹络是否出现了问题,于是开始从请求的数据流程开始分析。
由于业务的架构采⽤的是nginx + tomcat 的集群配置,⼀个请求上来的流向可以⽤下图来简单的描述。
从上图可以看出,如果是⽹络的原因,可以从两个点进⾏分析。
1.从前端到nginx的⽹络情况分析nginx上的access.log ,在其中⼀台上可以查出当时该条请求的访问⽇志,也就是说可以排除这段⽹络的问题。
2.从nginx 到tomcat 的⽹络情况分析tomcat 的访问⽇志localhost_acess.log 上⽆法查出该条请求的访问⽇志。
可以怀疑是否⽹络有问题。
就该情况,从该台nginx ping 了⼀下tomcat server ,均为正常,没有发现问题。
既然⽹络貌似没有问题,开始怀疑是tomcat本⾝的问题,在tomcat本机直接curl 调⽤该条请求,发现仍然没有响应。
到此基本可以断定⽹络没有问题,tomcat 本⾝出现了假死的情况。
基于tomcat 假死的情况,开始分析有可能的原因。
造成tomcat假死有可能的情况⼤概有以下⼏种:1.tomcat jvm 内存溢出分析当时的gc.logText代码1. 7581861.927: [GC 7581861.927: [ParNew2. Desired survivor size 76677120 bytes, new threshold 15 (max 15)3. - age 1: 5239168 bytes, 5239168 total4. : 749056K->10477K(898816K), 0.0088550 secs] 1418818K->680239K(8238848K), 0.0090350 secs]没有发现有内存溢出的情况,直接grep catalina.sh也没有结果,证明没有发⽣内存溢出的情况,这种假死可能可以排除。
TOMCAT挂死现象之JDBC资源释放问题
TOMCA T挂死现象之JDBC资源释放问题系统测试用户多了以后,TOMCA T挂死,请求无法响应!观察其日志文件catalina.out包含以下内容:transaction completed on session with on_close connection release mode; be sure to close the session to release JDBC resources参考网络资源:/blog/88289Hibernate配置时易忘掉的一项使用Hibernate時,大家一般都記住了配置基本的那些選項,比如方言,緩存等,但是有一項配置卻很容易忘掉,這就是連接釋放模式:hibernate.connection.release_mode,可有三個選擇,after_statement/after_transaction/on_close,javadoc中可以看出它們的用處,這裡不再講,注意的一點是,如果不配置的話默認是on_close,那麼如果沒有顯示的去調用session.close或其它關閉連接的方法的話,這個連接是不會被關閉的!在用到連接池的時候,這就更體現出問題了:池中的連接會一直存在著而不會被關閉和回收!從log4j打印出來的日志也可以看出來,如果是on_close模式,則:transaction completed on session with on_close connection release mode; be sure to close the session to release JDBC resources!具體的一些細節可以看看hibernate的源代碼,涉及到的兩個類為:org.hibernate.ConnectionReleaseModeorg.hibernate.jdbc.ConnectionManager最後,貼一下配置的代碼:<propkey="hibernate.connection.release_mode">after_transaction</prop>修改如下配置文件,重新发布,重启TOMCA T之后,多人同时访问,PORTAL运行正常。
Windows下监控端口号
Windows下监控端⼝号例如tomcat 端⼝号如果tomcat 死掉并重启@echo offrem 读取tomcat死之前的配置⽂件 depotupdate赋予默认值!null 升级失败造成的tomcat 死亡(java -jar 升级程序)如果没有此值或者此⽂件不知为何tomcat 会死 5分钟检测⼀次set depotupdate=nullset tomcatPort=80set URL="http://localhost:%tomcatPort%/depot/TestServlet"set httpcode=0rem 判断 tomcat 死活for /l %%i in (1,1,10) do (echo %%irem 借助⼯具获得项⽬的状态头(curl⼯具的安装会在下⾯提及)for /f "delims=" %%r in ('curl -sL -w "%%{http_code}" %URL% -o /dev/null') do (rem 将变量r的值赋值给httpcodeset httpcode=%%r))rem 判断 tomcat 是如何死的如果是升级造成死亡执⾏升级程序否则直接启动for /f "tokens=1,2 delims==" %%i in (%ETC_HOME%\ETC_Managent\apache-tomcat\conf\update.properties) do (if "%%i"=="depotupdate" set depotupdate=%%jif "%%i"=="tomcatPort" set tomcatPort=%%j)echo 是否通断 %httpcode%echo 端⼝号 %tomcatPort%rem 判断 httpcode 是否 ==200 200 说明通tomcat 还活着,不是200 说明不通不同说明 tomcat 死了启动if not %httpcode%==200 (netstat -ano|findstr 0.0.0.0:%host%>pid.txtrem 查找进程记录,提取第5列的值,并终⽌进程,for 默认根据空格,制表符,;等进⾏字符串分割for /f "tokens=5" %%i in (%cd%\pid.txt) do (echo 虽然tomcat 死了但是进程依旧存在杀死echo try to kill pid %%itaskkill /pid %%i /Frem 删除pid.txt⽂件del /a/f/q "%~dp0\pid.txt)echo depotupdate:%depotupdate%rem 判断 update 状态 depotupdate 状态if "null" == "%depotupdate%" (echo depotupdate:%depotupdate% 不是升级造成的重启Tomcat::setx /M CATALINA_HOME "%ETC_HOME%\ETC_Managent\apache-tomcat"%ETC_HOME%\ETC_Managent\apache-tomcat\bin\startup.bat)if not "null" == "%depotupdate%" (echo depotupdate:%depotupdate% 是升级造成tomcat 挂掉执⾏升级、java -jar %ETC_HOME%\ETC_Managent\script\update.jar %depotupdate%del /a/f/q %ETC_HOME%\ETC_Managent\apache-tomcat\conf\update.properties))pause。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
tomcat假死与异常监控
在开发的tomcat服务应用中,经常会遇到tomcat假死情况,除了每次出现假死时找出原因外,有时候由于业务的重要性,需要及时发现服务异常并及时解决。
所以本人就想通过Linux定时任务定时监控的方式来预防这个问题,一旦发现及时通知告警并重启服务,然后才通过日志查明原因从根本上解决。
1)tomcat假死状态
处于假死状态时,后台日志不在生成,服务链接没有响应,但tomcat的进程是存在的,所以若要监控是否处于假死状态可以从日志和服务链接方面入手,但由于检测日志比较麻烦,本人选择的是通过选择某个服务链接获取其访问状态码http_code,若状态码不正常则确认为tomcat服务异常。
例如:
url=“http://localhost/….”
code=$(curl -o /dev/null --retry 3 -s -w %{http_code} $url)
echo “${code}”
上面脚本中url变量为选择的适合的监控链接,code就是该链接正常时应该返回的返回码,正常是为200,有时候由于浏览器缓存可能返回302等也是正常的,所以建议最好选择那种后台的链接能够返回200的,这样检测起来比较方便。
2)tomcat异常监控
在tomcat运行日志中,经常会出现一些异常,对于有些异常我们可以不用管,但例如数据库链接异常、内存溢出异常等,这些异常会直接导致服务不能正常使用,所以需要对这些类型的异常进行监控,同样的本人也是通过Linux脚本实时检查tomcat运行日志的方式来检测服务状态。
脚本如下:
errormessage1="ng.OutOfMemoryError"
if
cat ${tomcatpath}/logs/catalina.out |grep "$errormessage1">/dev/null then
restartFlag="yes"
其实就是通过cat |grep 的方式来查找异常特征字符串是否在运行日志文件中存在,存在则代表出现了该类异常,当然这是需要程序对该类异常做了处理的(捕捉到并输出到控制台)。
附带说明:语句 cat …加上了 >/dev/null是为了不输出具体查询的结果的
3)tomcat重启
检查出这些异常时,一般先通过重启服务的方式来优先恢复服务,则对tomcat进行脚本重启。
tomcat重启的原理是:先通过命令获取tomcat进程id,然后kill掉该进程id,再重启tomcat命令即可,具体命令如:
#tomcat部署路径
tomcatpath="/data/apps/tomcat"
#获取tomcat进程id
pid=$(ps -ef |grep java| grep ${tomcatpath} |grep -v grep | awk '{print $2}')
kill -9 $pid
cd ${tomcatpath}
./bin/startup.sh
4)配置Linux定时任务
将脚本编辑保存到文件check.sh
设置脚本文件为可执行
#chmod u+x check.sh
添加到定时任务
#cront -e 后编辑添加
*/10 * * * * /data/apps/scripts/check.sh >> /data/apps/scripts/check.log 2>&1
(此处设置为每10分钟检查一次)
5)附完整的同时监控假死和内存溢出/数据库链接异常的监控脚本代码
#!/bin/sh
# ----------------------------------
# 服务器错误检查与服务重启定时脚本
# 每10分钟执行一次
# ----------------------------------
export LANG="zh_CN.GB18030"
export LANGUAGE="zh_CN.GB18030:zh_CN.GB2312:zh_CN"
export SUPPORTED="zh_CN.GB18030:zh_CN:zh"
export SYSFONT="lat0-sun16"
export SYSFONTACM="8859-15"
tomcatpath="/data/apps/tomcat"
errormessage1="com.alibaba.druid.pool.GetConnectionTimeoutException" errormessage2="ng.OutOfMemoryError"
exetime=$(date +"%y-%m-%d_%H:%M:%S")
checkUrl="http://localhost/web/…”
echo "check ${tomcatpath}/logs/catalina.out at ${exetime}"
pid=$(ps -ef |grep java| grep ${tomcatpath} |grep -v grep | awk '{print $2}')
echo "pid=${pid}"
#是否重启标志,yes重启,no不重启
restartFlag="no"
##
hicode=$(curl -o /dev/null --retry 3 -s -w %{http_code} $checkUrl)
if [ "$hicode" != "200" ]
then
echo "code=${hicode}"
restartFlag="yes"
elif
cat ${tomcatpath}/logs/catalina.out |grep "$errormessage1">/dev/null then
restartFlag="yes"
elif
cat ${tomcatpath}/logs/catalina.out |grep "$errormessage2">/dev/null then
restartFlag="yes"
fi
##
if [ $restartFlag = "yes" ]
then
#此处添加告警,可通过发邮件或发短信两种方式
kill -9 $pid
mv ${tomcatpath}/logs/catalina.out
${tomcatpath}/logs/catalina.${exetime}
cd ${tomcatpath}
echo "wait at $(date +"%y-%m-%d_%H:%M:%S")"
#sleep 60
./bin/startup.sh
echo "restart at $(date +"%y-%m-%d_%H:%M:%S")"
else echo "checkweb is normal at $(date +"%y-%m-%d_%H:%M:%S")" fi。