作為 Zabbix 骨灰級粉絲,一直以來對第三方監控(APM)都是拒絕的。一來覺得收費,二來擔心數據被人所知,三來覺得 Zabbix 牛逼到無可取代。但是,隨着 APM 市場的火爆,我決定「放下身段」試用一次,並且會總結出它與開源監控之間差別在哪里。
運維經歷的磨難
雖然都在不同的公司,做着不同的業務,但是大多運維總會經歷相同的故事,以及背着類似的黑鍋。運維們大多有如下經歷:
- 網站或者業務訪問不了,服務器問題,運維的責任
- 昨天還好好的,今天就出現的問題,運維的責任
- 部分地區用戶反饋網站/App 無法試用,運維查查服務器。而且這種問題大多出現在事后。
- 各種程序都需要監控,常見的 MongoDB 、 Redis 、 Nginx ,還會出現各種不常見的應用。任何一種軟件都要熟悉,運維總是在不停的學習,待遇缺一直比不上研發!
- 服務器出現問題,老板找運維、領導找運維、開發也找運維,運維並不知道代碼邏輯,看日志,各種排錯。
初識 OneAPM
OneAPM 是一家為企業和開發者提供 APM 解決方案的服務商,支持 Java、.NET、PHP、Ruby、Python、Node.js、HTML5、iOS、Android 等語言和操作系統。
什么是 APM ?
既然試用 APM ,我覺得很有必要給大家解釋一下這個名詞。應用性能管理(Application Performance Management)主要指對企業的關鍵業務應用進行監測、優化,提高企業應用的可靠性和質量,保證用戶得到良好的服務,降低IT總擁有成本 (TCO) 。使用全業務鏈的敏捷 APM 監控,可使一個企業的關鍵業務應用的性能更強大,可以提高競爭力,並取得商業成功,因此,加強應用性能管理(APM)可以產生巨大商業利益。國內外的 APM 有 Compuware 、 iMaster 、聽雲、New Relic、OneAPM 、AppDynamics 等。 解釋比較干,如果還是不了解什么是 APM ,那么請隨我全面試用 OneAPM 的過程來了解什么是 APM 。
為什么要使用 OneAPM ?
分別從兩個層面考量,分別為運維層面與代碼層面
- 運維層面 團隊規模小,大多數團隊因為成本問題,都由開發人員兼職,造成了沒有專業運維的一個局面,導致無法做更多的運維層面監控。
- 代碼層面 運維能監控到眾多系統層面甚至業務級別監控,但是代碼級別、終端用戶層面無法監控到。部分 App /程序上線初期因為用戶量較少服務器能夠頂住,但是一旦用戶上來,將會變成亂成一團,最終導致用戶流失。
OneAPM 六個監控大項
共有六項功能,接下來我一一使用,並對它和傳統的開源監控來做比較
可監控 Java、.NET、Node.js、Python、PHP、Ruby 性能,通過探針的方式監控,可以監控到代碼層面的性能,例如代碼響應時間、吞吐量等等,研發人員通過它可以快速的定位性能低效代碼
通過Ai方式注入或者流量器中增加js ,js 收集瀏覽網頁用戶的信息,並提交到OneAPM服務器。於是,我們能夠了解到真實用戶對網站的瀏覽情況。例如:白屏時間、首屏時間、腳本錯誤、網頁加載就 緒時間、各種瀏覽器的訪問情況,甚至能了解不同瀏覽器、運營商、地區用戶的訪問狀況。
Ai、Bi 都比較偏向於開發,Ci則偏向於運維,Ci提供對系統、開源程序(例如:Nginx、PHP、Apache、MySQL、redis 等等)的性能指標管理,而且也提供系統層面的基本監控,例如 CPU 、內存、硬盤,但是功能相對比 Server 模塊弱一點。
與Ai相類似,唯一不同的是它屬於用戶層面軟件管理,真實反饋用戶是用情況,並定位到代碼問題。目前支持 iOS、 Android ,Windows Phone 用戶量畢竟太少
服務器系統級別監控,主要監控CPU、內存、網絡、硬盤等基本信息
OneAlert 的前身是 110 monitor ,偏向於運維,它是監控中最終的一環。 OneAlert 是一個中心,任何告警信息發送至 OneAlert,你可以設置各種規則,例如什么時間點發告警給誰,通過什么發送發送,例如短信、郵箱、微信、app等等。此功能相對獨立,不依托前面幾 個產品。支持多種插件,例如zabbix、NAGIOS、阿里雲,甚至競爭對手監控寶。不知道監控寶該高興呢還是不高興呢!
OneAPM 正式試用
因為運維生存時間是 LNMP 環境,所以接下來的內容以 LNMP 為主,當然盡量試用更多的業務
OneAPM 試用之Ai
其實就是安裝一個 PHP 擴展,而且官方已經列出了傻瓜式的文檔,所以可以知道安裝到底有多簡單了。極力推薦官方改成一鍵安裝方式。
安裝OneAPM PHP Agent
#wget https://user.oneapm.com/account/7e42e138b703a72ae6950531c9ad958a/agent/php/OneAPM_php_Agent_latest.tar.gz tar -xzf OneAPM_php_Agent_latest.tar.gz cd oneapm-php5-linux-install-script ./oneapm-install
在提示輸入「License Key」時,輸入「License Key」
BwQCBwAPDAd5724VHAhDXw9NW04886BbXhgGCAkDTb0f6wBfGwNRTQcE3ca5BgcZBAAVBls=
等待安裝腳本執行。若出現以下信息,則安裝成功。
OneAPM is now installed on your system. Congratulations!
重啟php-fpm
service php-fpm restart
或者你是 Apache ,那么重啟 Apache 就行了,等候幾分鍾,重新進入后台,便可以看到數據。
Ai 總覽
默認顯示最近30分鍾數據。一一看下都有哪些功能及其作用 平均響應時間 分為4個事物, Web 事務、后台任務、數據庫、外部服務,着重了解 Web 與數據庫。
Web 事務響應時間為從接收到請求到放回之間的時間,最高平均值為870多毫秒,這個值可以容忍。好在運維生存時間時間有使用 CDN ,否則絕對都是無法容忍的。
數據庫最大平均響應時間為3.08ms,執行次數16,316次,總時間50.22毫秒。看到這些數據,心里有底了。
Apdex (性能指數)
先來了解下什么是 Apdex 。 Apdex 是一個國際通用標准,是對用戶體驗滿意度的量化值。 服務端 Apdex :當前服務端設定的 Apdex T 值為0.5秒。這意味着響應時間小於0.5秒時,為滿意狀態,介於0.5秒到2秒之間為可容忍狀態,2秒以上為不滿意狀態。 瀏覽器 Apdex :當前瀏覽器設定的 Apdex T值為2秒。 這意味着瀏覽器加載時間在2秒內是滿意狀態,介於2秒到8秒之間為可容忍狀態,8秒以上為不滿意狀態。
吞吐量
每分鍾平均請求量
目前這邊每分鍾平均27.17個請求,上圖圖層顯示的數據為14:50到14:52兩分鍾內平均響應時間328.76ms,執行次數66次。如果吞吐量小,響應時間長,那應該引起足夠的重視,將問題消滅在萌芽期。
Web 事務
一個 http/https 請求從發起到收到響應這個過程,我們稱之為 Web 事務。 有時候網站慢,有時候有正常,運維無法排查到問題。OneAPM 的慢事務追蹤完美解決了這個問題。來找出運維生存時間網站隱藏的問題。
由此,我找到 Uri/wp-login.php 在整個過程相對耗時間,這是一個較少用到的頁面,從上圖可以發現2分鍾內只執行了2次,平均響應時間卻達到995.78毫秒。
點擊如上連接,進入追蹤
在最慢組件中,我們發現函數 filegetcontents 調用了一次,卻執行了9秒時間。我們看看追蹤詳情,來探探究竟。
運維生存時間時間啟用了酷炫的登陸頁面,后台圖片為 bing 的背景。這個文章竟然是通過 filegetcontents 抓取的,得不償失呀!
Web 事務追中不僅僅包含了代碼級別追蹤,其中還有請求參數,SQL 語句。功能酷的不能在庫了。到底是 SQL 有問題還是代碼有問題,OneAPM 都給你展示出來了。
錯誤信息
程序執行過程中可能會少量出現錯誤,因為概率的關系,我們可能無法遇到,有些錯誤致命,有些錯誤無關大小,OneAPM 也就能抓住他們,等着開發人員去消滅。
以上錯誤,在近6小時出現1326次,慶幸它是一個 warning 。為此功能點贊!
OneAPM 試用之 Bi
試用Ai之后,即使它是商業化產品,但是崇拜之心油然而生,畢竟這些功能 Zabbix 、NAGIOS 無法實現。 Bi , 瀏覽器應用管理,適合門戶、論壇等站點,數據均來自真實用戶,能夠最直接的了解到站點性能,以及用戶端出現的錯誤。
有三種部署方式
- 復制/黏貼 js 純文本 輸入應用名稱后,復制生成的代碼,將其粘貼在<head>中。 注意:需要將代碼粘貼在 <meta> 后面,所有 <script> 前面。 優勢:避免加載 js 探針第一個腳本引起的網絡耗時和減少白屏時間。
- 復制/黏貼 js 鏈接 輸入應用名稱后,復制生成的代碼,將其粘貼在<head>中。 注意:需要將代碼粘貼在<meta> 后面,所有 <script> 前面。 優勢:操作簡單,部署方便。
- Ai 自動注入 Bi 探針 由 Ai 探針自動向前端頁面注入 js 代碼,只需簡單配置,無需修改代碼。 優勢:和 Ai 無縫集成,可監控 Web 應用程序在不同區域、不同設備下響應時間,更新 js 探針方便
部署 Bi
使用 js 純文本方式部署,輸入應用名「運維生存時間 WEB」,保存即可獲取到 js ,獲取到的代碼放到網站共用 head 之間。
如果不知道怎么放到 head ,聯系對應的開發人員,他會告訴你。
在測試的前一周,我們已經部署了一個未上 CDN 的小流量站點,先用這個站點看看。
Bi 基本功能
功能分為:受訪頁面、Ajax、腳本錯誤、瀏覽器、地理、運營商。 這部分數據對前端工程師非常重要,白屏時間、首屏時間、網頁就緒時間,OneAPM 統計了每一個 URL 的這些指數的平均時間,從中找出最耗時間的 URL ,對代碼響應的改良。
Apdex 性能指數
此處能非常清晰的表現出當前站點的用戶體驗狀況。如果大於2,那說明網站情況非常糟糕。如上截圖,平均性能指標 Apdex 在0.28,可以容忍,看到這個指數心里相對放心,咱的站點用戶體驗不差。
腳本兼容性之腳本錯誤
公司有個前端工程師安裝了各種瀏覽器,不知道的人還以為他愛好廣泛呢,實際上他僅僅是為了在每種瀏覽器上做兼容性測試。瀏覽器有多家,每一家都有多 個版本, Firefox 都以及42.0了^_^。腳本錯誤在所難免, js 錯誤進一步導致網站部分功能無法使用。 OneAPM 記錄了用戶腳本錯誤信息,簡直就是一個專業用戶自動反饋(以往靠熱心的用戶的反饋,還提供測試,遠程測試那得多消磨時間,而且其他未反饋的用戶就別遺忘 了,被遺忘幾乎等於流失)。
如上信息可以知道哪個頁面出現了哪些腳本錯誤,並且給出了用戶信息、瀏覽器、錯誤信息、堆棧信息等。我想,前端工程師從這里可以解決相當多問題!
頁面跟蹤
某些頁面慢,到底慢在哪里,和 Ai 的 Web 事務一樣,提供了慢事務追蹤。
點擊需要 Trace 的頁面,找到滿加載追蹤,資源為支持的可以 Trace
時間都在DOM
只列出了部分資源時序,底下還有更多,類似 firebug 的「網絡」,顯示各個資源加載所消耗的時間。但是功能略顯不足,未顯示每個資源 DNS 解析、建立連接、接收數據分別消耗的時間,但是它能為我們提供一定的參考。這邊或許可以做得更好。
OneAPM 試用之 Ci
Ci 平台監控,具體干嘛的,我上一張圖你就明白了。
用戶只需在服務器安裝 OneAPM Ci Agent,配置需要監控應用的配置文件即可。
部署OneAPM Ci Agent
點擊設置添加平台,如下圖
復制 shell 命令,在 Linux 中運行即可。
平台添加完畢之后,過幾分鍾就能看到信息
剛配置完畢,平台服務列只有 System 。 System 為服務器基本信息,例如 CPU、內存、硬盤、網絡等。如下圖
效果與剛安裝完 Zabbix 一樣,但是安裝更簡單,UI 更漂亮。
添加平台服務
有各種各樣的程序需要做性能管理,例如 Nginx 、 MySQL 、 PHP 、tomcat 等
LNMP 環境部署
所有的配置文件均在 /etc/oneapm-ci-agent/conf.d/ ,支持被監控的軟件都有配置文件 sample
配置文件如下
ll /etc/oneapm-ci-agent/conf.d/
-rw-r--r-- 1 oneapm-ci-agent root 2630 Sep 6 22:41 activemq_58.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 2619 Sep 6 22:41 activemq.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 232 Sep 6 22:41 apache.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 2372 Sep 6 22:41 cassandra.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 250 Sep 6 22:41 couchbase.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 916 Sep 6 22:41 couch.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 2408 Sep 6 22:41 docker.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 2385 Sep 6 22:41 elastic.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 1550 Sep 6 22:41 jmx.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 338 Sep 6 22:41 kafka_consumer.yaml.example -rw-r--r-- 1