迅遊科技：遊戲監控實踐分享

趙亞南，7年運維實踐經驗，早期主要負責過淘寶網淘江湖、浙江日報、銀率網(北京)、廣州寶潔、機電之家等網站的維護，2012年後加入重慶迅遊，負責開服網、開區網及多個遊戲項目的運維，務真求實，追求以公司項目實際狀況出發，權衡成本、效率、安全和穩定，推進團隊向最合理的方向發展。

遊戲玩家對遊戲體驗的要求是最苛刻的，任何因爲服務器、數據庫性能瓶頸、網絡CDN形成的卡頓、崩潰都會影響遊戲體驗，並有可能形成玩家的流失和支付的減小，所以如何確保各地玩家在遊戲過程當中得到最佳用戶體驗，第一時間發現系統、應用、網絡故障並予以解決，是遊戲公司對運維部門的基本要求。

重慶迅遊科技成立於2009年，目前團隊規模不到200人。自主運營開服網等資訊網站，自主研發端遊《傳奇正傳》、頁遊《開天戰神》、手遊《滿貫遊戲》等產品，有專業的研發技術團隊，是一家技術導向的公司，和兄弟公司小閒在線強強聯手，在重慶遊戲產業內頗具影響力！下面是迅遊運維部門負責人趙亞南在雲智慧［監控與性能優化］微信羣分享的遊戲監控經驗。

你們好，我是趙亞南，來自重慶迅遊科技，今天分享一些遊戲監控的實踐經驗，謝謝你們棒場。我我的在運維崗工做了7年，主要歷程在前面都有介紹，2012年後加入重慶迅遊，經驗也從這裏開始分享吧。

重慶迅遊的監控選擇
監控的工具和方式太多，相信你們都能列舉出不少，但永遠是適合自已的纔是最好的。由於遊戲行業的業務需求，運維工做須要在監控上作到最好，不然就會直接影響公司收入。
常常會有人講： 「運維就是主動發現問題，變被動爲主動」，說得在理，但其實是作不到100%主動的，這時候完善的監控體系就能幫助咱們更好地發現問題，定位問題。監控作得好很差，就很重要了。

要用好的監控工具，並且不光要會用，還要去深刻研究、測試、驗證，規劃好，作好自動化設置，監控配置合理，報警效率高，發送給該發送的人，不緊要的就發郵件，緊要的那就發郵件和短信，甚至電話同時報警，不應報的不要報，不應發送的人不要發送。

很囉嗦吧。是啊，要作到這些，是要花不少時間和精力的，尤爲是業務變更頻繁，變更量大時，不但要承擔業務的設備、服務等資源的調整，監控項、閾值也要按需調整，你敢保證此次調整的就必定合理嗎？那過兩天極可能須要再調整。

廢話真多，直接說下咱們是怎麼作的吧。（咱們就作得完美嗎？也難講）
最初迅遊採用的是雲智慧監控寶，用了不少年。後來監控需求愈來愈多，就寫腳本監控，不過比較分散，管理不方便，因而把Zabbix也加進來。Zabbix優勢包括靈活、穩定、有效、性能好、功能強大，最大的問題是幫助文件全英文，並且功能複雜，就是全翻譯成中文看着也頭大，因業務變更頻繁，變更量大，只好一邊用一邊摸索，有特別需求時，去找官方文檔相關的部分，或百度搜一下，下面說說整體思路。

Zabbix的實踐經驗粗談
【模板】
首先，監控這麼龐大的量，一個一個去添加？不可能！因此創建模版很重要，並且模版只有一套也不行，咱們的服務器類型、配置，所在運營商不少，項目也多，創建多套模版頗有必要，甚至有時須要子模板。不要小看這個思路，這和各種軟件架構的構成也是一脈相承的，有共性的監控項，可以使用同一套模版，按需關聯便可。
這樣，批量調整成爲可能。好比調某個閾值，至少不用一臺一臺去改了吧。個別主機有少許不一樣的地方，好比它的磁盤就只有50GB，CPU核就1個，或者它的帶寬高達500Mbps，模板不適用了，單獨作模板不太好，就把由模板關聯進來的相關觸發器停用，克隆一個，重調閾值便可。
【主機】
接着說主機的添加，主機按項目或運營商，進行交叉分組，方便查找。主機的命名很是講究，直接和「動做」（觸發報警後發送給那些人）有關係，根據關鍵字關聯，同一項目的主機（設備）使用同一關鍵字打頭。
爲何puppet裏面建議的主機名那麼長，由於那才能準確的描述一臺主機，它的IP、機房、用途、服務、功能，都是可能隨業務而變化，每一個公司有不一樣的狀況。
【觸發器】
觸發器的名稱包含主機名稱便可，在模版中統一配置，就不用單獨去想它怎麼命名了。
【動做】
即把哪些報警發送到哪兒，根據問題的嚴重性，匹配名稱，發送給對應的項目組運維崗的郵箱或短信，或電話告警。
例如迅遊網站項目的動做截圖：

