WebSphere簡單故障排查

工做中常常遇到這樣那樣的或有跡可循、或「靈異」的狀況：WebSphere在某次中止後沒法啓動了，部署在集羣上的應用沒法經過IHS訪問，應用更新後重啓服務器發送回滾……出現問題固然均可以聯繫專門的中間件管理員來解決，但等管理員趕到現場，也許時間已過去半天，問題也許很簡單，幾分鐘就能解決，因此若是你會一些基本的排查技巧和診斷方法，那麼這些小問題就能夠本身迎刃而解了。

下面我就介紹幾種常見的簡單錯誤，但願對於現場人員能有所幫助：

應用沒法訪問

下面是一張常見的由IBM HTTP SERVER（IHS）轉發到後端AppCluster上的拓撲結構：

應用沒法訪問，問題能夠出如今HTTP Server上，或者App Server上，更可能發生在數據庫上，因此第一步須要縮小範圍，肯定問題發生的點。

我在這裏假設IHS的應用地址爲http://192.168.1.51 /yingyong

DMGR的訪問地址是http://192.168.1.51:9060/admin

APP SERVER的應用地址爲http://192.168.2.50:9080/yingyong和http://192.168.2.51:9080/yingyong

 

1. 找不到服務器或404錯誤

訪問http://192.168.1.51，肯定IHS是否正常，若是頁面沒法顯示，那麼去「服務」中嘗試重啓「IBM HTTP SERVER V6.x」。服務啓動失敗的話，「服務」只會提示你一句服務沒法啓動或者啓動後又由於致命錯誤中止。因此你要到IBM\HTTPServer\bin目錄下運行apache –k start或者httpd –k start，失敗的話會有詳細信息供參考。通常是端口被佔用或者config目錄下的httpd.conf格式出錯（它會提示你出錯的行數）。

若是IHS訪問無缺，那麼嘗試分別訪問 http://192.168.2.50（51）:9080/yingyong，若是訪問失敗，那麼是IHS轉發失敗。

能夠在管理控制檯http://192.168.1.51:9060/admin中的「服務器」——「Web服務器」中勾選相應的webserver，「生成插件」而且「傳播插件」。

 

 

不少IHS轉發失敗是由於應用發佈過程當中沒有選則發佈到webserver上，或在傳播插件的過程當中，因爲目錄訪問控制等緣由傳播失敗。你能夠在「應用程序」中找到本身的應用，點擊「管理模塊」，肯定是否正確的發佈到app server上和webserver上了，注意首先在第一個框中選擇要發佈到集羣和服務器，而後勾選模塊前的勾，最後必定要點「應用」，而不是直接肯定。

轉發失敗的緣由不少，不過最快的解決方法是手動複製文件。生成插件後控制檯會提示文件生成的位置，直接拿到而後複製到傳播插件失敗的位置就能夠了。

不過我也遇到過很蹊蹺的狀況，明明部署正確，傳播正確，確依舊沒法訪問。這時候你要看一下生成的plugin-cfg.xml文件

<UriGroup Name="default_host_server1_xzh-hasheiNode01_Cluster_URIs"> 
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/> 
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/> 
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>

       是否有你的應用url那行存在，不存在的話手動添加一下便可，不過記得下次生成插件後注意再修改。

       最後要肯定app server是否已經啓動，是否遇到錯誤退出了，這點在下面一部分細說。

2. 505 Internal Error

505內部錯誤有三種狀況，一是程序出錯，不是本文討論的重點。二是AppServer或應用程序沒有正常啓動，三是數據庫鏈接失敗。

AppServer是否運行能夠經過訪問管理控制檯，查看JAVA進程肯定。在profiles\AppSrv01\logs\server1目錄下會有一個pid文件，此文件記錄的PID號即爲進程號。 Windows下在「任務管理器」點擊「查看」—「選擇列」，勾選PID-進程標識符便可顯示。Unix/linux下運行ps –ef | grep PID或者ps –ef | grep java，查看該app的進程和全部的JAVA進程。注意：在安裝DM profile的節點上，通常至少有DM、Node agent、app server三個java進程，注意區分。

