WebSphere簡單故障排查

工作中經(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è)代運營等,從售前售中售后,我們都將竭誠為您服務(wù),您的肯定,是我們大的嘉獎;創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供關(guān)嶺建站搭建服務(wù),24小時服務(wù)熱線:13518219792,官方網(wǎng)址:muchs.cn

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

應(yīng)用無法訪問

下面是一張常見的由IBM HTTP SERVER(IHS)轉(zhuǎn)發(fā)到后端AppCluster上的拓撲結(jié)構(gòu):

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

我在這里假設(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ù)無法啟動或者啟動后又因為致命錯誤停止。所以你要到IBMHTTPServerbin目錄apache –k start或者httpd –k start,失敗的話會有詳細信息供參考。一般是端口被占用或者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īng)用發(fā)布過程中沒有選則發(fā)布到webserver上,或在傳播插件的過程中,由于目錄訪問控制等原因傳播失敗。你可以在“應(yīng)用程序”中找到自己的應(yīng)用,點擊“管理模塊”,確定是否正確的發(fā)布到app server上和webserver上了,注意首先在第一個框中選擇要發(fā)布到集群和服務(wù)器,然后勾選模塊前的勾,最后一定要點“應(yīng)用”,而不是直接確定。

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

不過我也遇到過很蹊蹺的情況,明明部署正確,傳播正確,確依舊無法訪問。這時候你要看一下生成的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"/>

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

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

2. 505 Internal Error

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

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

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

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

端口沖突

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

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

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

這時候你也許才恍然想起某個不經(jīng)意的操作將websphere的端口占用了,怎么辦?如果要WebSphere作出讓步,那么可以修改profile_pathconfigcellscell_namenodesnode_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,也就是常用的管理端口、應(yīng)用訪問端口和它們各自的SSL端口,被修改后需要到profile_pathconfigcellscell_name再修改virtualhosts.xml文件中的相應(yīng)端口(添加亦可),否則出現(xiàn)虛擬主機未定義的錯誤可別怪我沒提醒。(我遇到過很多說用IHS可以訪問,但是直接訪問端口出錯的情況,原因就是沒有添加相應(yīng)的虛擬主機,在管理控制臺——虛擬主機——default host里添加改動后的端口就可以了)。

權(quán)限不足

權(quán)限不足一般發(fā)生在Unix/Linux下,比較常見的是安裝websphere時新建了一個單獨的用戶和組,但是開發(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的同步機制在搗鬼,你有沒有注意到profilesAppSrv01 configcellscell_nameapplications目錄下也有你的程序,打開可以看到并不是程序所有的內(nèi)容都在此,而是 web.xml和WEB-INF等重要內(nèi)容。所以如果你更新的文件在config目錄下也存在,那么你需要這里也更新一份。集群環(huán)境下還要注意 profilesDmgr的config目錄下還有一份等著你呢。

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

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

4. 日志文件很重要

日志文件是排查的依賴。我見過不少項目,因為處于試運行修改階段,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窗口后一直看到運行的日志,在unix/linux下,你可以用tail –f SystemOut.log來達到這個效果,windows下也有一個tail工具,后跟文件名運行就可以了。

網(wǎng)頁題目:WebSphere簡單故障排查
URL鏈接:http://muchs.cn/article26/chshjg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設(shè)計公司、定制開發(fā)、營銷型網(wǎng)站建設(shè)企業(yè)網(wǎng)站制作、關(guān)鍵詞優(yōu)化、軟件開發(fā)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)

綿陽服務(wù)器托管