Prometheus 文件現在包含了一個全新的 Kapa.ai 整合。這是作為 CNCF 與 Kapa.ai 的合作伙伴關係  的一部分提供的，旨在幫助 CNCF 專案使其文件和知識更易於獲取。

您現在可以使用 prometheus.io 上的 Ask AI 入口，用自然語言進行提問，並獲得基於 Prometheus 文件的回答。對於 Prometheus 團隊而言，這也是一種瞭解人們試圖從文件中學習什麼以及文件在哪些方面仍需改進的有用方式。

Prometheus 一直將解決複雜的技術挑戰放在首位，以交付一個可靠、高效能的開源監控系統。然而，隨著時間的推移，使用者反映了各種與體驗相關的痛點。這些痛點涵蓋了從入門和配置到文件、心智模型以及整個生態系統的互操作性等各個方面。

在 PromCon 2025 上，展示了一項使用者研究 ，該研究強調了其中一些問題。儘管調查的核心領域涉及 Prometheus 和 OpenTelemetry 工作流，但更廣泛的啟示很明確：Prometheus 將受益於一項致力於瞭解使用者需求並改善整體使用者體驗的持續努力。

認識到這一點，Prometheus 團隊成立了一個工作組，專注於透過設計和使用者研究來改善使用者體驗。該小組旨在透過將結構化研究、使用者洞察和易用性視角引入社群的開發和決策過程中，來支援 Prometheus 的所有領域。

您是否發現自己經常在查詢 container_memory_usage_bytes、container_memory_working_set_bytes 和 container_memory_rss 之間的區別？一旦選錯，您的記憶體限制就會誤導您，您的基準測試也會產生誤導，並且您的容器會被 OOMKilled（因記憶體不足而被殺掉）。

您並不孤單。甚至有一個 已有 9 年曆史的 Kubernetes Issue  記錄了使用者的沮喪。

解釋很簡單：RAM 的使用方式不止一種。最容易忽略的事情之一就是 頁面快取  語義。對於某些容器，頁面快取佔用的記憶體可能會佔報告使用量的大部分，即使這部分記憶體很大程度上是可以回收的，從而在這些指標之間造成驚人的差異。

在過去的一年裡，the Prometheus 社群一直在努力進行幾項有趣且雄心勃勃的改變，這些改變在以前可能被認為是備受爭議或不可行的。雖然外界對這些改變的瞭解可能很少（例如，它不是 OpenClaw Prometheus 外掛，抱歉 🙃），但 Prometheus 開發者正在有機地引導 Prometheus 走向一個確定、連貫的未來。一步一個腳印，我們出乎意料地接近了作為一個開源專案從未夢想過能實現的目標！

這篇文章是（希望如此！）分享一些雄心勃勃的轉變的系列部落格文章的開篇，這些轉變可能會讓新的以及現有的 Prometheus 使用者和開發者感到興奮。在這篇文章中，我想把重點放在複合型別的原生儲存這一概念上，它正在解決隨著時間推移積累起來的許多挑戰。請務必檢視文中提供的內聯連結，瞭解如何儘早採用其中一些更改或做出貢獻！

在 Prometheus 中，用元資料標籤來豐富指標可能會出奇地棘手，即使您是 PromQL 專家也是如此！傳統上用於此目的的 PromQL 連線 (join) 查詢本質上相當複雜，因為它必須指定要連線的標籤、要連線的 info 指標以及要豐富進去的標籤。全新且仍處於實驗階段的 info() 函式承諾提供一種更簡單的方法，使標籤豐富變得像將查詢包裝在單個函式呼叫中一樣簡單。

在 Prometheus 3.0 中，我們引入了 info() 函式，這是一種利用 info 指標的標籤來豐富時間序列的強大新方法。與傳統的連線查詢技術相比，info() 的特殊之處在於它使您無需指定識別性標籤 (identifying labels)、要與哪些 info 指標進行連線，以及要豐富進去的（“資料”或“非識別性”）標籤。請注意，在此特定上下文中，“識別性標籤”是指用於標識相關 info 指標並與相關的非 info 指標共享的標籤集。它們是您在 Prometheus 連線查詢  中進行連線時所依據的標籤。在概念上，它們可以與關係資料庫中的 外部索引鍵  相媲美。

除了主要功能之外，info() 還解決了一個多年來一直困擾著連線查詢的微妙但至關重要的問題：當非識別性 info 指標標籤發生變化時導致查詢失敗的“流失問題 (churn problem)”，以及結合缺失的陳舊性標記（如 OTLP 攝入的情況）。

無論您是在處理 OpenTelemetry 資源屬性、Kubernetes 標籤還是任何其他元資料，info() 函式都能讓您的 PromQL 查詢更整潔、更可靠且更易於理解。

Prometheus 的 目標重新打標籤 (target relabeling) 功能允許您調整已發現目標的標籤，甚至可以完全丟棄該目標。重新打標籤規則雖然功能強大，但可能很難理解和除錯。您的規則必須與服務發現機制返回的預期標籤相匹配，任何步驟出錯都可能導致您的目標被錯誤打上標籤或被意外丟棄。

為了幫助您找出出錯（或正確）的地方，Prometheus 3.8.0 剛剛在 Prometheus 伺服器的 Web UI 中添加了一個重新打標籤視覺化工具 ，使您能夠檢查每個重新打標籤規則是如何應用於已發現目標的標籤的。讓我們來看看它是如何工作的！

我第一次接觸 Prometheus 專案是透過 Linux 基金會導師計劃 ，在其中我進行了 UX（使用者體驗）研究。我還記得當選為學員時感到的焦慮。我不僅對 Prometheus 感到陌生，對整個可觀測性領域也完全陌生。我擔心自己無法勝任，在一個高度以開發者為核心的領域工作，而自己卻完全沒有開發背景。

事實證明，那種焦慮是多餘的。我隨後對該專案做出了有意義的貢獻，並且我瞭解到，我的經歷在開源的非技術貢獻者中幾乎是普遍存在的。

如果您也有同樣的疑慮，這篇文章就是為您準備的。我將分享您可能面臨（或已經面臨）的挑戰，為什麼您的貢獻至關重要，以及如何在 Prometheus 社群中找到自己的位置。

Yet Another Cloudwatch Exporter  (YACE) 已正式加入 Prometheus 社群！此舉將使其更易於被使用者獲取，併為貢獻者改進和維護該專案開闢新的機遇。此外，還有一篇從 Cristian Greco 的視角出發的部落格文章 。

早期階段

當我剛開始開發 YACE 時，我根本沒想到它會發展到如此規模。當時，我在 Invision AG  工作（不要與同名設計應用混淆），這是一家專注於勞動力管理軟體的公司。他們完全支援我將該工具開源，並在我的隊友 Kai Forsthövel  的幫助下，YACE 誕生了。