另外，把{ITEM.VALUE}包含到警報信息中，在非工做時間收到報警，具體監控值也許對你有幫助。
【用戶和用戶組】
動做只把告警發給用戶組，咱們用戶組按項目創建，用戶添加到組中，方便批量管理。
【示警媒介】
咱們有自編腳本，自建郵件系統，觸發告警發郵件，爲何自建郵件系統呢，由於第三方郵件系統大多有限制，還不便宜。固然你的量真的不多，就不要緊了。
重要告警，結合飛信、微信、139郵箱，189郵箱，聯通的wo郵箱，發送告警信息。喜歡手機長期連網的同事，直接經過互聯網接收公司郵箱的告警也行。這裏說個細節，最好尊重每一個人的習慣、選擇，人性化一點嘛。在非上班時間接收告警和要求應急響應的必須是比較嚴重的問題，畢竟是對人傢俬人時間的侵佔。嚴重故障，能夠經過監控寶等第三方告警平臺觸發電話告警，這種狀況一般還會發給領導。
【自動發現（或着叫探索）】
某些監控能夠作成自動發現，好比某些主機的進程，重要端口，其監控量和維護量十分龐大，咱們的估約有幾千項的，因此按json格式自動生成，增減自動完成（shell或python實現）。Zabbix服務端作個模版，配置自動發現，有須要的主機關聯下模版便可，監控內容也自動增刪，觸發閾值統一配置，全程高度自動化。
【重要的業務監控】
舉例一：好比網站，從玩家發起請求到最終成功響應正確內容，期間要通過DNS、邊緣節點、父層節點、前端nginx服務、php服務、haproxy、mysql，咱們就作一個鏈接數據庫並查詢必要字串的php程序，Zabbix原本就能夠部署在異地的，這樣由Zabbix開始，經過公網解析後，從邊緣節點監控起，獲取到查詢的正確字符串，而且響應時間不長，完成這一連串監控，哪一層有問題，報警都不會恢復。
舉例二：模擬網站登錄過程，網站功能那麼多，能監控到的老是有限。咱們就監控常常有問題的、重要的地方，網站登錄過程常常出問題，好，咱們結合監控寶分佈式監測網絡控件，在異地自動模擬登錄過程。
舉例三：太多監控都是從運維角度去發起的，只關注基礎設施的運行情況。你們是否是遇到過這樣的場景，就是咱們全部監控都沒有發現問題，但業務部門反饋在線用戶量就是降低了。最後查出來還真是運維的問題，沒有監控到業務層的運行情況。若是你能主動監控公司業務的情況，並在發現問題的第一時間向業務部門反饋，如今在線量降低了，注意一下，也許同時我們就發現問題了並解決了，或者即便沒解決業務部分對運維的印象仍是好的。因此能監控到業務數據就最好，幸虧迅遊的在線人數寫在了數據庫中，直接取出來，配置觸發器，還作成圖，有異常，很容易發現。好比某臺DB的監控：

【總覽圖】
想一眼就直觀的看到想關注的監控項目嗎？這是由Zabbix的篩選和總覽來實現的，其中總覽能夠按主機來查看，固然也不用一個一個去添，在主機模版中配置好篩選便可。篩選就是比較靈活的了，和監控寶的視圖相似，能夠組織任意你想觀察的圖表在一個界面中來。

【各種應用監控】
Zabbix監控很容易擴展，默認的若是沒有能夠去網上找模板，或者自主編寫監控腳本，咱們找了些模板，也自主編寫或完善了一些，如nginx,memcache,redis,mysql,varnish，想關注的可用性或性能趨勢，都作了上去。但說實話，若是業務量不大的話這些真沒多少用，可是業務量很大的時候，這些應用服務就有出現性能瓶頸的可能，或者出錯率上升，運維必須進行關注，作到心中有數。

