做爲 Zabbix 骨灰級粉絲,一直以來對第三方監控(APM)都是拒絕的。一來以爲收費,二來擔憂數據被人所知,三來以爲 Zabbix 牛逼到無可取代。可是,隨着 APM 市場的火爆,我決定「放下身段」試用一次,而且會總結出它與開源監控之間差異在哪裏。php
雖然都在不一樣的公司,作着不一樣的業務,可是大多運維總會經歷相同的故事,以及揹着相似的黑鍋。運維們大多有以下經歷:html
OneAPM 是一家爲企業和開發者提供 APM 解決方案的服務商,支持 Java、.NET、PHP、Ruby、Python、Node.js、HTML五、iOS、Android 等語言和操做系統。前端
既然試用 APM ,我以爲頗有必要給你們解釋一下這個名詞。應用性能管理(Application Performance Management)主要指對企業的關鍵業務應用進行監測、優化,提升企業應用的可靠性和質量,保證用戶獲得良好的服務,下降IT總擁有成本 (TCO) 。使用全業務鏈的敏捷 APM 監控,可以使一個企業的關鍵業務應用的性能更強大,能夠提升競爭力,並取得商業成功,所以,增強應用性能管理(APM)能夠產生巨大商業利益。國內外的 APM 有 Compuware 、 iMaster 、聽雲、New Relic、OneAPM 、AppDynamics 等。 解釋比較幹,若是仍是不瞭解什麼是 APM ,那麼請隨我全面試用 OneAPM 的過程來了解什麼是 APM 。mysql
分別從兩個層面考量,分別爲運維層面與代碼層面linux
共有六項功能,接下來我一一使用,並對它和傳統的開源監控來作比較nginx
Ai(應用監控)面試
可監控 Java、.NET、Node.js、Python、PHP、Ruby 性能,經過探針的方式監控,能夠監控到代碼層面的性能,例如代碼響應時間、吞吐量等等,研發人員經過它能夠快速的定位性能低效代碼redis
Bi(瀏覽器監控)sql
經過Ai方式注入或者流量器中增長js ,js 收集瀏覽網頁用戶的信息,並提交到OneAPM服務器。因而,咱們可以瞭解到真實用戶對網站的瀏覽狀況。例如:白屏時間、首屏時間、腳本錯誤、網頁加載就 緒時間、各類瀏覽器的訪問狀況,甚至能瞭解不一樣瀏覽器、運營商、地區用戶的訪問情況。docker
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、阿里雲,甚至競爭對手監控寶。不知道監控寶該高興呢仍是不高興呢!
由於運維生存時間是 LNMP 環境,因此接下來的內容以 LNMP 爲主,固然儘可能試用更多的業務
其實就是安裝一個 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 。爲此功能點贊!
試用Ai以後,即便它是商業化產品,可是崇拜之心油然而生,畢竟這些功能 Zabbix 、NAGIOS 沒法實現。 Bi , 瀏覽器應用管理,適合門戶、論壇等站點,數據均來自真實用戶,可以最直接的瞭解到站點性能,以及用戶端出現的錯誤。
有三種部署方式
部署 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 解析、創建鏈接、接收數據分別消耗的時間,可是它能爲咱們提供必定的參考。這邊或許能夠作得更好。
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 oneapm-ci-agent root