我們的第一次提交是在 2018 年，我們的主要目標之一是使 CloudWatch 指標易於擴充套件並自動檢測要測量的內容，同時保持簡單直觀的使用者體驗。由於機器學習工作負載，InVision AG 當時正在頻繁地對基礎設施進行擴縮容，因此我們需要一種能夠輕鬆檢測新基礎設施的工具。這種對簡單性的關注一直是核心優先順序。從那時起，YACE 開始找到了自己的受眾。

繼最近在柏林 PromCon 上釋出 Prometheus 3.0 beta 之後，Prometheus 團隊很高興地宣佈 Prometheus 3.0 版本即刻可用！

這一最新版本標誌著一個重要的里程碑，因為它是 7 年來的首個主要版本。在這段時間裡，Prometheus 走過了漫長的道路，從一個針對早期採用者的專案發展成為雲原生監控棧的標準組成部分。Prometheus 3.0 旨在透過新增一些令人興奮的新功能，同時在很大程度上保持與先前版本的穩定性和相容性，來繼續這一旅程。

完整的 3.0 版本在 beta 版的基礎上添加了一些新功能，並引入了一些我們將在本文中描述的其他重大變更 (breaking changes)。

Prometheus 團隊自豪地宣佈 Prometheus 3.0-beta 版本釋出！您可以在 此處  下載它。按照 Beta 版釋出的傳統，我們不建議使用者在關鍵生產系統上安裝 Prometheus 3.0-beta，但我們確實希望每個人都能對它進行測試並找出 bug。

總的來說，唯一的重大變更是移除了已棄用的特性標誌 (feature flags)。Prometheus 團隊努力確保向後相容性，且不破壞現有的安裝，因此下面描述的所有新功能都是在現有功能之上構建的。大多數使用者應該能夠直接試用 Prometheus 3.0，而無需更改任何配置。

OpenTelemetry 專案  是一個可觀測性框架和工具包，旨在建立和管理遙測資料（如鏈路追蹤、指標和日誌）。由於其在不同訊號之間的規範一致性，以及減少廠商鎖定的承諾，它正獲得廣泛採用，這也是我們感到興奮的地方。

回顧 2023 年

在過去的幾年中，我們與 OpenTelemetry 社群展開了合作，以確保 OpenTelemetry 和 Prometheus 實現雙向支援。這促成了兩個系統之間相互轉換的官方規範的起草，以及允許您將 Prometheus 指標攝入到 OpenTelemetry Collector（反之亦然）的實現。

從那時起，我們花費了大量時間來了解 OpenTelemetry 使用者在 Prometheus 中儲存指標時 面臨的挑戰 ，並在此基礎上探索了 我們該如何解決這些問題 。提出的一些變更需要仔細考慮，以避免破壞任何一方的操作承諾，例如同時支援推（push）和拉（pull）。在 PromCon Berlin 2023 上，我們嘗試在 其中一場演說  中對我們的想法進行了總結。

在柏林舉辦的 開發者峰會  上，我們花了大半時間深入討論了這些變革以及我們對 OpenTelemetry 的總體立場，而廣泛的共識是，我們希望 “成為 OpenTelemetry 指標的預設儲存庫” ！

我們已經組建了一個核心開發團隊來領導這一倡議，並將於 2024 年釋出 Prometheus 3.0，而 OTel 支援將是其最重要的特性之一。以下是 2024 年即將推出內容的搶先預覽。

PromCon Europe 是第八屆完全致力於 Prometheus 監控系統的會議

德國柏林 – 2023 年 9 月 1 日 – CNCF 和 Prometheus 團隊公佈了將於 2023 年 9 月 28 日至 29 日在德國柏林舉行的單軌 PromCon Europe 2023 會議的為期兩天的日程表。參會者將能夠從 21 場完整長度（25分鐘）的專題會議以及多達 20 場 5 分鐘的閃電演講中進行選擇，內容涵蓋與 Prometheus 相關的各類主題。

作為第 8 屆會議，PromCon 匯聚了來自世界各地的 Prometheus 使用者和開發者，共同交流在使用 Prometheus 過程中積累的知識、最佳實踐和經驗。專案委員會評審了 66 份提案，這些提案將為當今圍繞 Prometheus 的最緊迫議題提供全新且資訊豐富的視角。

“我們對 PromCon 回到柏林舉辦感到超級興奮。Prometheus 於 2012 年誕生於柏林的 Soundcloud。第一屆 PromCon 在柏林舉辦，此間曾移師慕尼黑。今年，我們在柏林腓特烈斯海因的 Radialsystem 接待大約 300 名參會者。柏林擁有活躍的 Prometheus 社群，許多 Prometheus 團隊成員就住在附近。這是一個與 Prometheus 家族建立聯絡並進行交流的絕佳機會，他們都對系統和業務監控充滿熱情，”Polar Signals 高階軟體工程師兼今年 PromCon 專案委員會負責人、Prometheus 團隊成員 Matthias Loibl 說道。“這將是一個瞭解 Prometheus 團隊本身最新進展，並近距離接觸一些 Prometheus 大規模使用者的絕佳活動。”

Prometheus 2.43 剛剛釋出，它帶來了一些令人興奮的特性和增強。其中一項重大改進是 stringlabels 版本，它使用了全新的標籤資料結構。這篇部落格文章將回答關於 2.43 版本和 stringlabels 最佳化的一些常見問題。

什麼是 stringlabels 版本？

stringlabels 版本是使用新標籤資料結構的 Prometheus 2.43 版本。它將所有的標籤/值對儲存在單個字串中，從而在大多數情況下可以減小堆大小並帶來一定的速度提升。這些最佳化並未包含在預設的二進位制檔案中，需要使用 Go 構建標籤 stringlabels 來編譯 Prometheus。

Bartek Płotka 自 2019 年起擔任 Prometheus 維護者，現任 Red Hat 首席軟體工程師。CNCF Thanos 專案的共同作者，CNCF 大使兼 CNCF TAG 可觀測性技術負責人。在空閒時間，他與 O'Reilly 合作撰寫了名為《Efficient Go》的書。以上僅代表個人觀點！

我個人非常喜愛 Prometheus 專案的一點，也是我加入該團隊的眾多原因之一，是該專案對自身目標的極度專注。Prometheus 始終致力於在提供實用、可靠、廉價但極具價值的基於指標的監控方面不斷突破極限。Prometheus 極度穩定且健壯的 API、查詢語言和整合協議（例如 Remote Write 和 OpenMetrics ）使雲原生計算基金會 (CNCF) 的指標生態系統得以在這些強大的基石上蓬勃發展。令人驚歎的事情由此發生

