工作中經(jīng)常遇到這樣那樣的或有跡可循、或“靈異”的情況：WebSphere在某次停止后無法啟動了，部署在集群上的應(yīng)用無法通過IHS訪問，應(yīng)用更新后重啟服務(wù)器發(fā)送回滾……出現(xiàn)問題當(dāng)然都可以聯(lián)系專門的中間件管理員來解決，但等管理員趕到現(xiàn)場，也許時間已過去半天，問題也許很簡單，幾分鐘就能解決，所以如果你會一些基本的排查技巧和診斷方法，那么這些小問題就可以自己迎刃而解了。

創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于做網(wǎng)站、網(wǎng)站設(shè)計、關(guān)嶺網(wǎng)絡(luò)推廣、微信小程序、關(guān)嶺網(wǎng)絡(luò)營銷、關(guān)嶺企業(yè)策劃、關(guān)嶺品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們大的嘉獎；創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供關(guān)嶺建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：aaarwkj.com

下面我就介紹幾種常見的簡單錯誤，希望對于現(xiàn)場人員能有所幫助：

應(yīng)用無法訪問

下面是一張常見的由IBM HTTP SERVER（IHS）轉(zhuǎn)發(fā)到后端AppCluster上的拓?fù)浣Y(jié)構(gòu)：

應(yīng)用無法訪問，問題可以出現(xiàn)在HTTP Server上，或者App Server上，更可能發(fā)生在數(shù)據(jù)庫上，所以第一步需要縮小范圍，確定問題發(fā)生的點(diǎn)。

我在這里假設(shè)IHS的應(yīng)用地址

DMGR的訪問地址

APP SERVER的應(yīng)用地址

1. 找不到服務(wù)器或404錯誤訪問http://192.168.1.51，確定IHS是否正常，如果頁面無法顯示，那么去“服務(wù)”中嘗試重啟“IBM HTTP SERVER V6.x”。服務(wù)啟動失敗的話，“服務(wù)”只會提示你一句服務(wù)無法啟動或者啟動后又因?yàn)橹旅e誤停止。所以你要到IBMHTTPServerbin目錄apache –k start或者h(yuǎn)ttpd –k start，失敗的話會有詳細(xì)信息供參考。一般是端口被占用或者config目錄下的httpd.conf格式出錯（它會提示你出錯的行數(shù)）。

如果IHS訪問完好，那么嘗試分別訪問http://192.168.2.50（51）:9080/yingyong，如果訪問失敗，那么是IHS轉(zhuǎn)發(fā)失敗。

可以在管理控制臺http://192.168.1.51:9060/admin中的“服務(wù)器”——“Web服務(wù)器”中勾選相應(yīng)的webserver，“生成插件”并且“傳播插件”。

很多IHS轉(zhuǎn)發(fā)失敗是因?yàn)閼?yīng)用發(fā)布過程中沒有選則發(fā)布到webserver上，或在傳播插件的過程中，由于目錄訪問控制等原因傳播失敗。你可以在“應(yīng)用程序”中找到自己的應(yīng)用，點(diǎn)擊“管理模塊”，確定是否正確的發(fā)布到app server上和webserver上了，注意首先在第一個框中選擇要發(fā)布到集群和服務(wù)器，然后勾選模塊前的勾，最后一定要點(diǎn)“應(yīng)用”，而不是直接確定。

轉(zhuǎn)發(fā)失敗的原因很多，不過最快的解決方法是手動復(fù)制文件。生成插件后控制臺會提示文件生成的位置，直接拿到然后復(fù)制到傳播插件失敗的位置就可以了。

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

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

最后要確定app server是否已經(jīng)啟動，是否遇到錯誤退出了，這點(diǎn)在下面一部分細(xì)說。

2. 505 Internal Error

505內(nèi)部錯誤有三種情況，一是程序出錯，不是本文討論的重點(diǎn)。二是AppServer或應(yīng)用程序沒有正常啟動，三是數(shù)據(jù)庫連接失敗。

AppServer是否運(yùn)行可以通過訪問管理控制臺，查看JAVA進(jìn)程確定。在profilesAppSrv01logsserver1目錄下會有一個pid文件，此文件記錄的PID號即為進(jìn)程號。 Windows下在“任務(wù)管理器”點(diǎn)擊“查看”—“選擇列”，勾選PID-進(jìn)程標(biāo)識符即可顯示。Unix/linux下運(yùn)行ps –ef | grep PID或者ps –ef | grep java，查看該app的進(jìn)程和所有的JAVA進(jìn)程。注意：在安裝DM profile的節(jié)點(diǎn)上，一般至少有DM、Node agent、app server三個java進(jìn)程，注意區(qū)分。