肯定服務器沒有運行或者想重啓時，在profiles\AppSrv01\bin下運行 startServer.sh(bat）便可啓動服務器，觀察啓動情況，直到出現「爲電子商務開放服務器 server1」，即爲啓動成功。若是失敗，那就要打開logs下的SystemOut.log，查看最新的日誌，查找error信息。

通常啓動失敗無外乎端口衝突、權限不夠。

端口衝突

端口出錯在SystemOut.log中的信息以下：

TCPC0003E: TCP 通道 TCP_2 初始化失敗。主機 * 和端口 9081 的套接字綁定失敗。端口可能已在使用。

這時你能夠用netstat –an 命令查看監聽端口信息，而後用tcpview或者icesword等工具查看佔用端口的進程，linux/unix下能夠用netstat –an | grep LISTEN（或端口號）直接查看，而後使用lsof -i :端口號或者rmsock來查看佔用端口的進程。

這時候你也許才恍然想起某個不經意的操做將websphere的端口占用了，怎麼辦？若是要WebSphere做出讓步，那麼能夠修改profile_path\config\cells\cell_name\nodes\node_name 目錄中serverindex.xml文件：

specialEndpoints xmi:id="NamedEndPoint_1243228596786" endPointName="WC_adminhost"> 
<endPoint xmi:id="EndPoint_1243228596786" host="*" port="9060"/> 
</specialEndpoints> 
<specialEndpoints xmi:id="NamedEndPoint_1243228596787" endPointName="WC_defaulthost"> 
……

看到端口號了麼？不過要注意WC_adminhost、WC_defaulthost、 WC_adminhost_secure、WC_defaulthost_secure，也就是經常使用的管理端口、應用訪問端口和它們各自的SSL端口，被修改後須要到profile_path\config\cells\cell_name再修改virtualhosts.xml文件中的相應端口（添加亦可），不然出現虛擬主機未定義的錯誤可別怪我沒提醒。（我遇到過不少說用IHS能夠訪問，可是直接訪問端口出錯的狀況，緣由就是沒有添加相應的虛擬主機，在管理控制檯——虛擬主機——default host裏添加改動後的端口就能夠了）。

權限不足

權限不足通常發生在Unix/Linux下，比較常見的是安裝websphere時新建了一個單獨的用戶和組，可是開發階段權限管理不嚴致使開發人員也有root權限，啓停沒有su到was用戶，等到權限回收以後發現沒法啓動服務了。這時候只要用root權限chown username/groupname 整個安裝 目錄便可。

還有一種狀況是修改的端口<1024，在Unix/Linux下只能用root來起了。

其它狀況

還要注意文件系統的狀況，見過幾回access.log和dump文件把文件系統撐滿的。

應用更新失敗

應用更新了，修改的文件直接上傳到目錄，重啓應用程序，測試正常。等等！爲什麼重啓app server或者集羣下重啓dm後又變回修改前了呢？

這應該是dm的同步機制在搗鬼，你有沒有注意到profiles\AppSrv01 \config\cells\cell_name\applications目錄下也有你的程序，打開能夠看到並非程序全部的內容都在此，而是 web.xml和WEB-INF等重要內容。因此若是你更新的文件在config目錄下也存在，那麼你須要這裏也更新一份。集羣環境下還要注意 profiles\Dmgr的config目錄下還有一份等着你呢。

3. 肯定數據庫無端障

這個很簡單，只要用sqlplus鏈接數據庫正常且能查詢便可。

4. 日誌文件很重要

日誌文件是排查的依賴。我見過很多項目，由於處於試運行修改階段，log4j中輸出日誌信息極多，每條sql語句都絲絕不差的打出來，致使1m大小的SystemOut.log文件十幾分鍾就寫滿，10個SystemOut.log存檔也頂不過幾小時的日誌量（單個文件1～2M，總共10～20個存檔是通常設置），等我趕到時案發現場已經蕩然無存。（這種狀況通常是重啓能暫時解決問題，可是故障緣由沒有找到）

因此即時保存當時日誌是很重要的，logs\server1下的 SystemOut.log、SystemErr.log必定要保存一份，並記下故障發生的時間。

WebSphere不像Weblogic，能夠在console窗口後一直看到運行的日誌，在unix/linux下，你能夠用tail –f SystemOut.log來達到這個效果，windows下也有一個tail工具，後跟文件名運行就能夠了。