• 我們可以看到幾乎針對任何事物的指標獲取社群匯出器 (exporters)，例如 容器 、eBPF 、Minecraft 伺服器統計資訊 ，甚至還有 園藝時的植物健康狀況 。
• 如今，大多數人都期望雲原生軟體具有一個 Prometheus 可以抓取的 HTTP/HTTPS /metrics 端點。這一概念最初是在谷歌內部秘密開發的，並由 Prometheus 專案在全球範圍內開創了先河。
• 可觀測性正規化發生了轉變。我們看到 SRE 和開發人員從第一天起就嚴重依賴指標，這提高了軟體的彈性、可除錯性，並促進了資料驅動的決策！

歸根結底，我們幾乎看不到不執行 Prometheus 的 Kubernetes 叢集。

今天，我們啟動了 Prometheus 一致性計劃，旨在確保 Prometheus 監控領域中不同專案和廠商之間的互操作性。雖然法律文書仍需最終確定，本著測試先行的原則，我們將以下內容視為我們的第一輪結果。作為此次啟動的一部分，Julius Volz 更新了他的 PromQL 測試結果 。

快速提醒一下：該計劃被稱為 Prometheus 一致性 (Conformance)，軟體可以透過特定測試實現合規 (compliant)，從而獲得相容性 (compatibility) 評級。命名法看起來可能有些複雜，但它使我們能夠討論這個話題，而無需使用無休止的冗長詞句。

正如奧斯卡·王爾德所說，模仿是最真誠的奉承。

“Prometheus” 和 “Thanos” 這兩個名字 最近被一個勒索軟體團伙採用了 。對此我們無能為力，除了通知您這正在發生。您也無能為力，除了意識到這正在發生。

雖然我們沒有理由相信該團伙會試圖誘騙任何人下載我們專案的虛假二進位制檔案，但我們仍然建議遵循通用的供應鏈和安全實踐。在部署軟體時，請透過那些安全機制進行。

正如 CNCF 所宣佈的  以及我們自己所宣佈的那樣，我們正在啟動一項 Prometheus 一致性計劃。

為了在正式執行測試之前讓大家對整個生態系統現狀有一個大概的瞭解，我們想展示一下我們快樂的小測試套件家族中的最新成員：Prometheus Remote Write 合規性測試套件，該套件根據我們的 規範  對 Remote Write 協議的傳送端部分進行測試。

在週一的 PromCon  上，Tom Wilkie  展示了幾周前錄製時的測試結果。在現場直播環節中，他已經發布了 更新 。兩天後，我們又迎來了兩個更新：添加了 可觀測性流水線工具 Vector ，以及 現有系統的新版本 。

Prometheus 是雲原生領域及其他領域指標監控的標準。為了確保互操作性、保護使用者免受意外影響，並實現更多並行創新，Prometheus 專案在 CNCF  的幫助下推出了 Prometheus 一致性計劃 ，以認證元件合規性和 Prometheus 相容性。

CNCF 理事會預計將在下次會議上正式審查和批准該計劃。我們邀請更廣泛的社群在這個準備階段幫助改進我們的測試。

藉助我們 廣泛且不斷擴充套件的測試套件 ，專案和廠商可以確定是否符合我們的規範以及在 Prometheus 生態系統中的相容性。

您是否曾經選擇過某個指標的前 10 個時間序列，結果卻得到了 100 個，而不是 10 個？如果是的話，那麼這篇文章非常適合您。讓我帶您瞭解背後的根本問題以及我是如何解決的。

目前，topk() 查詢僅作為瞬時查詢 (instant query) 才有意義，在瞬時查詢中您可以準確地得到 k 個結果，但是當您將其作為區間查詢 (range query) 執行時，您可能會得到遠多於 k 個結果，因為每個時間步長都是獨立評估的。這個 @ 修飾符允許您在區間查詢中固定所有步長的排名。

在 Prometheus v2.25.0 中，我們引入了一個新的 PromQL 修飾符 @。類似於 offset 修飾符允許您將瞬時向量選擇器、區間向量選擇器和子查詢的評估相對於評估時間偏移固定的時長， @ 修飾符允許您固定這些選擇器的評估時間，而不受查詢評估時間的影響。該語法的功勞歸功於 Björn Rabenstein 。

<vector-selector> @ <timestamp>
<range-vector-selector> @ <timestamp>
<subquery> @ <timestamp>

The <timestamp> 是一個 Unix 時間戳，用浮點字面量表示。

我們始終遵循 SemVer（語義化版本）模型，對穩定性和重大變更做出過堅實的承諾。這一原則將保持不變。

由於我們希望在實驗方面更加大膽，我們計劃更多地使用特性標誌 (feature flags)。

從 v2.25.0 開始，我們引入了一個名為 停用特性 (disabled features) 的新部分，其中的特性隱藏在 --enable-feature 標誌後面。在未來的版本中，您可以預期會有越來越多特性被新增到此部分。

此列表中的特性被視為實驗性的，只要它們仍處於 --enable-feature 後面，就需要注意以下事項

1. 如果該特性具有任何 API（Web API、程式碼介面等），其 API 規範可能會發生變化。
2. 特性的行為可能會發生改變。
3. 它們可能會打破您對 Prometheus 的某些假設。
   • 例如，認為查詢不會在評估時間之後去前瞻樣本的假設，該假設將被 @ 修飾符和負偏移量 (negative offset) 打破。
4. 它們可能會不穩定，但我們當然會盡力保持它們的穩定性。

新的 Prometheus 2.13.0 版本已可用，與往常一樣，它包含了許多修復和改進。您可以在 此處  閱讀具體變更。然而，有一個特性是一些專案 and 使用者一直在等待的：分塊、流式版本的 Remote Read API 。

在本文中，我想深入探討我們在遠端協議中做出了哪些改變、為什麼要進行這些改變，以及如何有效地使用它。

遠端 API

自 1.x 版本以來，Prometheus 已經能夠使用 遠端 API 直接與其儲存進行互動。

該 API 允許第三方系統透過兩種方法與指標資料進行互動

• Write - 接收由 Prometheus 推送的樣本
• Read - 從 Prometheus 拉取樣本

這兩種方法都使用 HTTP，訊息使用 protobufs  進行編碼。這兩種方法的請求和響應都使用 snappy  進行壓縮。

繼續我們對 Prometheus 使用者的系列訪談，來自 ForgeRock 的 Ludovic Poitou 講述了他們的監控心路歷程。

您能介紹一下您自己以及 ForgeRock 是做什麼的嗎？

我是 Ludovic Poitou，ForgeRock  的產品管理總監，工作地點在法國格勒諾布林附近。ForgeRock 是一家國際身份與訪問管理軟體公司，擁有 500 多名員工，於 2010 年在挪威成立，總部目前設在美國舊金山。我們提供解決方案，以保障與客戶、員工、裝置和事物的每一次線上互動的安全。我們擁有 800 多家客戶，從金融公司到政府服務機構不等。

