摘要：大家好，我叫湯金城，今天和大家分享一下我在公司業務方面故障排查遇到的一些坑，以及進行性能調優的解決方法。性能的優化在我看來，性能優化和監控是分不開的，現在關于優化的配置非常多，適合自己的才是最好的。

本期主講：湯金城，多年從事移動互聯網相關運維工作，帶領團隊維護數百臺服務器，擁有豐富的故障排查和性能優化實戰經驗，擅長業務拆分，高可用架構設計。

大家好，我叫湯金城，今天和大家分享一下我在公司業務方面故障排查遇到的一些坑，以及進行性能調優的解決方法。記得剛來公司接手業務的時候，IT架構亂的一塌糊涂，前任留下來很多坑：服務器資源緊張，初期架構沒考慮擴展性等等，不過對于初創企業來說這些問題都是正常的。

故障的及時發現與實時分析

首先來講下公司初期的一個需求，因為公司對業務很重視，所以領導需要第一時間了解故障原因是什么以及怎樣做才能預防故障的再次發生。前期我考慮的就是監控日志，通過實時分析日志發現問題，開始我們使用的是一款python寫的開源工具ganglia-logtailer，相當于對log進行tail實時獲取并截取想要的信息進行監控，但是一段時間后發現這種工具的效率不高，并且數據并不是很準確。

然后就用了ELK，采用Logstash進行數據采集，存入redis，再由logstash從redis獲取數據，中間進行一個過濾以及分析，存入到elasticsearch，通過kibana進行數據展示，同時logstash還可以對獲取的數據進行監控以及郵件報警。

通過上面這種方式，確實能對后端服務器、存儲等設備的故障和系統信息進行統計，但很多業務故障并不單純是內部IT系統問題造成的，我們經常發現前端出現掉流量，掉訪問的現象，而后端運行完全正常，通過這種內部監控是找不出原因的，這時候就需要考慮一些外部原因了。

下面給大家看一些故障排查案例：

實例1：服務器計算時長
有一段時間，每到晚上業務最高峰網站訪問都會變慢，從內網并沒看出什么明顯訪問異常，那時候剛上了監控寶，于是就部署上了監控外部分析，白天都很正常，一到晚上業務高峰期報警就增多了。監控寶的分析做的還不錯，是基于curl來做的監控，curl本身就可以打印出相關連接時間 ，監控寶的響應時間報告包括一下參數：

DNS域名解析時間：訪問網站的第一步就是DNS解析，如果這個時間消耗長，就得看看是不是DNS解析商那塊出了問題；

建立連接：TCP三次握手建立連接的時間，如果5秒內無法建立連接，就會報無法連接服務器；
服務器計算：監控服務器的處理能力；
內容下載：網頁內容下載到本地的時長；

通過以上報警可以看出訪問消耗在了服務器計算能力上，那么很明顯還是服務端的問題，于是又對服務器進行了一次檢查，這次著重檢查了服務器配置，結果發現被入口的nginx給坑了，nginx有個worker_connections參數，早期服務器沒什么訪問量的時候設置的比較低，只設置了8000，難怪每到晚上estab連接數最高就到32000左右，從未看到飆到32000以上，于是將worker_connections調到對應的數，這個問題就解決了，后面訪問量自然就漲上去了，相比以前訪問峰值PV漲了足足45%。

實例2：移動用戶無法訪問網站

上面是4月21日交換機的入口出口圖，在20點整的時候出現一個流量的掉坑，根據這張圖可以很明顯的看到流量在進來的時候就已經減少了，這個時候內部監控系統卻沒發現有其他異常，下面再看下nginx的入口出口圖：

可以很明顯的看到流量進來就減少了，造成出去的流量減少，那么問題肯定出在外部。

這是監控寶的告警信息，可以很明顯的看到4月21日20點之后，持續25分鐘的移動用戶節點無法訪問。

這時候就不是我們的問題，而是機房的事了，馬上打電話給機房反饋情況，機房幫我們做了路由優化之后故障得到解決，整個過程持續了將近20分鐘。

