[APM] OneAPM 雲監控部署與試用體驗

摘要: 做爲 Zabbix 骨灰級粉絲,一直以來對第三方監控(APM)都是拒絕的。一來以爲收費,二來擔憂數據被人所知,三來以爲 Zabbix 牛逼到無可取代。可是,隨着 APM 市場的火爆,我決定「放下身段」試用一次,而且會總結出它與開源監控之間差異在哪裏。

做爲 Zabbix 骨灰級粉絲,一直以來對第三方監控(APM)都是拒絕的。一來以爲收費,二來擔憂數據被人所知,三來以爲 Zabbix 牛逼到無可取代。可是,隨着 APM 市場的火爆,我決定「放下身段」試用一次,而且會總結出它與開源監控之間差異在哪裏。php

運維經歷的磨難

雖然都在不一樣的公司,作着不一樣的業務,可是大多運維總會經歷相同的故事,以及揹着相似的黑鍋。運維們大多有以下經歷:html

  • 網站或者業務訪問不了,服務器問題,運維的責任
  • 昨天還好好的,今天就出現的問題,運維的責任
  • 部分地區用戶反饋網站/App 沒法試用,運維查查服務器。並且這種問題大多出如今過後。
  • 各類程序都須要監控,常見的 MongoDB 、 Redis 、 Nginx ,還會出現各類不常見的應用。任何一種軟件都要熟悉,運維老是在不停的學習,待遇缺一直比不上研發!
  • 服務器出現問題,老闆找運維、領導找運維、開發也找運維,運維並不知道代碼邏輯,看日誌,各類排錯。

初識 OneAPM

OneAPM 是一家爲企業和開發者提供 APM 解決方案的服務商,支持 Java、.NET、PHP、Ruby、Python、Node.js、HTML五、iOS、Android 等語言和操做系統。前端

什麼是 APM ?

既然試用 APM ,我以爲頗有必要給你們解釋一下這個名詞。應用性能管理(Application Performance Management)主要指對企業的關鍵業務應用進行監測、優化,提升企業應用的可靠性和質量,保證用戶獲得良好的服務,下降IT總擁有成本 (TCO) 。使用全業務鏈的敏捷 APM 監控,可以使一個企業的關鍵業務應用的性能更強大,能夠提升競爭力,並取得商業成功,所以,增強應用性能管理(APM)能夠產生巨大商業利益。國內外的 APM 有 Compuware 、 iMaster 、聽雲、New Relic、OneAPM 、AppDynamics 等。 解釋比較幹,若是仍是不瞭解什麼是 APM ,那麼請隨我全面試用 OneAPM 的過程來了解什麼是 APM 。mysql

爲何要使用 OneAPM ?

分別從兩個層面考量,分別爲運維層面與代碼層面linux

  • 運維層面 團隊規模小,大多數團隊由於成本問題,都由開發人員兼職,形成了沒有專業運維的一個局面,致使沒法作更多的運維層面監控。
  • 代碼層面 運維能監控到衆多系統層面甚至業務級別監控,可是代碼級別、終端用戶層面沒法監控到。部分 App /程序上線初期由於用戶量較少服務器可以頂住,可是一旦用戶上來,將會變成亂成一團,最終致使用戶流失。

OneAPM 六個監控大項

共有六項功能,接下來我一一使用,並對它和傳統的開源監控來作比較nginx

