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

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

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

應用無法訪問

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

應用無法訪問，問題可以出現在HTTP Server上，或者App Server上，更可能發生在數據庫上，所以第一步需要縮小范圍，確定問題發生的點。

我在這里假設IHS的應用地址

DMGR的訪問地址

APP SERVER的應用地址

1. 找不到服務器或404錯誤訪問http://192.168.1.51，確定IHS是否正常，如果頁面無法顯示，那么去“服務”中嘗試重啟“IBM HTTP SERVER V6.x”。服務啟動失敗的話，“服務”只會提示你一句服務無法啟動或者啟動后又因為致命錯誤停止。所以你要到IBMHTTPServerbin目錄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文件

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

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

2. 505 Internal Error

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

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

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

一般啟動失敗無外乎端口沖突、權限不夠。

端口沖突

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

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

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

看到端口號了么？不過要注意WC_adminhost、WC_defaulthost、 WC_adminhost_secure、WC_defaulthost_secure，也就是常用的管理端口、應用訪問端口和它們各自的SSL端口，被修改后需要到profile_pathconfigcellscell_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的同步機制在搗鬼，你有沒有注意到profilesAppSrv01 configcellscell_nameapplications目錄下也有你的程序，打開可以看到并不是程序所有的內容都在此，而是 web.xml和WEB-INF等重要內容。所以如果你更新的文件在config目錄下也存在，那么你需要這里也更新一份。集群環境下還要注意 profilesDmgr的config目錄下還有一份等著你呢。

3. 確定數據庫無故障

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

4. 日志文件很重要

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

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

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