領導都喜歡看圖表，因此咱們使用了大屏展現Zabbix的數據，Grafana能夠從Zabbix中取數據，定製靈活，圖形展現很是好，可作大屏展現，一目瞭然，它的正則很好用，但有個缺點就是查詢時間跨度太大，甚至超過半個月，就會形成Zabbix數據庫極大的壓力，因此開放給非運維崗的同事查詢太不明智了，看看結果就好了。

監控寶的實踐經驗粗談
Zabbix主要用於基礎設施和應用層的可用性監控，但Zabbix的分佈式監控仍是比較弱的，而且即便好用，其成本投入也很大。因此網絡層的監控就要靠監控寶了，監控寶的監控點在國內、國外處處都有，若是有部分服務器或用戶在境外，那監控寶更是值得推薦的第三方監控服務了，因此接下來聊聊監控寶。

若是要關心特定地區的網絡狀況，監控寶是很容易作到的，這個功能很是好：

若是有不少邊緣節點，又不肯花錢買更多的監控寶「網站監控項」服務，那就針對分佈式監測點設置爲1~2個，幾乎就能監控到各個邊緣節點了。若是設置了好幾個，並且都報警了，業務部門問起來，你就有分析參考的依據了，和同運營商的其它監控以及不一樣運營商的監控一對比，就能明白髮生什麼事兒了，若是骨幹網的事，也許能夠提早鬆口氣說：「還好不是個人事兒」。
固然這只是監控寶最具價值的功能之一，短信告警、電話語音告警、用戶體驗監控都是其核心功能，此外若是大量使用了API，那麼監控寶API監控一樣是不能錯過的，這些也是其它監控服務商或自建監控平臺難以替代的，這是老實話。

有的人還在提各類免費監控，確實免費監控很長一段時間好像還能夠用，但從企業業務需求的角度出發，過去兩年的經驗告訴我們，免費的可靠性確實不高。對於不想在監控方面投入太多人力物力，或者技術能力達不到使用Zabbix的，或者監控量不大的，均可以考慮監控寶，省事還好用。

最後分享一個案例
我們舉個在監控寶上使用的案例，咱們購買了2個監控寶帳號，按業務需求須要對重點區域和重要運營商的可用性、網絡質量進行監控，因此我們建了多個監測點：

每一個監測點均精心選擇，兩個帳號選的監測點互不相同，覆蓋重點區域和重要運營商。監控服務目前主要以「網站監控」爲主，每一個監測項均精巧配置，均有不一樣意義，避免重複配置：

全國CDN節點那麼多，咱們是這樣監控的：

全國CDN監控，我們就在兩個帳號分別配置了一個任意點延時就告警。有的人要問了，10秒延時才告警是否是太慢了？是的，但這是有效監控的追求，而且網頁加載過程當中已經不影響訪客瀏覽了，而監控寶必定要等他加載完啊，這是人機的區別。

如今監控寶綁定的告警郵箱只有一個，我們就使用一個公共郵箱，全部的人都能收到。若是您的監控要分類發送到不一樣的接收人，那能夠考慮監控寶的企業版服務，比你自已去研究Zabbix來得可靠，節省時間和精力，專一於業務。

固然也有一些偏方，好比郵件過濾轉發，foxmail過濾轉發，這個過程增長了告警成功的依賴，其可靠性理論上確定要低一些。
謝謝你們，分享結束。

問： Zabbix和監控寶有沒有業務衝突，你兩個都有用？
答：基本上沒有衝突，只在最最重要的業務監控上，作了重複監控。

問：遊戲產品的監控有沒有特別須要注意的監控點？他們的監控閾值能否給咱們一個參考。
答：遊戲產品的監控，仍是應該根據每款遊戲的特色來。一些基礎項目包括遊戲登錄服是否存活，遊戲服務端各重要端口，是否在正常偵聽，數據庫及其所在服務器各項性能（和網站數據庫同樣的監控了）。一般還有平臺，最好配備這兩項監控：機器人模擬登錄遊戲，模擬一個重要操做，和真實玩家的操做流程越接近越好。

此外要關注平臺各項數據是否有大的波動，好比在線玩家，是否有忽然掉線、人數大減，若是其它指標都沒變就人數變了，確定須要人工去處理了。另外充值數據也是一個重要監控項，常常是什麼都好的，就有幾個小時沒有進帳了，直到早上有玩家反饋。一般充值過程很複雜的，涉及到第三方支付接口，因此必須監控到它的一連串服務是否正常，這就能夠用到監控寶API事務流監控。