在 SRE/DevOps 工程師的環境中，如果有一天客戶端（或監控系統）出現並報告“一切都丟失了”，任何人都不會感到驚訝：網站無法工作，付款無法完成，生活正在衰退.. .無論您多麼想在這種情況下提供幫助，如果沒有簡單易懂的工具，都很難做到這一點。 通常，問題隱藏在應用程式程式碼本身中；您只需對其進行本地化即可。
並在悲傷和喜悅中…
恰巧我們已經深深地愛上了New Relic。 它過去是，現在仍然是監控應用程式效能的優秀工具，並且還允許您檢測微服務架構（使用其代理）等等。 如果不是服務定價政策的變化，一切都會很棒： 成本 成長了3倍以上。 此外，從去年開始，獲得試用帳戶需要與個人經理溝通，這使得向潛在客戶展示產品變得困難。
通常的情況：New Relic 並不是「永久」需要的；他們只在問題開始時才記住它。 但您仍然需要定期付費（每台伺服器每月 140 美元），並且在自動擴展的雲端基礎設施中，這筆費用加起來相當大。 雖然有即用即付選項，但啟用 New Relic 將要求您重新啟動應用程序，這可能會導致丟失所有啟動時出現的問題情況。 不久前，New Relic推出了新的資費計畫—— ， - 乍一看似乎是專業版的合理替代品...但經過仔細檢查，發現缺少一些重要功能（特別是，它沒有 關鍵交易, 跨應用程式追蹤, 分佈式追踪).
因此，我們開始考慮尋找更便宜的替代方案，我們的選擇落在了兩個服務上：Datadog 和 Atatus。 為什麼要針對他們？
關於競爭對手
我馬上說，市場上還有其他解決方案。 我們甚至考慮了開源選項，但並非每個客戶都有空閒能力來託管自託管解決方案...... - 此外，它們將需要額外的維護。 我們選擇的這對夫婦是最接近的 我們的需求:
- 對 PHP 應用程式的內建和開發支援（我們客戶的堆疊非常多樣化，但在尋找 New Relic 替代方案的背景下，這是一個明顯的領導者）；
- 負擔得起的成本（每個主機每月低於 100 美元）；
- 自動儀表；
- 與 Kubernetes 整合；
- 與 New Relic 介面的相似性是一個明顯的優點（因為我們的工程師已經習慣了）。
因此，在最初的選擇階段，我們排除了其他幾種流行的解決方案，特別是：
- Tideways、AppDynamics 和 Dynatrace - 出於成本考慮；
- Stackify 在俄羅斯聯邦被屏蔽，顯示的資料太少。
本文其餘部分的結構是，首先簡要介紹所討論的解決方案，然後我將討論我們與 New Relic 的典型互動以及在其他服務中執行類似操作的經驗/印象。
選定參賽者的介紹
Про ，想必大家都聽過吧？ 這項服務於 10 多年前（即 2008 年）開始開發。 自 2012 年以來，我們一直在積極使用它，並且在 PHP、Ruby 和 Python 中整合大量應用程式時沒有出現任何問題，而且我們也有與 C# 和 Go 整合的經驗。 該服務的作者提供了監控應用程式、基礎設施、追蹤微服務基礎設施、為用戶設備創建方便的應用程式等的解決方案。
但是，New Relic 代理在專有協定上運行，不支援 OpenTracing。 高級儀器需要專門針對 New Relic 進行編輯。 最後，Kubernetes 支援仍處於實驗階段。
2010年開始研發 就 Kubernetes 環境中的使用而言，它看起來明顯比 New Relic 更有趣。 特別是，它支援與 NGINX Ingress、日誌收集、statsd 和 OpenTracing 協定集成，這使您可以追蹤使用者請求從連接到完成的那一刻起，以及查找該請求的日誌（都在 Web 伺服器端）以及消費者的）。
在使用Datadog時，我們遇到了它有時會錯誤地建立微服務地圖，以及一些技術缺陷。 例如，它錯誤地識別了服務類型（將 Django 誤認為是快取服務），並在使用流行的 Predis 庫的 PHP 應用程式中導致了 500 個錯誤。
— 最年輕的樂器； 該服務於2014年推出。 它的行銷預算顯然不如列出的競爭對手，提及的次數也少得多。 然而，該工具本身與 New Relic 非常相似，不僅在功能上（APM、瀏覽器監控等），而且在外觀上也是如此。
一個顯著的缺點是它只支援 Node.js 和 PHP。 另一方面，它的實作明顯優於 Datadog。 與後者不同的是，Atatus 不需要應用程式對程式碼進行修改或添加額外的標籤。
我們如何與 New Relic 合作
現在讓我們來了解一下我們一般如何使用New Relic。 假設我們有一個需要解決的問題：
從圖表上很容易看出 維克普萊斯克 - 我們來分析一下。 在New Relic 中，立即為Web 應用程式選擇Web 事務，所有元件都在效能圖表中指示，有錯誤率、請求率面板...最重要的是，您可以直接從這些面板在不同的面板之間移動。應用程式的部分（例如，點擊 MySQL 將進入資料庫部分）。
由於在所考慮的範例中我們看到活動激增 PHP，點選該圖表，自動跳轉至 交易:
事務清單本質上是 MVC 模型中的控制器，已按以下順序排序： 最耗時，這非常方便：我們立即看到應用程式做了什麼。 以下是 New Relic 自動收集的長查詢範例。 透過切換排序，很容易發現：
- 負載最多的應用程式控制器；
- 最常請求的控制器；
- 最慢的控制器。
此外，您可以展開每個事務並查看執行程式碼時應用程式正在執行的操作：
最後，應用程式儲存長請求（花費超過 2 秒的請求）的追蹤範例。 這是長交易的面板：
可以看到兩個方法花費了很多時間，同時也顯示了請求執行的時間，它的URI和域。 通常這有助於在日誌中尋找請求。 即將 追蹤詳情，您可以看到這些方法是從哪裡呼叫的：
而在 資料庫查詢 — 評估應用程式執行階段執行的資料庫的查詢：
有了這些知識，我們就可以評估應用程式速度變慢的原因，並與開發人員合作制定解決問題的策略。 事實上，New Relic 並不總是能給出清晰的畫面，但它有助於選擇調查方向：
- 長
PDO::Construct引導我們了解 pgpoll 的奇怪功能； - 隨著時間的推移不穩定
Memcache::Get提示虛擬機器配置不正確； - 模板處理時間的可疑增加導致嵌套循環檢查物件儲存中是否存在 500 個頭像；
- 等等…
也有可能是與外部資料儲存相關的內容出現在主螢幕上，而不是執行程式碼 - 無論它是什麼：Redis 或 PostgreSQL - 它們都隱藏在選項卡中 數據庫.
您可以選擇特定的研究基礎並對查詢進行排序 - 類似於事務中的操作方式。 透過轉到請求選項卡，您可以看到該請求在每個應用程式控制器中發生了多少次，並估計了它被呼叫的頻率。 非常舒服：
該選項卡包含類似數據 對外服務，它隱藏對外部 HTTP 服務的請求，例如存取物件儲存、向哨兵發送事件等。 此選項卡的內容與資料庫完全相似：
競爭對手：機會和印象
現在最有趣的是將 New Relic 的功能與競爭對手提供的功能進行比較。 不幸的是，我們無法在生產中運行的一個應用程式的一個版本上測試所有這三種工具。 然而，我們嘗試比較盡可能相同的情況/配置。
1.數據狗
Datadog 用一個有服務牆的面板來迎接我們：
它嘗試將應用程式分解為元件/微服務，因此在範例 Django 應用程式中，我們將看到 2 個到 PostgreSQL 的連接（defaultdb и postgres），還有 Celery、Redis。 使用 Datadog 需要您對 MVC 原則有最低限度的了解：您需要了解使用者請求通常來自哪裡。 這通常有幫助 服務地圖:
順便說一句，New Relic 中也有類似的內容：
……在我看來，他們的地圖變得更簡單、更清晰：它不顯示一個應用程式的元件（這會使其過於詳細，就像Datadog 的情況一樣），而只顯示特定的服務或微服務。
讓我們回到Datadog：從服務圖中我們可以看到使用者請求來到了Django。 我們去Django服務，最後看看我們期望的是什麼：
不幸的是，這裡預設沒有圖表 網路交易時間，類似於我們在 New Relic 主面板上看到的內容。 但是，可以配置它來代替計劃 所花費時間的百分比。 把它切換到就足夠了 按類型劃分的每個請求的平均時間……現在熟悉的圖表正在看著我們！
為什麼 Datadog 選擇不同的圖表對我們來說是個謎。 另一個令人沮喪的是系統不會記住用戶的選擇（與兩個競爭對手不同），因此唯一的解決方案是建立自訂面板。
但我很高興 Datadog 能夠從這些圖表切換到相關伺服器的指標、讀取日誌並評估 Web 伺服器處理程序 (Gunicorn) 上的負載。 一切都與 New Relic 中的幾乎相同......甚至更多（日誌）！
下圖是與 New Relic 完全相似的交易：
在Datadog中，交易被稱為 資源。 您可以按請求數、平均回應時間以及選定時間段內花費的最長時間對控制器進行排序。
您可以擴展資源並查看我們在 New Relic 中已經觀察到的所有內容：
其中有資源的統計資料、內部呼叫的通用清單以及可以按回應代碼排序的請求範例…順便說一句，我們的工程師非常喜歡這種排序。
Datadog 中的任何範例資源都可以開啟和研究：
提供了請求參數、每個元件所花費時間的總和圖表以及顯示呼叫順序的瀑布圖。 您也可以切換到瀑布圖的樹視圖：
最有趣的是查看執行請求的主機的負載並查看請求日誌。
偉大的整合！
您可能想知道選項卡在哪裡 數據庫 и 對外服務，如《新遺物》中那樣。 這裡沒有：由於Datadog將應用程式分解為組件，因此將考慮PostgreSQL 單獨的服務，而不是外部服務值得尋找 aws.storage （對於應用程式可以存取的所有其他外部服務來說，這都是類似的）。
這是一個例子 postgres:
基本上我們想要的一切都有了：
您可以看到請求來自哪個「服務」。
值得提醒您的是，Datadog 與 NGINX Ingress 完美集成，允許您從請求到達集群的那一刻起執行端到端跟踪，還允許您接收 statsd 指標、收集日誌和主機指標。
Datadog 的一個巨大優點是它的價格 發展 從基礎設施監控、APM、日誌管理和綜合測試，即您可以靈活選擇您的計劃。
2.狀態
Atatus 團隊聲稱他們的服務「與 New Relic 相同，但更好」。 讓我們看看事實是否如此。
主面板看起來確實相似，但無法確定應用程式中使用的 Redis 和 memcached。
APM 預設選擇所有事務，但通常只需要 Web 事務。 與 Datadog 一樣，無法從主面板導航到所需的服務。 而且，事務是在錯誤之後列出的，這對 APM 來說似乎不太符合邏輯。
在 Atatus 交易中，一切都盡可能與 New Relic 相似。 缺點是每個控制器的動態不是立即可見的。 您必須在控制器表中查找它，按排序 消耗最多的時間:
選項卡中提供了常用的控制器列表 探索各精選系列:
在某些方面，這張表讓人想起 Datadog，而且我比 New Relic 中的類似表更喜歡它。
您可以展開每個事務並查看應用程式正在做什麼：
該面板也更讓人想起 Datadog：有許多請求，以及調用的整體情況。 頂部面板提供了一個錯誤選項卡 HTTP 失敗 以及慢查詢的範例 會話追蹤:
如果您轉到事務，您可以看到追蹤範例，您可以取得對資料庫的請求清單並查看請求標頭。 一切都與 New Relic 相似：
總的來說，Atatus 對詳細的追蹤感到滿意 - 沒有典型的 New Relic 將呼叫黏合到提醒塊中：
然而，它缺少一個可以切斷超快請求（<5ms）的過濾器（如 New Relic）。 另一方面，我喜歡顯示最終的交易回應（成功或錯誤）。
面板 數據庫 將幫助您研究應用程式對外部資料庫發出的請求。 讓我提醒您，Atatus 只發現了 PostgreSQL 和 MySQL，儘管 Redis 和 memcached 也參與了這個專案。
請求根據通常的標準進行排序：回應頻率、平均回應時間等。 我還想提一下查詢最慢的選項卡 - 它非常方便。 此外，PostgreSQL 的此標籤中的資料與擴充功能中的資料一致 - 優異的成績！
標籤 外部請求 與資料庫完全相同。
發現
兩種工具在 APM 方面都表現良好。 他們中的任何一個都可以提供所需的最低限度。 我們的印象可以簡單概括如下：
數據狗
優點：
- 方便的資費表（APM 每個主機的費用為 31 美元）；
- 與 Python 配合良好；
- 與 OpenTracing 整合的可能性
- 與 Kubernetes 整合；
- 與 NGINX Ingress 整合。
缺點：
- 唯一導致應用程式因模組錯誤（predis）而變得不可用的APM；
- PHP 自動偵測功能較弱；
- 服務及其目的的定義有些奇怪。
阿塔圖斯
優點：
- 深入的 PHP 檢測；
- 使用者介面類似於New Relic。
缺點：
- 不適用於較舊的作業系統（Ubuntu 12.05、CentOS 5）；
- 自動儀表功能弱；
- 僅支援兩種語言（Node.js 和 PHP）；
- 界面緩慢。
考慮到 Atatus 每台伺服器每月 69 美元的價格，我們寧願使用 Datadog，它與我們的需求（K8s 中的 Web 應用程式）很好地集成，並且具有許多有用的功能。
聚苯乙烯
另請閱讀我們的博客：
- «“;
- «“;
- «“。
來源： www.habr.com