# 新的文物建筑-每天收集 20 億多個指標 > 原文： [http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html](http://highscalability.com/blog/2011/7/18/new-relic-architecture-collecting-20-billion-metrics-a-day.html)  *這是 New Relic 應用性能工程師 [Brian Doll](/cdn-cgi/l/email-protection#0e6c7c676f604e606b797c6b62676d206d6163) 的來賓帖子。* New Relic 的多租戶 SaaS Web 應用程序監視服務持續不斷地每秒收集并保存超過 100,000 個指標，同時仍提供 1.5 秒的平均頁面加載時間。 我們相信，良好的體系結構和良好的工具可以幫助您處理大量數據，同時仍然提供非常快速的服務。 在這里，我們將向您展示我們如何做到的。 * 新遺物是應用程序性能管理（APM）即服務 * 應用內代理檢測（字節碼檢測等） * 支持 5 種編程語言（Ruby，Java，PHP，.NET，Python） * 全球監控超過 175,000 個應用程序進程 * 10,000+客戶 ## 統計資料 * 每天收集超過 20 億個應用程序指標 * 每周收集超過 1.7 億個網頁指標 * 每個“時間片”指標約為 250 個字節 * 每秒插入 10 萬個時間片記錄 * 每天有 70 億條新數據行 * 由 9 個分片的 MySQL 服務器處理的數據收集 ## 架構概述 * 語言特定的代理（Ruby，Java，PHP..NET，Python）每分鐘一次將應用程序指標發送回 New Relic * “收集器”服務提取應用程序指標并將其保存在正確的 MySQL 分片中 * 實時用戶監控 javascript 代碼段針對每個頁面瀏覽將前端性能數據發送到“信標”服務 * 客戶登錄 http://rpm.newrelic.com/查看其性能儀表板 * 我們每天收集的數據量驚人。 最初，每個指標均以全分辨率捕獲所有數據。 隨著時間的流逝，我們會對數據進行定期處理，從每分鐘到每小時，再到每天平均。 對于我們的專業帳戶，我們會無限期地存儲每日指標數據，因此客戶可以看到他們在長期內的改進情況。 * 我們的數據策略針對讀取進行了優化，因為我們的核心應用一直需要按時間序列訪問指標數據。 為了使數據保持最佳狀態以實現更快的讀取速度，更容易在寫操作上付出代價，以確保我們的客戶可以在一天中的任何時間快速訪問其性能數據。 通過將客戶分布在多臺服務器上，可以對數據庫進行分片。 在每個服務器中，每個客戶都有單獨的表，以使客戶數據在磁盤上保持緊密并保持每個表的總行數減少。 * New Relic 管理用于監視系統的多種警報。 客戶可以設置其 APDEX 分數和錯誤率的閾值。 New Relic 還具有可用性監視功能，因此客戶可以在短短 30 秒內收到停機事件的警報。 我們主要發送電子郵件警報，使用我們的 PagerDuty.com 集成向多個客戶發送電子郵件，并通過 SMS 集成進行更復雜的通話輪換。 * 讓我們從客戶請求一直到 New Relic 堆棧進行一次 Web 交易。 1. 最終用戶查看 Example.com 上的頁面，該頁面使用 New Relic 監視其應用程序性能 2. 運行 Example.com 的應用程序運行時已安裝了 New Relic 代理（適用于 Ruby，Java，PHP，.NET 或 Python） 3. 為每個事務捕獲詳細的性能指標，包括每個組件花費的時間，數據庫查詢，外部 API 調用等 4. 這些后端指標在客戶的 New Relic 代理中保留最多一分鐘，然后將其發送回 New Relic 數據收集服務。 5. 同時，嵌入在網頁中的是新的 Relic 真實用戶監控 JavaScript 代碼，該代碼可跟蹤這種單一客戶體驗的性能 6. 在客戶的瀏覽器中完全呈現頁面后，New Relic 信標會收到一個請求，其中提供了有關后端，網絡，DOM 處理和頁面呈現時間的性能指標。 7. 在 Example.com 上工作的工程師登錄到 New Relic，并查看了最新的應用程序性能指標以及每位客戶的最終用戶體驗，包括瀏覽器和地理信息。 ## 平臺 ### 網頁界面 * Ruby on Rails * Nginx 的 * 的 Linux * 2 個@ 12 核心 Intel Nehalem CPU 帶 48Gb RAM ### 數據收集器和 Web 信標服務 * 爪哇 * 碼頭上的 Servlet * 應用指標收集器：每分鐘 180k +請求，在 3 毫秒內響應 * Web 指標信標服務：每分鐘 200k +請求，在 0.15 毫秒內響應 * 使用 Percona 構建的 MySQL 分片 * 的 Linux * 9 @ 24 核 Intel Nehalem，帶 48GB RAM，SAS 附加 RAID 5 * 裸機（無虛擬化） ### 有趣的 MySQL 統計資料： * New Relic 每小時為每個帳戶創建一個數據庫表以保存度量標準數據。 * 該表策略針對讀取和寫入進行了優化 * 始終需要在特定的時間窗口內基于特定帳戶的一個或多個指標來繪制圖表 * 指標（指標，代理，時間戳）的主鍵允許來自特定代理的特定指標的數據一起位于磁盤上 * 隨著時間的推移，當創建新表時，這會在 innodb 中創建更多頁面拆分，并且 I / O 操作會在一小時內增加 * 新帳戶將以循環方式分配給特定的分片。 由于某些帳戶比其他帳戶大，因此有時會將分片從分配隊列中拉出，以更均勻地分配負載。 * 由于表中包含如此多的數據，因此無法進行模式遷移。 而是使用“模板”表，從中創建新的時間片表。 新表使用新定義，而最終從系統中清除舊表。 應用程序代碼需要注意多個表定義可能一次處于活動狀態。 ## 挑戰性 * 數據清除：匯總指標和清除粒度指標數據是一個昂貴且幾乎連續的過程 * 確定哪些指標可以預先匯總 * 大帳戶：一些客戶擁有許多應用程序，而另一些客戶擁有數量驚人的服務器 * MySQL 優化和調整，包括操作系統和文件系統 * I / O 性能：裸機數據庫服務器，每個帳戶表與大型表的讀取性能 * 負載均衡碎片：大帳戶，小帳戶，高利用率帳戶 ## 得到教訓 * New Relic 使用 New Relic 監視自己的服務（臨時監視生產） * 旨在隨時提高運營效率和簡化操作 * 保持苗條。 New Relic 擁有約 30 名工程師，為 1 萬名客戶提供支持 * 時髦！=可靠：高性能系統有許多重要但無聊的方面，但并不是所有時髦的解決方案都可以解決。 * 使用合適的技術來完成工作。 New Relic 主要 Web 應用程序始終是 Rails 應用程序。 數據收集層最初是用 Ruby 編寫的，但最終被移植到 Java。 導致此更改的主要因素是性能。 該層目前每分鐘支持超過 18 萬個請求，并在大約 2.5 毫秒內做出響應，并具有足夠的擴展空間。 ## 相關文章 * [如何在僅 9 臺服務器上構建具有類似 Twitter 吞吐量的 SaaS 應用程序](http://www.slideshare.net/newrelic/how-to-build-a-saas-app-with-twitterlike-throughput-on-just-9-servers)作者：Lew Cirne > >為每個事務捕獲詳細的性能指標，包括在每個組件中花費的時間，數據庫查詢，外部 API 調用等 這種儀器的開銷是多少？ 就延遲而言？ 感謝您的詳細帖子 幾個問題 1.你做后寫嗎？ 有關的任何細節。 哪種工具/技術 2.有關“負載平衡分片”的更多詳細信息將有所幫助 3.為什么選擇 Java 而不是 Rails ...特定的性能原因。 謝謝。 > 在每個服務器中，每個客戶都有單獨的表，以使客戶數據在磁盤上保持緊密并保持每個表的總行數減少。 也許他們不知道文件系統如何工作？ 除非您預分配了該塊，否則它將像其他所有文件一樣隨文件的增長而隨機寫入磁盤。 他們似乎認為，通過使用“ innodb_file_per_table”選項將其放入自己的表中并不保證文件會在磁盤上聚集。 @Hrish：“這種檢測的開銷是多少？就延遲而言？” 我們不斷監控儀器的開銷，并確保其開銷盡可能低。 開銷因應用程序而異，但通常在 5％的范圍內。 與不了解生產系統的機會成本相比，這種開銷顯得微不足道。 我已經看到許多公司在使用 New Relic 的短短幾天內就大大縮短了他們的響應時間，因此開銷遠遠超過了其本身。 @Subhash： 1.您是否在后面寫？ 有關的任何細節。 哪種工具/技術 不，我們不做后寫。 2.有關“負載平衡分片”的更多詳細信息將有所幫助 我們采用經典的分片模式，因為客戶指標對他們來說是唯一的，并且我們不需要在各個帳戶之間引用指標。 理想情況下，我們希望將負載分配到每個分片上。 在這種情況下，負載既指數據量（在給定時間段內每個分片接收多少數據），也指查詢量（那些客戶訪問其指標的積極程度）。 我們每個帳戶允許無限數量的用戶，因此某些帳戶有許多用戶一次訪問其性能數據。 我們一起研究這些指標以及諸如 CPU 和內存之類的系統指標，以確定負載在整個分片上的分布情況。 我們以循環方式將新帳戶分配給特定的分片。 這聽起來非常簡單，而且確實如此。 這里的過早優化可能需要付出很大的努力才能進行管理，而帶來的好處卻很小。 您只是無法確定注冊新帳戶后的忙碌程度。 我們會不時注意到特定的分片比其他分片更忙。 這可能是由于新帳戶非常龐大，或者是由于現有帳戶利用率提高。 為了幫助平衡分片，我們只從分配隊列中刪除該分片，因此暫時不會獲得任何新帳戶。 由于我們一直在注冊新帳戶，因此其余的碎片將趕上來，我們將其重新添加。 我已經與幾個為具有類似數據需求的公司在生產中運行分片的人交談過，看來這種方法相當普遍。 正如他們所說，做最簡單的事情就可以了:) 3.為什么選擇 Java 而不是 Rails ...特定的性能原因。 用于數據收集的服務端點已從 Ruby 移植到 Java。 這些服務非常強大，并且不會經常更改。 他們需要從成千上萬個應用程序實例中獲取指標數據，并將其放入正確的分片中的正確的數據庫表中。 除了耐用性，這些保養的最重要特征是原始速度。 使用當前的 ruby 實現，根本不可能與 Java servlet 競爭速度和效率。 我們的 Real User Monitoring 信標服務（作為 Java Servlet 部署）的響應時間為 0.15 毫秒。 十五分之一毫秒！ 這是每分鐘 280k +請求。 您特別強調數據庫服務器是裸機。 這是否意味著其他內容已虛擬化？ 我很驚訝您確實運行自己的服務器。 我一直以為您是那些早期的云采用者之一。 :) 您是否在單個數據中心中運行？ 您如何處理高可用性？ “ [開銷]通常在 5％的范圍內” 除非有人指出執行的檢測程度和檢測到的主要組件的等待時間，即一個非常慢的 Rails 應用程序甚至更慢的數據庫訪問，否則這毫無意義。 與其他產品的單位成本相比，NewRelic 的速度要慢近 10,000-100,000 倍。 http://williamlouth.wordpress.com/2011/03/17/which-ruby-vm-consider-monitoring/ 順便說一句，我想知道如何將 NewRelic 下面的屏幕截圖中的多個 SQL 語句打包成 250 個字節。 http://williamlouth.wordpress.com/2010/03/02/does-transaction-tracing-scale-analysis/ 我認為您還應該指出，考慮到發送之前在 1 分鐘的示例窗口中對高級度量聚合進行了批處理，因此所測量的頁面數與對服務的入站調用數不同。 如果您打算從事 APM 業務，那么您至少可以嘗試對數字的實際含義和關聯性進行準確和更加透明的了解。 您是否曾經考慮過使用 Mysql Cluster？ NDB？ 無需分片即可立即獲得巨大的讀取/寫入可擴展性。 我們一直在使用 Galera 群集來處理 1440K 更新，每分鐘有足夠的凈空。 順便說一句，恭喜并感謝您分享非常有用的信息。