在使用 Prometheus 之前，您的監控體驗是怎樣的？

ForgeRock 身份平臺一直提供監控介面。但是該平臺由 4 個主要產品組成，每個產品都有不同的選項。例如，Directory Services 產品透過 SNMP、JMX 或 LDAP 提供監控資訊，在最新版本中甚至透過基於 HTTP 的 RESTful API 提供。其他產品則只提供 REST 或 JMX。因此，監控整個平臺非常複雜，並且需要能夠整合這些協議的工具。

繼續我們對 Prometheus 使用者的系列訪談，來自 Hostinger 的 Donatas Abraitis 講述了他們的監控心路歷程。

您能介紹一下您自己以及 Hostinger 是做什麼的嗎？

我是 Donatas Abraitis，Hostinger  的系統工程師。顧名思義，Hostinger 是一家主機託管服務公司。自 2004 年以來，我們擁有大約 3000 萬客戶，其中包括免費網頁託管服務商 000webhost.com  專案。

在使用 Prometheus 之前，您的監控體驗是怎樣的？

當 Hostinger 還是一家相當小的公司時，當時市場上僅有 Nagios、Cacti 和 Ganglia 作為開源監控工具存在。這就像跟年輕人解釋什麼是軟盤驅動器一樣，但 Nagios 和 Cacti 至今仍在開發週期中。

即便當時沒有自動化工具，Bash + Perl 也能完成工作。如果您想擴充套件您的團隊和您自己，就絕對不能忽視自動化。沒有自動化，就需要投入更多的人工手動工作。

當時大約有 150 臺物理伺服器。相比之下，到目前為止我們大約擁有 2000 臺伺服器，包括虛擬機器和物理機。

對於網路裝置，SNMP 仍被廣泛使用。隨著“白盒”交換機的興起，SNMP 變得不那麼必要了，因為可以安裝常規的工具。

你可以不用 SNMP，而是在交換機內執行 node_exporter 或任何其他匯出器，以人類可讀的格式暴露你需要的任何指標。美觀總比醜陋好，對吧？

我們使用 CumulusOS，在我們的案例中它大多執行在 x86 架構上，因此執行任何 Linux 程式完全沒有問題。

簡介

正如標題所示，子查詢是查詢的一部分，允許您在查詢內進行區間查詢，這在以前是不可能的。這是一個提出已久的特性請求：prometheus/prometheus/1227 。

用於支援子查詢的 合併請求 (Pull Request)  最近已被合併到 Prometheus 中，並將在 Prometheus 2.7 中可用。讓我們在下文中瞭解更多資訊。

動機

有時，在某些情況下，您可能希望使用較低解析度/區間（例如 5m）的 rate 來發現問題，同時在一個較大的區間（例如 1h 的 max_over_time）內聚合該資料。

以前，在單個 PromQL 查詢中是無法實現上述操作的。如果您希望在針對告警規則或圖表的查詢中進行區間選擇，就需要基於該查詢建立一個記錄規則 (recording rule)，並在該記錄規則建立的指標上進行區間選擇。例如：max_over_time(rate(my_counter_total[5m])[1h])。

當您想要獲取跨越數天或數週的資料的快速結果時，在記錄規則中有足夠的資料可供使用之前，可能需要等待相當長的時間。忘記新增記錄規則可能會令人沮喪。而且，為查詢的每一步都建立記錄規則會很繁瑣。

有了子查詢支援，所有的等待和沮喪都迎刃而解了。

繼續我們對 Prometheus 使用者的系列訪談，來自 Presslabs 的 Mile Rosu 講述了他們的監控心路歷程。

您能介紹一下您自己以及 Presslabs 是做什麼的嗎？

Presslabs  是一個高效能的託管型 WordPress 託管服務平臺，目標客戶是出版商、企業品牌和數字代理機構，旨在 100% 的時間內為他們的網站訪問者提供無縫的體驗。

最近，我們為核心產品開發了一個創新元件——WordPress 商業智慧 (WordPress Business Intelligence)。使用者現在可以在一個綜合的儀表板中獲取即時的、可操作的資料，以支援從發現問題到快速部署的短流程以及網站的持續改進。

我們在完全致力於為苛刻客戶提供託管型 WordPress 託管服務的 100 臺機器組成的叢集上，支援每月高達 20 億次頁面瀏覽量的無縫交付。

我們目前正致力於為全球的 WordPress 出版商帶來最佳體驗。在這一旅程中，Kubernetes 為我們邁向高可用性 WordPress 託管基礎設施的新興標準提供了便利。

我們很高興地宣佈，截至今天，Prometheus 已經在 CNCF  正式畢業。

Prometheus 是有史以來第二個達到這一級別的專案。透過讓 Prometheus 畢業，CNCF 表明了其對我們的程式碼和功能迭代速度、我們的成熟度與穩定性，以及我們的治理和社群流程充滿信心。對於任何在關於監控工具選擇的內部討論中的人來說，這也起到了外部質量驗證的作用。

自達到孵化級別以來，發生了很多事情；其中一些尤為突出

• 我們完全重寫了儲存後端，以支援服務中的高流失率 (high churn)
• 我們大力推動了穩定性，尤其是 2.3.2 版本
• 我們啟動了文件推進計劃，特別關注讓 Prometheus 的採納和加入社群變得更加容易

Prometheus 包含對許多服務發現 (SD) 系統的內建整合，例如 Consul、Kubernetes 以及 Azure 等公共雲提供商。然而，我們無法為市面上的每一個服務發現選項都提供整合實現。Prometheus 團隊在支援當前的一系列 SD 整合方面已經捉襟見肘，因此維護每一個可能的 SD 選項的整合是不可行的。在許多情況下，當前的 SD 實現是由團隊外部的人員貢獻的，然後沒有得到很好的維護或測試。我們希望承諾僅對我們知道能夠維護且按預期工作的服務發現機制提供直接整合。出於這個原因，目前暫停了新的 SD 整合。

然而，我們知道人們仍然希望能夠與其他服務發現（SD）機制（例如 Docker Swarm）進行整合。最近，Prometheus 倉庫的文件目錄 中提交了一個小的程式碼更改和一個示例，用於實現自定義服務發現整合，而無需將其合併到 Prometheus 主二進位制檔案中。這一程式碼更改允許我們利用內部的 Discovery Manager（發現管理器）程式碼來編寫另一個可執行檔案，該檔案與新的服務發現機制進行互動，並輸出與 Prometheus 的 file_sd 相容的檔案。透過將 Prometheus 和我們的新可執行檔案同機部署，我們可以配置 Prometheus 來讀取我們可執行檔案輸出的相容 file_sd 的內容，從而抓取該服務發現機制中的目標。未來，這將使我們能夠將服務發現整合移出 Prometheus 主二進位制檔案，並能將使用介面卡的穩定服務發現整合移動到 Prometheus 的 discovery  包中。

