Bitly 運維團隊的 10 個監控教訓

慕容老匹夫發表於2014-03-25

bit.ly 是一個全球知名的短網址服務商,為網民提供網址和連結縮短服務。Bitly 公司2008年成立於紐約。據說 bitly  每月縮短超過10億個網址用於社交網路分享傳播。2009年5月6日 bit.ly 一度成為 Twitter 預設的短網址,後來被 Twitter 自家的 t.co 取代。今年年初 bitly 運維團隊官方技術部落格發了一篇文章,分享了他們的一些經驗教訓。以下是全文。

我們總是會監控很多指標(比如硬碟利用率、記憶體利用率、負載、ping等等)。除了這些,我們還從運營自家產品系統的過程中吸取了很多經驗教訓,這些經驗教訓幫助我們擴充了在bitly的監控範圍。

下面是我最喜歡的推特之一,來自@DevOps_Borat

開發者的墨菲定律:如果一件事情可能會出現錯誤,那麼這就意味著它已經出錯了,只不過你還沒有發現罷了。

下面是一個我們運營bitly時的監控清單,這些例子的背後故事,有時甚至可以稱為痛苦的經歷,幫助了bitly的成長。

1.叉率 | Fork Rate

我們曾經遇到過這樣一個問題:通過設定options ipv6 disable=1和在/etc/modprobe.conf中的alias ipv6 off,將一臺伺服器的IPv6關閉。不過這可給我們找了一個大麻煩:每次建立一個新的curl物件,modprobe都會被呼叫,並通過檢查net-pf-10來確定IPv6的狀態。這可給伺服器帶來了很大的負擔,最終我們發現了/proc/stat下的程式計數器會以每秒數以百計的速度增長,進而發現了上面說到的那些現象的原因。通常你會希望在一臺流量穩定的機器上的叉率保持在1-10/s。

2.流控制包

參考資料。如果你的網路設定中包括流控制包,並且你沒有設定禁止它們,那麼它們有時可能會引起流量丟失。(如果你覺得這聽起來還不夠嚴重,那你也許該檢查下你的腦袋裡都裝了些什麼了)。

注:閱讀這個來更加詳細的瞭解當你使用某些博通網路卡時,這些流控制幀是如何和連結的損耗聯絡在一起的。

3.交換輸入/輸出速率

人們通常會檢查超過某一閾值的交換使用率。不過即便你僅僅只有一小部分記憶體被交換,實際上影響效能的卻是交換輸入/輸出的速率,而不是數量。檢查交換輸入/輸出速率會更直觀。

4.伺服器啟動通知

意外的重啟是生活的一部分。你知道你的伺服器何時重啟了嗎?很多人都不知道。這裡我們會使用一個當系統重啟時會傳送郵件通知的簡單的初始化指令碼。當新增新伺服器的時候,這會很有用。同時,當伺服器出現異常時,能優雅的使人瞭解伺服器狀態的變化,而不是隻提供一個報警。

5.NTP的時鐘偏移

如果這貨不被檢測,是的,你的某臺伺服器也許已經掛了。如果你從未考慮過時鐘偏離,那麼你甚至可能沒有在你的伺服器上跑過ntpd命令。通常來說,有三點可以作為檢查的切入點。1)ntpd是否在執行。2)你的資料中心內的時鐘脈衝相位差。3)你的主時間伺服器和外部之間的時鐘脈衝相位差。

我們使用check_ntp_time來做這個檢查。

6.DNS決議

內部DNS-這是一個你會依賴卻常被忽略掉的、你的構架的隱藏部分。檢查它的切入點如下:

  • 1)每個伺服器的本地決議。
  • 2)如果你的資料中心有本地DNS伺服器,那麼你應該檢查決議,和查詢的數量。
  • 3)檢查你用的每個上行DNS解析器是否可用。

外部DNS-最好能核實你的外部域名解析能正確的和你已經發布的外部域名伺服器對應上。在bitly我們也依靠一些CC頂級域名,而且我們也直接監測這些認證伺服器。(是的,這發生在所有的頂級域名伺服器離線的時候。)

7.SSL過期

因為這種情況發生的如此之少,以至於很多人都忘記了它。修復很簡單,試試更新一下SSL證照吧。

8.DELL伺服器管理器(OMSA)

我們將bitly分別部署在兩個資料中心,一個在DELL的裝置上,另一個是亞馬遜EC2。對於我們的DELL裝置而言,監測OMSA的輸出是十分重要的。它會讓我們留意磁碟陣列的狀態,壞掉的磁碟(可預見性的硬體故障),記憶體問題,能源供應狀態等等。

9.連線限制

你可能在連線限制的情況下執行過例如memcached和mysql這樣的東西,但是當你向外擴充套件應用程式層的時候,你真的監測過你離那些限制到底有多接近嗎?

與此相關的是解決遇到檔案修飾符限制的程式的問題。在實際操作中,我們經常在啟動指令碼中加入ulimit -n 65535來啟動服務以最小化連線限制帶來的影響。我們也可以通過 worker_rlimit_nofile來設定Nginx。

10.負載均衡器的狀態

我們可以設定負載均衡器的健康檢查(health check),這樣我們就可以輕鬆的將某臺伺服器從輪轉中剔除。(假設一個伺服器掛掉了,負載均衡器將會探測到同時停止向這臺伺服器傳送資訊—譯者注)我們發現健康檢查的視覺化十分重要,於是我們基於相同的健康檢查來監控、報警。(如果你使用EC2負載均衡器,你可以通過亞馬遜的API來監測ELB的狀態)

一些碎碎念(這些東西也要監測)

Nginx錯誤日誌,服務重啟(假設遇到錯誤時,會重啟),numa統計,新程式核心轉儲。

結語

以上僅僅是我們保證bitly穩定運營的一些皮毛,如果打動了你,那麼請戳

相關文章