確定服務(wù)器沒有運(yùn)行或者想重啟時，在profilesAppSrv01bin下運(yùn)行 startServer.sh(bat）即可啟動服務(wù)器，觀察啟動狀況，直到出現(xiàn)“為電子商務(wù)開放服務(wù)器 server1”，即為啟動成功。如果失敗，那就要打開logs下的SystemOut.log，查看最新的日志，查找error信息。

一般啟動失敗無外乎端口沖突、權(quán)限不夠。

端口沖突

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

這時你可以用netstat –an 命令查看監(jiān)聽端口信息，然后用tcpview或者icesword等工具查看占用端口的進(jìn)程，linux/unix下可以用netstat –an | grep LISTEN（或端口號）直接查看，然后使用lsof -i :端口號或者rmsock來查看占用端口的進(jìn)程。

這時候你也許才恍然想起某個不經(jīng)意的操作將websphere的端口占用了，怎么辦？如果要WebSphere作出讓步，那么可以修改profile_pathconfigcellscell_namenodesnode_name 目錄中serverindex.xml文件：

看到端口號了么？不過要注意WC_adminhost、WC_defaulthost、 WC_adminhost_secure、WC_defaulthost_secure，也就是常用的管理端口、應(yīng)用訪問端口和它們各自的SSL端口，被修改后需要到profile_pathconfigcellscell_name再修改virtualhosts.xml文件中的相應(yīng)端口（添加亦可），否則出現(xiàn)虛擬主機(jī)未定義的錯誤可別怪我沒提醒。（我遇到過很多說用IHS可以訪問，但是直接訪問端口出錯的情況，原因就是沒有添加相應(yīng)的虛擬主機(jī)，在管理控制臺——虛擬主機(jī)——default host里添加改動后的端口就可以了）。

權(quán)限不足

權(quán)限不足一般發(fā)生在Unix/Linux下，比較常見的是安裝websphere時新建了一個單獨(dú)的用戶和組，但是開發(fā)階段權(quán)限管理不嚴(yán)導(dǎo)致開發(fā)人員也有root權(quán)限，啟停沒有su到was用戶，等到權(quán)限回收之后發(fā)現(xiàn)無法啟動服務(wù)了。這時候只要用root權(quán)限chown username/groupname 整個安裝 目錄即可。

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

其它情況

還要注意文件系統(tǒng)的情況，見過幾次access.log和dump文件把文件系統(tǒng)撐滿的。

應(yīng)用更新失敗

應(yīng)用更新了，修改的文件直接上傳到目錄，重啟應(yīng)用程序，測試正常。等等！為何重啟app server或者集群下重啟dm后又變回修改前了呢？

這應(yīng)該是dm的同步機(jī)制在搗鬼，你有沒有注意到profilesAppSrv01 configcellscell_nameapplications目錄下也有你的程序，打開可以看到并不是程序所有的內(nèi)容都在此，而是 web.xml和WEB-INF等重要內(nèi)容。所以如果你更新的文件在config目錄下也存在，那么你需要這里也更新一份。集群環(huán)境下還要注意 profilesDmgr的config目錄下還有一份等著你呢。

3. 確定數(shù)據(jù)庫無故障

這個很簡單，只要用sqlplus連接數(shù)據(jù)庫正常且能查詢即可。

4. 日志文件很重要

日志文件是排查的依賴。我見過不少項(xiàng)目，因?yàn)樘幱谠囘\(yùn)行修改階段，log4j中輸出日志信息極多，每條sql語句都絲毫不差的打出來，導(dǎo)致1m大小的SystemOut.log文件十幾分鐘就寫滿，10個SystemOut.log存檔也頂不過幾小時的日志量（單個文件1～2M，總共10～20個存檔是一般設(shè)置），等我趕到時案發(fā)現(xiàn)場已經(jīng)蕩然無存。（這種情況一般是重啟能暫時解決問題，但是故障原因沒有找到）

所以即時保存當(dāng)時日志是很重要的，logsserver1下的 SystemOut.log、SystemErr.log一定要保存一份，并記下故障發(fā)生的時間。

WebSphere不像Weblogic，可以在console窗口后一直看到運(yùn)行的日志，在unix/linux下，你可以用tail –f SystemOut.log來達(dá)到這個效果，windows下也有一個tail工具，后跟文件名運(yùn)行就可以了。