使用 file_sd 的整合（例如使用介面卡程式碼實現的整合）列在這裡。

讓我們來看看示例程式碼。

繼續我們的 Prometheus 使用者系列訪談，來自 Datawire 的 Richard Li 將講述他們是如何過渡到 Prometheus 的。

能向我們介紹一下您自己以及 Datawire 是做什麼的嗎？

在 Datawire，我們開發開源工具來幫助開發人員在 Kubernetes 上更快地編寫程式碼。我們的專案包括用於本地開發 Kubernetes 服務的 Telepresence ；基於 Envoy Proxy  構建的 Kubernetes 原生 API 閘道器 Ambassador ；以及構建/部署系統 Forge 。

我們在 AWS 的 Kubernetes 中執行著許多關鍵任務雲服務，以支援我們的開源工作。這些服務支援各種用例，例如每天動態預配數十個 Kubernetes 叢集，然後由我們的自動化測試基礎設施使用。

在使用 Prometheus 之前，您的監控體驗是怎樣的？

我們之前使用 AWS CloudWatch。這很容易設定，但我們發現，隨著我們採用更分散式的開發模型（微服務），我們希望獲得更多的靈活性和控制權。例如，我們希望每個團隊都能夠根據需要定製他們的監控，而不需要運維人員的協助。

繼續我們的 Prometheus 使用者系列訪談，來自 Scalefastr 的 Kevin Burton 將講述他們是如何使用 Prometheus 的。

能向我們介紹一下您自己以及 Scalefastr 是做什麼的嗎？

我叫 Kevin Burton，是 Scalefastr  的 CEO。我的背景是分散式系統，此前我曾創辦了 Datastreamer，這是一家構建了 PB 級分散式社交媒體爬蟲和搜尋引擎的公司。

在 Datastreamer，我們遇到了關於基礎設施的可擴充套件性問題，並基於 Debian、Elasticsearch、Cassandra 和 Kubernetes 構建了一個高效能叢集。

我們發現我們的許多客戶也同樣在基礎設施方面掙扎，我很驚訝他們在 AWS 和 Google Cloud 上託管海量內容所支付的費用。

我們不斷評估在雲中執行的成本，對我們來說，我們的雲託管成本將是目前支付費用的 5 到 10 倍左右。

我們決定基於開源和雲原生技術（如 Kubernetes、Prometheus、Elasticsearch、Cassandra、Grafana、Etcd 等）推出一個新的雲平臺。

我們目前託管了幾位 PB 級規模的客戶，並於本月試執行我們的新平臺。

12 月 6 日星期三是奧斯汀 CloudNativeCon 的 Prometheus 日，我們為您準備了精彩的演講和活動陣容。去 Prometheus 沙龍獲取有關如何最好地監控 Kubernetes 的實用建議，參加一系列關於 Prometheus 各個方面的演講，然後在 CNCF 展臺與一些 Prometheus 開發人員交流，之後還有 Prometheus 歡樂時光。閱讀下文了解更多細節……

大約一年半以前，我們釋出了 Prometheus 1.0。該版本的釋出標誌著該專案的一個重要里程碑。我們已經實現了一套廣泛的功能，構成了 Prometheus 簡單卻極其強大的監控哲學。

自那以後，我們新增並改進了各種服務發現整合，擴充套件了 PromQL，並對遠端 API 進行了首次迭代實驗，以支援可插拔的長期儲存解決方案。

但還有什麼其他變化值得釋出一個新的大版本呢？

發生了什麼

兩週前，來自世界各地的 Prometheus 使用者和開發人員匯聚慕尼黑，參加了關於 Prometheus 監控系統的第二屆會議 PromCon 2017 。本次活動的目的是交流知識和最佳實踐，並圍繞 Prometheus 監控建立專業聯絡。谷歌慕尼黑辦公室今年為我們提供了更大的場地，使我們的參會人數從 80 人增加到 220 人，而且門票依然售罄！

觀看回顧影片，感受一下本次活動的盛況

今天我們釋出了 Prometheus 2.0 的第三個 Alpha 版本。除了新儲存層中的各種錯誤修復之外，它還包含一些計劃中的重大變更。

命令列引數變更

首先，我們遷移到了一個新的 flag 庫，該庫使用更常見的雙橫線 -- 字首，而不是 Prometheus 迄今為止使用的單橫線。部署需要進行相應的調整。此外，此 Alpha 版本中刪除了一些 flag。自 Prometheus 1.0.0 以來的完整列表如下：

• web.telemetry-path
• 所有 storage.remote.* flag
• 所有 storage.local.* flag
• query.staleness-delta
• alertmanager.url

繼續我們的 Prometheus 使用者系列訪談，來自 L’Atelier Animation 的 Philippe Panaite 和 Barthelemy Stevens 將講述他們如何將動畫工作室的監控從 Nagios、Graphite 和 InfluxDB 的混合架構切換到 Prometheus。

能向我們介紹一下您自己以及 L’Atelier Animation 是做什麼的嗎？

L’Atelier Animation  是一家總部位於加拿大美麗城市蒙特利爾的 3D 動畫工作室。我們的第一部故事片 “Ballerina” （又名《飛躍奇蹟》）已於 2017 年在全球上映，預計今年晚些時候在美國上映。

我們目前正在努力製作一部動畫電視劇和我們的第二部故事片。  我們的基礎設施包括大約 300 臺渲染刀鋒伺服器、150 臺工作站和 20 臺各種伺服器。除了幾臺 Mac 之外，所有裝置都執行在 Linux（CentOS ）上，沒有一臺 Windows 機器。 

繼續我們的 Prometheus 使用者系列訪談，來自 iAdvize 的 Laurent COMMARIEU 將講述他們如何用 Prometheus 取代了傳統的 Nagios 和 Centreon 監控。

能向我們介紹一下 iAdvize 是做什麼的嗎？

我是 Laurent COMMARIEU，iAdvize 的系統工程師。我在一個由 60 人組成的研發部門中的一個 5 人系統工程師團隊工作。我們的工作主要是確保應用程式、服務和底層系統正常執行。我們與開發人員合作，確保他們的程式碼能以最簡單的方式進入生產環境，並在每一步提供必要的反饋。這就是監控的重要之處。

