linux系統上關於tomcat監控，很多平臺只是監控端口判斷服務正常，忽略對tcp鏈接情況（監控項中應定義zabbix-agentd關於tcp連接監控），tomcat父進程是否僵死，如果不做監控檢查機制，在衆多的應用服務器，使用集羣負載，依然存在某個tomcat線程堆積，造成服務僵死，變現爲死套接字不斷增加無法釋放，但是服務還在，如果用了zabbix監控使用現成的模塊jmx監控
tomcat監控項
1、tomcat的應用端口(如8080)，比較有侷限性
2、tomcat的jmx監控，是tomcat的性能監控。堆內存大小、線程峯值
3、tomcat可以寫個靜態文件 curl -I URL，獲取報文頭的http返回碼200則爲正常。
########## 方法在下面 ##########
------------------- JMX 監控 tomcat --------------
在tomcat被監控端安裝jdk和tomcat環境，然後在tomcat的安裝目錄的bin目錄下的catalina.sh文件
#需要進行用戶驗證
# ----- Execute The Requested Command -----------------------------------------”
之前插入新的一行(中間沒有換行)
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Djava.rmi.server.hostname=192.168.182.5"
==================================================================================
注意事項
1，-Djava.rmi.server.hostname=192.168.182.5中的IP地址要寫成本機配置的IP，也可以配置成0.0.0.0，不然有可能會導致監聽不能正常啓動。
使用JConsole監控本地應用程序在開發和創建原型是非常有效的，但不推薦用戶生產環境，因爲JConsole本省也消耗大量的系統資源
2，每個tomcat的端口不要重複，例如，一個ip上有多個tomcat實例，每個實例一個端口
=====================================================================================
在重啓tomcat服務前必須保證在hosts中有ip和主機名的映射。
在jdk的安裝目錄下認證用戶，配置用戶權限
編輯jmxremote.access和jmxremote.password 在jdk的安裝目錄下
which java
cd /usr/local/jdk/jre/lib/management
cp jmxremote.password.template jmxremote.password
chmod 600 jmxremote.access jmxremote.password
cp jmxremote.password.template jmxremote.password /opt/tomcat/tomcat1/conf/
cd /opt/tomcat/tomcat1/conf/
chmod 600 jmxremote.access jmxremote.password
vi jmxremote.password ---jdk 與 tomcat的jmxremote.password都修改
在jmxremote.password文件中，取消註釋,或者 加入自己的用戶名和密碼
monitorRole QED
controlRole R&D
在jmxremote.access 取消註釋
monitorRole readonly
controlRole readwrite \
create javax.management.monitor.*,javax.management.timer.* \
unregister
重啓tomcat服務
可以使用netstat -an | grep 9999命令查看端口是否正常啓動。可以看到端口9999的網絡連接
開始配置終端，獲取本機windows客戶端ip，linux機器執行 export DISPLAY=10.35.40.26:0.0(這是我的windowsＩＰ，待會兒要開啓圖形化界面，如果是ｌｉｎｕｘ機器是本機虛擬機，那麼IP應該寫LINUX的IP的網關 192.168.182.1)
打開 Xmanager - Passive
[root@db1 bin]# ./jconsole
輸入 192.168.182.5:9999 monitorRole QED 進入
ＯＫ
########## 漫談 tomcat 優化與 time-out #########
【tomcat】
啓動一般會所在用戶的環境變量
TIME_WAIT相關sysctl參數及超時時間
[root@lvs ~]# sysctl -a | grep tw
net.ipv4.tcp_max_tw_buckets //處於TIME_WAIT狀態的socket數目的最大值
net.ipv4.tcp_tw_recycle = 1 //打開TIME_WAIT快速回收機制
net.ipv4.tcp_tw_reuse //TIME_WAIT狀態socket複用
Sysctl –w net.ipv4.tcp_tw_len = 2 設置TIME_WAIT在2秒後超時
默認TIME_WAIT超時時間爲60秒，不可通過sysctl調節
如果tomcat本身指定的話:vi bin/setclasspath.sh
JAVA_HOME=/mall/jdk/jdk1.7.0_80
JRE_HOME=/mall/jdk/jdk1.7.0_80/jre
爲httpsession安全性考慮，防止客戶端腳本讀取session cookie內容諸如進行CSRF/XSS惡意http***，可在tomcat6的
conf/context.xml配置文件中配置 <Context useHttpOnly="true"> 爲自定義cookie及屬性添加HttpOnly屬性，在set-Cookie頭部信息設置時可以添加"httponly"
tomcat訪問url不需要加項目名，直接IP+port
<context path="" docBase="/home/tomcat/tomcat8080/webapps/jsjp" reloadable=“true”>
tomcat監控 1、tomcat的應用端口(如8080)，比較有侷限性
2、tomcat的jmx監控，是tomcat的性能監控，tomcat的運行情況
3、tomcat可以寫個靜態文件 curl -I URL，獲取報文頭的http返回碼200則爲正常。
---------------------------------------------------------------------------------------
這個配置文件時tomcat7的server.xml 關於線程池
Tomcat最大可能達到的線程數是maxConnections這個參數和併發數
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="3000" minSpareThreads="800"/> maxThreads:Tomcat線程池最多能起的線程數；線程數是pool，用來處理連接數的
maxConnections:Tomcat最多能併發處理的請求（連接）；
<Connector executor="tomcatThreadPool" port="8084" protocol="org.apache.coyote.http11.Http11AprProtocol"
connectionTimeout="60000"
keepAliveTimeout="30000" 因爲用了Keep-Alive導致程序性能下降，TPS降低了很多導致的
maxKeepAliveRequests="8000"
maxHttpHeaderSize="8192"
URIEncoding="UTF-8"
enableLookups="false"
acceptCount="1000" acceptCount:Tomcat維護最大的對列數；maxThreads是指Tomcat線程池做多能起的線程數，而 maxConnections 則是Tomcat一瞬間做多能夠處理的併發連接數。
比如maxThreads=1000，maxConnections=800，假設某一瞬間的併發時1000，那麼最終Tomcat的線程數將會是800，即同時處理800個請求，剩餘200進入隊列“排隊”，
如果acceptCount=100，那麼有100個請求會被拒掉。
disableUploadTimeout="true"
redirectPort="8443" />
keepAliveTimeout：長連接最大保持時間（毫秒），表示在下次請求過來之前，Tomcat 保持該連接多久，默認是使用 connectionTimeout 時間，-1 爲不限制超時。
thread dump看其實真正處於RUNNABLE狀態的線程很少，絕大部分線程都處於TIMED_WAITING狀態
netstat -nat|grep 8098 |grep TIME_WAIT |wc -l 2980
netstat -nat|grep 8098 |wc -l 3000 大夥都開始糾結爲什麼線程會漲到3000，而且發現即使峯值過了線程數並不會降下來。
我們首先想到的是：後端應用的處理瞬間比較慢，“堵住了”導致前端線程數漲了起來。但是優化一個版本上線後發現雖然漲的情況有所好轉，但是最終線程池還是會達到3000這個最大值。
直接跟各位說下目前我得到的結論：
1、首先是爲什麼線程不釋放的問題？
簡單說下我驗證的Tomcat(7.0.54)線程池大概的工作機制
Tomcat啓動時如果沒有請求過來，那麼線程數（都是指線程池的）爲0；一旦有請求，Tomcat會初始化minSapreThreads設置的線程數；
Tomcat不會主動對線程池進行收縮，除非確定沒有任何請求的時候，Tomcat纔會將線程池收縮到minSpareThreads設置的大小；
Tomcat6之前的版本有一個maxSpareThreads參數，但是在7中已經移除了， 所以只要前面哪怕只有一個請求，Tomcat也不會釋放多於空閒的線程。至於Tomcat爲什麼移除maxSpareThreads這個參數，我想也是出於性能的考慮，不停的收縮線程池性能肯定不高，而多餘的線程處於等待狀態的好處是一有新請求過來立刻可以處理。
而且大量的Tomcat線程處於等待狀態不會消耗CPU，但是會消耗一些JVM存儲。進一步驗證發現只有使用Keep-Alive（客戶端和服務端都支持）時纔是這種表現，如果客戶端沒有使用Keep-Alive那麼線程會隨着TCP連接的釋放而回收。
注意：根據前面所說，只是併發那一瞬間Tomcat會起800個線程處理請求，但是穩定後，某一瞬間可能只有很少的線程處於RUNNABLE狀態，大部分線程是TIMED_WAITING，如果你的應用處理時間夠快的話。
所以真正決定Tomcat最大可能達到的線程數是maxConnections這個參數和併發數，當併發數超過這個參數則請求會排隊，這時響應的快慢就看你的程序性能了。
Tomcat會停止長時間閒置的線程。 Tomcat還有一個參數叫 maxIdleTime ：其實從這個參數解釋也能看出來Tomcat會停止閒置了超過一定時間的線程的，這個時間就是maxIdleTime
添加虛擬內存
JAVA_OPTS="-server -Xms2048m -Xmx4086m -XX:PermSize=256M -XX:MaxNewSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true"
Xms：jvm初始化堆大小
Xmx：最大java堆大小，超出就會內存溢出
CATALINA_OPTS="
-server
-Xms6000M jvm初始化堆大小
-Xmx6000M 最大java堆大小，超出就會內存溢出
-Xss512k 表示每個 Java 線程堆棧大小，JDK 5.0 以後每個線程堆棧大小爲 1M，以前每個線程堆棧大小爲 256
-XX:NewSize=2250M 設置新生代內存大小。
-XX:MaxNewSize=2250M 設置最大新生代新生代內存大小
-XX:PermSize=128M 設置持久代內存大小
-XX:MaxPermSize=256M 設置最大值持久代內存大小，永久代不屬於堆內存，堆內存只包含新生代和老年代。
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=31
-XX:+CMSParallelRemarkEnabled
-XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-Duser.timezone=Asia/Shanghai
-Djava.awt.headless=true"
二：現網zabbix使用jvm工具，監控tomcat性能。
1、安裝Zabbix-Java-gateway（忽略）
2、tomcat啓動腳本添加參數，開啓JMX（忽略）
3、zabbix新建監控項-觸發器-圖形
圖形化：
監控項定義，tomcat性能監控項：
堆內存已使用，已提交(與系統tcp監控相輔相成)，活動線程總計、峯值
參考博客 http://www.cnblogs.com/Eivll0m/p/5446311.html