Ai(應用監控面試

可監控 Java、.NET、Node.js、Python、PHP、Ruby 性能,經過探針的方式監控,能夠監控到代碼層面的性能,例如代碼響應時間、吞吐量等等,研發人員經過它能夠快速的定位性能低效代碼redis

Bi(瀏覽器監控)sql

經過Ai方式注入或者流量器中增長js ,js 收集瀏覽網頁用戶的信息,並提交到OneAPM服務器。因而,咱們可以瞭解到真實用戶對網站的瀏覽狀況。例如:白屏時間、首屏時間、腳本錯誤、網頁加載就 緒時間、各類瀏覽器的訪問狀況,甚至能瞭解不一樣瀏覽器、運營商、地區用戶的訪問情況。docker

Ci(平臺監控)

Ai、Bi 都比較偏向於開發,Ci則偏向於運維,Ci提供對系統、開源程序(例如:Nginx、PHP、Apache、MySQL、redis 等等)的性能指標管理,並且也提供系統層面的基本監控,例如 CPU 、內存、硬盤,可是功能相對比 Server 模塊弱一點。

Mi(移動應用)

與Ai相相似,惟一不一樣的是它屬於用戶層面軟件管理,真實反饋用戶是用狀況,並定位到代碼問題。目前支持 iOS、 Android ,Windows Phone 用戶量畢竟太少

Servers(系統監控)

服務器系統級別監控,主要監控CPU、內存、網絡、硬盤等基本信息

告警(OneAlert)

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 就好了,等候幾分鐘,從新進入後臺,即可以看到數據。

Cloudwatch1

Ai 總覽

Cloudwatch2

默認顯示最近30分鐘數據。一一看下都有哪些功能及其做用 平均響應時間 分爲4個事物, Web 事務、後臺任務、數據庫、外部服務,着重瞭解 Web 與數據庫。

Cloudwatch3

Web 事務響應時間爲從接收到請求到放回之間的時間,最高平均值爲870多毫秒,這個值能夠容忍。好在運維生存時間時間有使用 CDN ,不然絕對都是沒法容忍的。

Cloudwatch4

數據庫最大平均響應時間爲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秒以上爲不滿意狀態。

Cloudwatch5

吞吐量

每分鐘平均請求量

Cloudwatch6

目前這邊每分鐘平均27.17個請求,上圖圖層顯示的數據爲14:50到14:52兩分鐘內平均響應時間328.76ms,執行次數66次。若是吞吐量小,響應時間長,那應該引發足夠的重視,將問題消滅在萌芽期。

Web 事務

一個 http/https 請求從發起到收到響應這個過程,咱們稱之爲 Web 事務。 有時候網站慢,有時候有正常,運維沒法排查到問題。OneAPM 的慢事務追蹤完美解決了這個問題。來找出運維生存時間網站隱藏的問題。

Cloudwatch7

由此,我找到 Uri/wp-login.php 在整個過程相對耗時間,這是一個較少用到的頁面,從上圖能夠發現2分鐘內只執行了2次,平均響應時間卻達到995.78毫秒。

Cloudwatch8

點擊如上鍊接,進入追蹤

Cloudwatch9

在最慢組件中,咱們發現函數 filegetcontents 調用了一次,卻執行了9秒時間。咱們看看追蹤詳情,來探探究竟。 Cloudwatch10

運維生存時間時間啓用了酷炫的登錄頁面,後臺圖片爲 bing 的背景。這個文章居然是經過 filegetcontents 抓取的,得不償失呀!

Web 事務追中不只僅包含了代碼級別追蹤,其中還有請求參數,SQL 語句。功能酷的不能在庫了。究竟是 SQL 有問題仍是代碼有問題,OneAPM 都給你展現出來了。

Cloudwatch11

錯誤信息

程序執行過程當中可能會少許出現錯誤,由於機率的關係,咱們可能沒法遇到,有些錯誤致命,有些錯誤無關大小,OneAPM 也就能抓住他們,等着開發人員去消滅。

Cloudwatch12

以上錯誤,在近6小時出現1326次,慶幸它是一個 warning 。爲此功能點贊!

OneAPM 試用之 Bi

試用Ai以後,即便它是商業化產品,可是崇拜之心油然而生,畢竟這些功能 Zabbix 、NAGIOS 沒法實現。 Bi , 瀏覽器應用管理,適合門戶、論壇等站點,數據均來自真實用戶,可以最直接的瞭解到站點性能,以及用戶端出現的錯誤。

Cloudwatch13

有三種部署方式

  • 複製/黏貼 js 純文本 輸入應用名稱後,複製生成的代碼,將其粘貼在<head>中。 注意:須要將代碼粘貼在 <meta> 後面,全部 <script> 前面。 優點:避免加載 js 探針第一個腳本引發的網絡耗時和減小白屏時間。
  • 複製/黏貼 js 連接 輸入應用名稱後,複製生成的代碼,將其粘貼在<head>中。 注意:須要將代碼粘貼在<meta> 後面,全部 <script> 前面。 優點:操做簡單,部署方便。
  • Ai 自動注入 Bi 探針 由 Ai 探針自動向前端頁面注入 js 代碼,只需簡單配置,無需修改代碼。 優點:和 Ai 無縫集成,可監控 Web 應用程序在不一樣區域、不一樣設備下響應時間,更新 js 探針方便

部署 Bi

使用 js 純文本方式部署,輸入應用名「運維生存時間 WEB」,保存便可獲取到 js ,獲取到的代碼放到網站共用 head 之間。

Cloudwatch14

Cloudwatch15

若是不知道怎麼放到 head ,聯繫對應的開發人員,他會告訴你。

Cloudwatch16

在測試的前一週,咱們已經部署了一個未上 CDN 的小流量站點,先用這個站點看看。

Bi 基本功能

功能分爲:受訪頁面、Ajax、腳本錯誤、瀏覽器、地理、運營商。 這部分數據對前端工程師很是重要,白屏時間、首屏時間、網頁就緒時間,OneAPM 統計了每個 URL 的這些指數的平均時間,從中找出最耗時間的 URL ,對代碼響應的改良。

Cloudwatch17

Apdex 性能指數

此處能很是清晰的表現出當前站點的用戶體驗情況。若是大於2,那說明網站狀況很是糟糕。如上截圖,平均性能指標 Apdex 在0.28,能夠容忍,看到這個指數內心相對放心,咱的站點用戶體驗不差。

腳本兼容性之腳本錯誤

公司有個前端工程師安裝了各類瀏覽器,不知道的人還覺得他愛好普遍呢,實際上他僅僅是爲了在每種瀏覽器上作兼容性測試。瀏覽器有多家,每一家都有多 個版本, Firefox 都以及42.0了^_^。腳本錯誤在所不免, js 錯誤進一步致使網站部分功能沒法使用。 OneAPM 記錄了用戶腳本錯誤信息,簡直就是一個專業用戶自動反饋(以往靠熱心的用戶的反饋,還提供測試,遠程測試那得多消磨時間,並且其餘未反饋的用戶就別遺忘 了,被遺忘幾乎等於流失)。 Cloudwatch18

Cloudwatch19

Cloudwatch20

Cloudwatch21

如上信息能夠知道哪一個頁面出現了哪些腳本錯誤,而且給出了用戶信息、瀏覽器、錯誤信息、堆棧信息等。我想,前端工程師從這裏能夠解決至關多問題!

頁面跟蹤

某些頁面慢,到底慢在哪裏,和 Ai 的 Web 事務同樣,提供了慢事務追蹤。

Cloudwatch22

點擊須要 Trace 的頁面,找到滿加載追蹤,資源爲支持的能夠 Trace

Cloudwatch23

Cloudwatch24

時間都在DOM

Cloudwatch25

只列出了部分資源時序,底下還有更多,相似 firebug 的「網絡」,顯示各個資源加載所消耗的時間。可是功能略顯不足,未顯示每一個資源 DNS 解析、創建鏈接、接收數據分別消耗的時間,可是它能爲咱們提供必定的參考。這邊或許能夠作得更好。

OneAPM 試用之 Ci

Ci 平臺監控,具體幹嗎的,我上一張圖你就明白了。

Cloudwatch26

用戶只需在服務器安裝 OneAPM Ci Agent,配置須要監控應用的配置文件便可。

部署OneAPM Ci Agent

點擊設置添加平臺,以下圖

Cloudwatch27

複製 shell 命令,在 Linux 中運行便可。

平臺添加完畢以後,過幾分鐘就能看到信息

Cloudwatch28

剛配置完畢,平臺服務列只有 System 。 System 爲服務器基本信息,例如 CPU、內存、硬盤、網絡等。以下圖

Cloudwatch29

效果與剛安裝完 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 5957 Sep 6 22:41 kafka.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 245 Sep 6 22:41 mcache.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 872 Sep 6 22:41 mongo.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 917 Sep 6 22:41 mysql.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 627 Sep 6 22:41 nginx.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 952 Sep 6 22:41 php_fpm.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 1787 Sep 6 22:41 postgres.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 1645 Sep 6 22:41 rabbitmq.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 1116 Sep 6 22:41 redisdb.yaml.example -rw-r--r-- 1 oneapm-ci-agent root 2760 Sep 6 22:41 tomcat.yaml.example

部署 nginx

部署 nginx status

請看以前的文章:http://www.ttlsa.com/nginx/nginx-status-detail/

status地址:http://localhost/status

編輯 nginx 配置

# cat nginx.yaml init_config: instances: - nginx_status_url: http://localhost/ngx_status tags: tag_key:tag_value`

重啓OneAPM-C

# /etc/init.d/oneapm-ci-agent restart Stopping OneAPM CI Agent (using killproc on supervisord): [ OK ] Starting OneAPM CI Agent (using supervisord): [ OK ]

驗證 php-fpm運行狀態

# /etc/init.d/oneapm-ci-agent info

若是看到以下信息,說明 php-fpm 監控配置成功,登錄 OneAPM,等候幾分鐘,Ci中會有數據展現

Checks
====== php_fpm ------- - instance #0 [OK] - Collected 7 metrics, 0 events & 2 service checks`

Nginx 性能數據

Cloudwatch30

修改配置文件,重啓 Agent 便可獲取到 nginx,很是簡答!

部署 MySQL

部署方法基本類型,只須要修改 mysql.yaml 便可

# cat mysql.yaml instances: - server: localhost user: oneapm pass: '123456'`

配置數據權限

# mysql -e "CREATE USER 'oneapm'@'localhost' IDENTIFIED BY 123456;" # mysql -e "GRANT REPLICATION CLIENT ON *.* TO 'oneapm'@'localhost' WITH MAX_USER_CONNECTIONS 5;"

重啓 Agent

# /etc/init.d/oneapm-ci-agent restart`

驗證配置

# /etc/init.d/oneapm-ci-agent restart
Checks
====== [...] mysql ----- - instance #0 [OK] - Collected 8 metrics & 0 events`

備註:密碼若是是數字,必定記得加上單引號,不然會出現錯誤。這算一個小 BUG,但願 OneAPM 能將它先轉爲字符串。

MySQL 性能數據

Cloudwatch31

固然,這邊只顯示部分12個性能指標,你能夠點擊「加載更多」顯示更多,或者前往 MySQL 儀表盤。

Nginx 部署

配置方法都同樣,只是配置文件不一樣,我列出個人配置文件以及監控圖

配置文件 nginx.yaml

# cat nginx.yaml init_config: instances: - nginx_status_url: http://localhost/ngx_status tags: -tag_key:tag_value`

性能數據

Cloudwatch32

到這裏咱們能夠發現 Ci 監控與 Zabbix 部分功能是同樣的

OneAPM 有以下優點

  • 部署簡單,沒有太多複雜配置
  • Ui 美觀大方
  • 圖片數據能更詳細的顯示,而 Zabbix 僅僅是一張圖

Zabbix 優點

  • 開源免費
  • 自定義功能強

OneAPM 試用之 Mi

功能與 Ai 相似,可實現代碼級別管理

OneAPM 試用之 Server

Server 監控與平臺監控中的平臺服務「system」部分重疊,若是你不想監控太多關於系統層面的數據(cpu、內存、io之類),那麼安裝OneAPM Ci Agent便可。反之,裝OneAPM Servers吧!

部署 OneAPM Servers

# wget https://user.oneapm.com/account/7e42e138b703a72ae6950531c9ad958a/agent/server/OneAPM_server_Age nt_latest.tar.gz # tar –xzvf OneAPM_server_Agent_latest.tar.gz # cd oneapm-sysmond-linux-install-script/ # ./oasysmond-install OneAPM Server Monitor Installation (interactive mode) ============================================ Please select from one of the following options: 1) Install OneAPM Server Monitor 2) Uninstall OneAPM Server Monitor 3) Upgrade OneAPM Server Monitor 0) Exit Enter choice (1-3, 0 to exit): 1

根據提示,輸入你的 key 便可。 運行 OneAPM Servers

# oasysmond

數據展現 啓動以後,登錄 OneAPM 後臺,進入 Server 監控,稍等幾分鐘即可以查看數據。我添加了兩臺服務器,數據以下

Cloudwatch33

一個服務器列表,顯示了最基礎的 CPU\ 內存、內存、磁盤信息。點擊主機名,查看更多數據。咱們能夠看到四個菜單:總覽、磁盤、網絡、進程。

相比其餘功能, Server 監控沒有給我太大的驚喜,畢竟功能和 zabbix 相相似。不過站在非專業運維角度出發,這絕對是個被須要產品。分別列出一些性能指數

Cloudwatch34

Cloudwatch35

Cloudwatch36

Cloudwatch37

Cloudwatch38

Cloudwatch39

Cloudwatch40

Cloudwatch41

千萬不要小看這些基本數據,他能給服務器是否須要擴容升級提供一個依據,歷史數據也更容易協助解決一些存在故障!

OneAPM 試用之 OneAlert

Cloudwatch42

它是告警 ALL IN ONE,Zabbix 、API、NAGIOS、阿里雲、騰訊雲、監控寶等等發出的告警信息接入 OneAlert 數據中心。 OneAlert 根據定義好的規則,將經過定義好的告警方式(多是郵件、多是短信、多是電話)將告警消息傳給指定的人,規則各類靈活配置。

OneAPM VS Zabbix

經過全面的試用 OneAPM ,我以爲沒有必要拿 OneAPM 與傳統開源監控 Zabbix 作個比較。由於各自側重點不一樣,互相不可取代。OneAPM 偏重於性能管理, Zabbix 偏重於業務監控。

OneAPM 與 Zabbix 如何選擇?

文章寫這麼多,不是立馬讓你掏錢去買 OneAPM 服務,這並非個人初衷。我想讓你們全面的瞭解什麼 APM,APM 能作什麼? APM 能解決什麼問題?若是你以爲它對大家有說幫助,請絕不猶豫的使用它。若是以爲 Zabbix 就夠了。那也沒那個必要。

最後

感謝 OneAPM 提供試用功能,讓我更全面的瞭解了 OneAPM 性能管理。固然, zabbix 毫無疑問是一個偉大的產品,我是它的鐵桿粉絲(我用 Zabbix 110篇系列文章這個行動證實了),瞭解到它的強大之處,也瞭解到了它的不足之處,這個不足恰巧是 APM 的機會!

相關文章
相關標籤/搜索