iAdvize 是一個全棧對話式商務平臺。我們為品牌提供了一種簡單的方式來集中與客戶互動，無論溝通渠道如何（聊天、電話、影片、Facebook 頁面、Facebook Messenger、Twitter、Instagram、WhatsApp、簡訊等……）。我們的客戶分佈在 40 個國家的電子商務、銀行、旅遊、時尚等行業 。我們是一家擁有 200 名員工的國際化公司，在法國、英國、德國、西班牙和義大利設有辦事處。我們在 2015 年融資了 1600 萬美元。

2016 年 7 月，Prometheus 隨著 1.0 版本的釋出達到了一個重大里程碑。自那以後，我們添加了許多新功能，例如新的服務發現整合和我們的實驗性遠端 API。我們還意識到，基礎設施領域的最新發展，特別是 Kubernetes ，使得被監控環境變得更加動態。不出所料，這也給 Prometheus 帶來了新的挑戰，我們發現其儲存層存在效能瓶頸。

在過去的幾個月裡，我們一直在設計和實現一種新的儲存概念，它解決了這些瓶頸，並顯示出整體效能的顯著提升。它還為新增熱備份等功能鋪平了道路。

這些變化是如此根本，以至於它將觸發一個新的重大版本：Prometheus 2.0。在其穩定版本釋出之前，我們計劃開發除儲存之外的其他重要功能和變更。然而，今天我們將釋出 Prometheus 2.0 的早期 Alpha 版本，以啟動新儲存的穩定化程序。

繼續我們的 Prometheus 使用者系列訪談，來自 Europace 的 Tobias Gesellchen 將講述他們是如何發現 Prometheus 的。

能向我們介紹一下 Europace 是做什麼的嗎？

Europace AG  開發並運營基於 Web 的 EUROPACE 金融市場，這是德國最大的抵押貸款、建房金融產品和個人貸款平臺。一個完全整合的系統連線了約 400 家合作伙伴——銀行、保險公司和金融產品分銷商。每月有數千名使用者在 EUROPACE 上執行約 35,000 筆交易，總價值高達 40 億歐元。我們的工程師定期在 http://tech.europace.de/  和 @EuropaceTech  發表部落格。

繼續我們的 Prometheus 使用者系列訪談，來自 Weaveworks 的 Tom Wilkie 將講述他們為什麼選擇 Prometheus，以及現在如何在此基礎上進行構建。

能向我們介紹一下 Weaveworks 嗎？

Weaveworks  提供 Weave Cloud  服務，該服務透過開源專案和軟體即服務的結合，將微服務“付諸運維”。

Weave Cloud 包括

• 透過 Weave Scope  實現視覺化
• 透過 Weave Flux  實現持續部署
• 透過容器 SDN Weave Net  實現網路連線
• 透過我們的開源分散式 Prometheus 即服務 Weave Cortex  進行監控。

您可以 免費試用 Weave Cloud 60 天 。有關我們產品的最新資訊，請檢視我們的 部落格 、Twitter  或 Slack （邀請連結 ）。

繼續我們的 Prometheus 使用者系列訪談，Canonical 將講述他們是如何過渡到 Prometheus 的。

能向我們介紹一下您自己以及 Canonical 是做什麼的嗎？

Canonical  最為人所知的身份大概是贊助 Ubuntu Linux 的公司。我們也開發或貢獻了許多其他開源專案，包括 MAAS、Juju 和 OpenStack，併為這些產品提供商業支援。Ubuntu 驅動了大多數 OpenStack 部署，其中包括 55% 的生產雲和 58% 的大型雲部署 。

我所在的團隊 BootStack 是我們的全託管私有云服務。我們為 Canonical 的客戶構建並運營 OpenStack 雲。

繼續我們的 Prometheus 使用者系列訪談，JustWatch 將講述他們是如何建立監控的。

能向我們介紹一下您自己以及 JustWatch 是做什麼的嗎？

對於消費者來說，JustWatch  是一個流媒體搜尋引擎，可以幫助人們在網上和影院中找到合法觀看電影和電視節目的地方。您可以搜尋 17 個國家的所有主要流媒體提供商（如 Netflix、HBO、Amazon Video、iTunes、Google Play 等）的電影內容。

對於我們的客戶（如電影製片廠或影片點播提供商）來說，我們是一家國際電影營銷公司，透過我們的消費者應用收集關於全球粉絲購買行為和電影喜好的匿名資料。我們幫助製片廠將他們的內容宣傳給目標受眾，並使數字影片廣告在減少無效覆蓋方面更加高效。

繼續我們的 Prometheus 使用者系列訪談，Compose 將講述他們從 Graphite 和 InfluxDB 走向 Prometheus 的監控歷程。

能向我們介紹一下您自己以及 Compose 是做什麼的嗎？

Compose  為世界各地開發人員提供開箱即用的生產級資料庫叢集託管服務。應用開發人員只需點選幾下滑鼠，即可在幾分鐘內準備好一個多主機、高可用、自動備份且安全的資料庫。隨後，這些資料庫部署會隨著需求的增加而自動彈性擴容，使開發人員可以把時間花在構建出色的應用上，而不是運維資料庫上。

我們在 AWS、Google Cloud Platform 和 SoftLayer 的每個平臺中至少兩個區域擁有數十個主機叢集。每個叢集在支援的地方都跨越多個可用區，並在其自己的私有網路中託管了大約 1000 個高可用資料庫部署。我們目前正在開拓更多的區域和供應商。

接下來在我們的 Prometheus 使用者系列訪談中，DigitalOcean 將講述他們是如何使用 Prometheus 的。Carlos Amedee 還在 PromCon 2016 上發表了關於 推廣過程中的社會學因素  的演講。

能向我們介紹一下您自己以及 DigitalOcean 是做什麼的嗎？

我叫 Ian Hansen，在平臺指標團隊工作。DigitalOcean  提供簡便的雲計算。到目前為止，我們已經在 13 個區域建立了 2000 萬個 Droplet（SSD 雲伺服器）。我們最近還發布了一款新的塊儲存產品。

繼續我們的 Prometheus 使用者系列訪談，ShuttleCloud 將講述他們是如何開始使用 Prometheus 的。來自 ShuttleCloud 的 Ignacio 還在 PromCon 2016 上解釋了 為什麼 Prometheus 適合小型初創公司 。

ShuttleCloud 是做什麼的？

ShuttleCloud 是全球最具擴充套件性的電子郵件和聯絡人資料匯入系統。我們幫助一些領先的電子郵件和通訊錄提供商（包括 Google 和 Comcast），透過資料匯入實現自動化遷移體驗，從而提高使用者增長和參與度。

透過將我們的 API 整合到其產品中，我們的客戶可以讓其使用者輕鬆地將電子郵件和聯絡人從一個合作提供商遷移到另一個合作提供商，從而減少使用者在更換新提供商時面臨的摩擦。支援的 24/7 電子郵件提供商包括美國所有主要的網際網路服務提供商：Comcast、Time Warner Cable、AT&T、Verizon 等。