性能的優化
在我看來，性能優化和監控是分不開的，現在關于優化的配置非常多，適合自己的才是最好的。我通常會在修改配置后，先進行壓力測試，然后觀察內部監控、外部監控的性能表現進行調整。這里給大家推薦一些常用的系統參數：
net.ipv4.tcp_fin_timeout = 30
net.core.somaxconn = 8196
net.ipv4.tcp_max_syn_backlog = 8196
net.ipv4.ip_local_port_range = 1024 65000

再強調一次，因為每個公司的業務場景都不一樣，只有了解了自己業務的真實需求才能針對性的進行性能調優，千萬不要盲目對照別人的參數去調整配置，以上參數對我們的業務來說是最優的，但可能在某些業務場景下反而會影響性能。所以建議大家先留一份原有參數的備份，如果調試有問題可以回滾。

下面給大家分享幾篇干貨，都是關于time_wait tcp listen backlog這些受爭議的參數，大家可以參考，然后自己做調整，記得先對照參數備份原有參數，另外有些參數sysctl -p后生效時間可能要2到5分鐘。

http://mp.weixin.qq.com/s?__biz=MzA3MzYwNjQ3NA==&mid=403319808&idx=1&sn=ddae082f5b844d040b9ab23c9c0eb778&scene=23&srcid=0311SD5dPUGnPq7sTqzC2vHn#rd
http://mp.weixin.qq.com/s?__biz=MzA3MzYwNjQ3NA==&mid=403232978&idx=1&sn=4ed396ac1999add1c866419bd62b0e75&scene=23&srcid=0307e64zzFVkDViC4iDlvIbD#rd
http://dngood.blog.51cto.com/446195/988968
http://blog.hellosa.org/2011/04/21/tcp-kernel-nat.html
http://www.udpwork.com/item/6909.html
http://blog.csdn.net/largetalk/article/details/16863689
https://www.douban.com/note/178129553/
http://mp.weixin.qq.com/s?__biz=MjM5NzUwNDA5MA==&mid=201005717&idx=1&sn=74036633114ee6212e57ee4576dbfcbc&3rd=MzA3MDU4NTYzMw==&scene=6#rd
http://www.cnxct.com/something-about-phpfpm-s-backlog/

還有更多的干貨這里就不方便貼出了，有需要的可以找我要。以上就是今天的分享，如有不足之處請大家多多包涵。

問：你現在外部監控是怎么做的？
答：目前外部監控我們通過監控寶監控了靜態頁面和動態頁面，靜態頁面監控我的緩存服務器，動態頁面監控的后端服務器。我們主要是URL監控，如果你們API使用比較多，也可以用監控寶進行API監控。此外，監控寶也提供內部系統監控的，采用agent方式對系統所關注的應用組件性能做監控，并不比zabbix差，而且還支持電話報警。

問：請問運維和領導溝通有什么技巧嗎？
答：直接曬數據最有力，領導喜歡看數據報告，要把各個方面的性能圖和數據給他看，然后給他挑刺，用數據說話抵得上千言萬語。不過這需要做到全面的監控，才可能獲取有說服力的完整數據，特別是隨著業務的增長，以前遺留下的一些問題在量小的時候并不怎么明顯，訪問壓力大了才會爆發出來，這時候如果有前后的對比分析，就可以讓領導為業務增長買單。

問：那數據用什么樣的方式呈現比較好？
答：當然是圖表，監控寶提供一些基礎數據的圖表，如果希望根據自己的業務定制圖表，可以使用ganglia集群監控，搭建方便，模塊多，圖形非常適合分析排查故障。

問：那能不能稍微總結下，對一個初創公司來說，有哪些工作是從一開始就必須要做的？
答：壓測和監控是構建彈性、高可用IT架構的基礎，云智慧的監控寶、透視寶和壓測寶正好從不同的角度解決這個性能問題，而且SaaS模式也比較適合初創企業，大家可以試試。