透過為終端使用者提供一條簡單的郵件遷移路徑（同時保持對匯入工具 UI 的完全控制），我們的客戶大幅提高了使用者啟用率和留存率。

發生了什麼

上週，來自世界各地的 80 名 Prometheus 使用者和開發人員在柏林齊聚兩天，參加了有史以來第一次關於 Prometheus 監控系統的會議：PromCon 2016 。本次會議的目標是交流知識、最佳實踐以及使用 Prometheus 獲得的經驗。我們還希望壯大社群，幫助人們圍繞服務監控建立專業聯絡。以下是第一天早上的一些現場花絮

讓我們來聊聊一個特別根深蒂固的誤區。每當有人討論監控系統並提到 Prometheus 基於拉取的指標採集方法時，不可避免地會有人插話，稱基於拉取的方法“從根本上就無法擴充套件”。給出的理由往往含糊不清，或者僅適用於與 Prometheus 根本不同的系統。事實上，我們曾在極大規模下使用過基於拉取的監控系統，這種說法與我們自己的運維經驗背道而馳。

我們已經有一個關於為什麼 Prometheus 選擇拉取而不是推送的常見問題（FAQ）條目，但它並沒有專門針對擴充套件性方面進行闡述。讓我們仔細看看圍繞這一說法的一些常見誤區，並分析它們是否以及如何適用於 Prometheus。

今年 1 月，我們發表了一篇關於 Prometheus 開源公開第一年 的博文，總結了對我們來說一段美妙的旅程，也希望為您帶來了一個創新且有用的監控解決方案。自那以後，Prometheus 也加入了雲原生計算基金會（CNCF）， w 在那裡我們擁有良好的夥伴關係，是繼 Kubernetes  之後第二個被接納的專案。

我們最近的工作重點是提供穩定的 API 和使用者介面，其標誌就是 Prometheus 1.0 版本的推出。我們非常高興地宣佈，我們已經實現了這一目標，並且 Prometheus 1.0 今日正式釋出 。

1.0 版本的釋出對您意味著什麼？

如果您已經使用 Prometheus 有一段時間了，您可能已經注意到，在過去一年中，重大變更的頻率和影響已顯著降低。本著同樣的原則，達到 1.0 版本意味著後續的 1.x 版本將保持 API 的穩定性。升級不會破壞構建在 Prometheus API 之上的程式，更新也不會要求重新初始化儲存或更改部署。自定義儀表盤和告警在 1.x 版本更新中也將保持完好。我們相信 Prometheus 1.0 是一個可靠的監控解決方案。現在 Prometheus 服務端已經達到了穩定的 API 狀態，其他模組隨著時間的推移也將陸續推出它們自己的穩定版 1.0。

自 Prometheus 創立以來，我們一直在為該專案尋找一種獨立於任何單一公司的可持續治理模式。最近，我們一直在與新成立的雲原生計算基金會 （CNCF）進行討論，該基金會得到了 Google、CoreOS、Docker、Weaveworks、Mesosphere 以及其他領先基礎設施公司 的支援。

今天，我們激動地宣佈，CNCF 的技術監督委員會全票透過 ，接受 Prometheus 作為繼 Kubernetes 之後的第二個託管專案！您可以在 CNCF 的官方新聞釋出稿  中找到有關這些計劃的更多資訊。

Prometheus 服務的嵌入式時間序列資料庫（TSDB）將每個時間序列的原始樣本資料組織在大小固定為 1024 位元組的資料塊（chunk）中。除了原始樣本資料之外，資料塊還包含一些元資料，這允許為每個資料塊選擇不同的編碼。最根本的區別是編碼版本。您可以透過命令列引數 -storage.local.chunk-encoding-version 為新建立的資料塊選擇版本。到目前為止，只支援兩個版本：0 表示原始的差分編碼，1 表示改進的雙重差分編碼。在釋出 0.18.0  版本時，我們添加了版本 2，這是雙重差分編碼的另一種變體。我們稱之為 varbit 編碼，因為它涉及資料塊內每個樣本的可變位寬。雖然版本 1 在幾乎所有方面都優於版本 0，但在版本 1 和版本 2 之間確實存在權衡。這篇部落格文章將幫助您做出決定。版本 1 仍是預設編碼，因此如果您在閱讀本文後想嘗試版本 2，則必須透過命令列引數顯式選擇它。來回切換沒有壞處，但請注意，現有資料塊一旦建立就不會更改其編碼版本。然而，這些資料塊將根據配置的保留時間逐漸被淘汰，並因此被命令列引數中指定編碼的新資料塊所替換。

這是 Prometheus 使用者系列訪談的第二篇，旨在分享他們評估和使用 Prometheus 的經驗。

能向我們介紹一下您自己以及 ShowMax 是做什麼的嗎？

我是 Antonin Kral，目前負責 ShowMax  的研究和架構。在此之前，我在過去 12 年中一直擔任架構師和 CTO 的職務。

ShowMax 是一項訂閱型影片點播服務，於 2015 年在南非推出。我們擁有豐富的內涵目錄，包含超過 20,000 集電視劇和電影。目前，我們的服務在全球 65 個國家可用。當更為知名的競爭對手在美洲和歐洲激戰時，ShowMax 正在解決一個更棘手的問題：在撒哈拉以南非洲幾乎沒有網路連線的村莊裡，你如何追劇？雖然全球 35% 的影片已經透過流媒體播放，但仍有許多地方沒有被這場革命所觸及。

我們管理著大約 50 個服務，它們大多執行在基於 CoreOS 構建的私有叢集上。它們主要處理來自我們客戶端（Android、iOS、AppleTV、JavaScript、三星電視、LG 電視等）的 API 請求，其中一些服務則在內部使用。最大的內部管道之一是影片編碼，在處理大量攝入批次時，它可以佔用 400 多臺物理伺服器。

我們的大多數後端服務都是用 Ruby、Go 或 Python 編寫的。在用 Ruby 編寫應用時，我們使用 EventMachine（MRI 上的 Goliath，JRuby 上的 Puma）。Go 通常用於需要高吞吐量且業務邏輯不多的應用。對於用 Python 編寫的服務，我們對 Falcon 非常滿意。資料儲存在 PostgreSQL 和 ElasticSearch 叢集中。我們使用 etcd 和自定義工具來配置 Varnish 以進行請求路由。

這是 Prometheus 使用者系列訪談的第一篇，旨在分享他們評估和使用 Prometheus 的經驗。我們第一期訪談的物件是來自 Life360 的 Daniel。

能向我們介紹一下您自己以及 Life360 是做什麼的嗎？

我是 Daniel Ben Yosef，又名 dby。我是 Life360  的基礎設施工程師，在此之前，我在過去 9 年中一直擔任系統工程職位。

Life360 創造的技術可以幫助家庭保持聯絡，我們是專門為家庭設計的家庭網路應用。我們為這些家庭服務非常忙碌——在高峰期，我們每分鐘為 7000 萬註冊家庭處理 70 萬次請求。

我們在生產環境中管理大約 20 個服務，主要處理來自移動客戶端（Android、iOS 和 Windows Phone）的位置請求，高峰期跨越 150 多個例項。冗餘和高可用是我們的目標，我們努力保持 100% 的線上時間，因為家庭信任我們，需要我們保持隨時可用。

我們的使用者資料存放在 MySQL 多主叢集和 12 節點的 Cassandra 環中（任何時候都儲存約 4TB 的資料）。我們的服務是用 Go、Python、PHP 編寫的，並計劃在我們的技術棧中引入 Java。我們使用 Consul 進行服務發現，當然，我們的 Prometheus 配置也與之整合。

Alertmanager 處理由 Prometheus 服務端傳送的告警，並根據其標籤將關於這些告警的通知傳送給不同的接收器。

接收器可以是許多不同整合中的一種，例如 PagerDuty、Slack、電子郵件，或者透過通用 webhook 介面實現的自定義整合（例如 JIRA ）。

模板

傳送給接收器的訊息是透過模板構建的。Alertmanager 附帶了預設模板，但也允許定義自定義模板。

在這篇部落格文章中，我們將逐步介紹 Slack 通知的一個簡單自定義過程。

我們使用這個簡單的 Alertmanager 配置將所有告警傳送到 Slack

global:
  slack_api_url: '<slack_webhook_url>'

route:
  receiver: 'slack-notifications'
  # All alerts in a notification have the same value for these labels.
  group_by: [alertname, datacenter, app]

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'

預設情況下，由 Alertmanager 傳送的 Slack 訊息如下所示

它向我們展示了有一個正在觸發的告警，後跟告警分組的標籤值（alertname、datacenter、app），以及這些告警所共有的其他標籤值（critical）。

起源

一年前的今天，我們正式向外界宣佈了 Prometheus 的存在。這是一個回首過去、並與大家分享自那時以來該專案所經歷的一些奇妙事情的絕佳機會。但首先，讓我們從頭開始。

儘管我們早在 2012 年就已在 GitHub 上將 Prometheus 作為開源專案啟動，但起初我們並沒有對外聲張。我們希望給專案時間去成熟，以便能夠毫無阻礙地進行實驗。2013 年，Prometheus 逐步被引入到 SoundCloud  進行生產環境監控，隨後在公司內部得到了越來越多的使用，並且在 2014 年得到了我們在 Docker 和 Boxever 的朋友們的早期採用。這些年來，Prometheus 變得越來越成熟，儘管它已經解決了人們的監控問題，但它對廣大公眾來說仍然鮮為人知。

在上一篇文章中，我們介紹了在 Prometheus 中進行服務發現的許多新方法。自那以後，發生了很多變化。我們改進了內部實現，並收到了來自社群的極好貢獻，增加了對 Kubernetes 和 Marathon 服務發現的支援。它們將在 0.16 版本釋出時可用。

我們還涉及了自定義服務發現的話題。

並非每種型別的服務發現都足夠通用，可以直接包含在 Prometheus 中。你們公司很可能有一套專有的系統，你只需要讓它能與 Prometheus 配合工作。這並不意味著你不能享受自動發現新監控目標的好處。

在這篇文章中，我們將實現一個小工具程式，它將基於高一致性分散式鍵值儲存 etcd  的自定義服務發現方法連線到 Prometheus。

編者按：本文是一篇由 Prometheus 使用者撰寫的客座博文。

如果您正在為成千上萬苛刻的遊戲玩家執行網路，您需要真正瞭解網路內部正在發生什麼。哦，而且所有東西都需要在短短五天內從頭開始構建。

如果您以前從未聽說過 DreamHack ，這裡有個介紹：將 20,000 人聚集在一起，其中大多數人都會自帶電腦。融入專業電競、程式設計比賽和現場音樂會。其結果就是世界上最大、專門致力於一切數字科技的節日。

要使這樣一個活動成為可能，需要部署大量的的基礎設施。通常這種規模的基礎設施需要幾個月的時間來構建，但 DreamHack 的團隊在短短五天內就從頭開始構建好了一切。這當然包括配置網路交換機等內容，但也包括構建電力分配系統、設立餐飲店、甚至搭建實際的桌子。

構建和運維所有網路相關內容的團隊官方名稱為網路團隊，但我們通常稱自己為 tech 或 dhtech。這篇文章將重點介紹 dhtech 的工作，以及我們在 2015 年 DreamHack 夏季活動期間如何使用 Prometheus 試圖讓我們的監控水平再上一個臺階。

在其《致監控/指標/告警公司的公開信》 中，John Allspaw 斷言，試圖“完美、並在正確的時間檢測到異常是不可能的”。

我見過幾位才華橫溢的工程師試圖構建系統來根據時間序列資料自動檢測和診斷問題。雖然將一個演示版執行起來確實是可行的，但資料往往總是過於嘈雜，使得這種方法除了最簡單的現實系統之外，根本無法發揮作用。

不過，也並非毫無希望。你可以透過自定義規則來檢測和處理許多常見的異常。Prometheus 查詢語言為您提供了發現這些異常並同時避免誤報的工具。

本週我們釋出了 Prometheus v0.14.0——該版本包含許多期待已久的新功能和改進。

在使用者方面， Prometheus 現在支援新的服務發現機制。除了 DNS-SRV 記錄之外，它現在還開箱即用支援 Consul ，而基於檔案的介面允許您連線自己的發現機制。隨著時間的推移，我們計劃向 Prometheus 新增其他常見的服務發現機制。

除了許多較小的修復和改進之外，現在您還可以在執行時透過向 Prometheus 程序傳送 SIGHUP 訊號來重新載入配置。如需完整的變更列表，請檢視該版本的變更日誌 。

在這篇部落格文章中，我們將更仔細地研究內建的服務發現機制並提供一些實用的例子。作為附加資源，請參見 Prometheus 配置文件。

自我們公開宣佈 Prometheus 0.10.0 版本以來，已經過去了近三個月，我們現在的版本是 0.13.1。

SoundCloud 的釋出宣告博文  仍然是 Prometheus 關鍵元件的最佳概述，但網際網路上圍繞 Prometheus 還有很多其他活動。這篇文章將讓您瞭解可能錯過的任何資訊。

未來，我們將利用此部落格釋出更多文章和公告，以幫助您充分利用 Prometheus。