深度揭秘！觀測雲産品核心理念

        【每日科技網】

　　引言

　　我是蔣爍淼，觀測雲的首席技術架構師兼産品把控者。今天，我有幸與大家分享我們團隊在設計和實現産品過程中所堅持的核心理念。這些理念不僅是我們工作的指導燈塔，更是推動我們技術不斷進步的動力源泉。

　　在觀測雲，我們堅信，一個産品的強大生命力和競争力，源自于其内在的哲學和理念。作為團隊的領航者，我帶領着每一位成員，堅守着這些核心理念。它們是我們設計和實現産品的基石，是我們在技術發展道路上的指南針。

　　以工程師們為中心

　　觀測雲是一款面向企業級市場的監控觀測産品，旨在滿足最終用戶的需求 。我們認識到，産品要想擁有持久的競争力，就必須得到工程師們的認可，使用便捷，并能為他們創造價值。通過提升工程師的工作效率，我們相信最終客戶也将從中受益。

　　在傳統監控産品中，設計往往以運維人員的需求為主，涵蓋儀表盤、告警、數據接入等多個方面。然而，觀測雲的設計理念有所不同。舉幾個例子：

　　觀測雲的 Agent 模型采用了類似 OpenTelemetry 的架構，将 Instrumentor(探針)和 Collector(Agent)分離，完全不同于傳統的 APM 廠商。

　　該架構設計具有多項優勢，在此僅列舉一個關鍵好處。我們認識到，無論是使用 eBPF 探針還是傳統字節碼探針，都可能對應用程序産生一定影響。同時，為了不斷增強監控能力，探針和 Agent 可能需要定期升級。這種架構允許研發團隊獨立驗證探針的穩定性和數據字段的擴展性，而運維團隊則負責 Agent 的升級和配置調整。通過分離探針和 Agent，Agent 的升級不會幹擾應用程序的正常運行，最多隻會導緻數據暫時不可用。在應用程序升級過程中，我們确保其與探針的兼容性已在測試環境中得到驗證，從而避免了因探針升級不當而導緻的整個業務系統的故障風險。

　　此外，這種架構還提高了系統的兼容性，能夠支持多種 Instrumentor，包括但不限于探針、日志采集器以及 Prometheus 生态系統的集成。

使用觀測雲的用戶将深刻體會到其賦予的廣泛自由度，這不僅僅體現在随心所欲地設計個性化儀表盤、靈活配置數據結構、自定義查詢模闆，以及獨創性地設計告警策略上。我們深刻理解研發工程師的微妙心理需求，因此在多處功能設計中巧妙地融入了“僅我可見”的選項，旨在為工程師們提供一個私密的空間，讓他們能夠安心地進行自我調試、儀表盤分析，而無需擔心被他人窺探 。這種貼心的設計，正是出于對研發者心理的深刻洞察與尊重，它鼓勵了更自由、更無拘束的創新實踐，從而真正釋放了可觀測性能力的潛力，為項目帶來實質性的價值提升。 前面的模型示例不僅簡化了研發流程，還賦予了他們在探針中自由擴展字段、深化業務洞察的能力，從而助力構建更為精準和全面的分析體系。衆多觀測雲用戶反饋，相較于某些标榜為AIOps的産品，我們的解決方案在功能強大性、AI 分析能力上更勝一籌，卻謙遜未以此為核心賣點。原因在于，我們堅信算法的真正價值遠不止于運維(Ops)，它應廣泛滲透于離群分析、異常檢測等各個環節，賦能研發團隊。這不僅僅意味着監控 CPU 行為異常，更關乎于深入理解代碼調用在不同場景下的異常表現。

　　過分渲染 AIOps 概念的産品，往往陷入誇大其詞的誤區，而真正出色的産品則是将這些能力無縫融入日常研發運維流程中，成為他們工具箱中不可或缺的一部分。我們緻力于讓技術回歸本質，為用戶提供實實在在的價值，而非空泛的概念炒作。

我們對觀測雲的細緻打磨體現在諸多方面，例如時間控件的靈活性。我們支持直接輸入unixtime，簡化了工程師在時間轉換上的繁瑣操作，避免了使用 Linux 命令或在不直觀的日曆控件中進行選擇。這種對細節的關注是許多同類産品所忽視的。

　　觀測雲的更新頻率為每兩周一次，這不僅是為了引入新功能，更重要的是，我們緻力于根據用戶的真實反饋來優化産品 。這些更新可能涉及大量的細節改進，雖然無法一一列舉，但它們共同構成了我們對産品不斷改進的承諾。我們相信，真正使用觀測雲的用戶能夠從這些細節中感受到我們的專注和誠意。

做一個開放的産品

　　我對開源的态度是明确的：我支持真正的開源精神，即開放代碼并與全球開發者進行交流。然而，我反對那些以開源為名，實則追求商業利益而忽視社區和技術發展的“僞開源”行為。觀測雲在這一點上采取了開放的姿态，我們公開了所有端側代碼，并在 Github 上維護着數十個開源項目。我們鼓勵團隊成員積極參與開源社區，發現問題時提交 Pull Request(PR)，以促進相關項目的進步。

　　同時，我們也持續為開源項目如 Victoriametrics 貢獻代碼。盡管觀測雲是一個商業産品，我們依然堅持開放的原則，但這種開放是有選擇性的。我們的目标是提供一個既開放又可控的環境，确保産品的穩定性和安全性。

我們緻力于整合開源技術，以增強觀測雲的功能。我們全面支持現有的觀測技術框架，例如與 Prometheus 生态系統的深度集成。我們的系統不僅能夠收集 Prometheus 的各種數據類型，包括 Exporter 和 Push 數據，而且在 Push 數據支持方面，我們在穩定性和性能上均超越了 Prometheus 官方的 Push Gateway。此外，我們還加強了對 Prometheus 自發現功能的支持。

　　在日志采集方面，我們兼容多種日志生成方式，例如支持 Log4J 通過 Socket 直接發送日志，避免了日志寫入磁盤的需要。這種支持使得在性能要求極高的場景下，開發者也能夠高效地收集大量日志數據。

　　對于分布式追蹤(Tracing)，我們同樣提供了廣泛的支持，兼容了包括 ddtrace、OpenTelemetry、Zipkin、SkyWalking 以及 Jaeger 等多種追蹤協議。這些開源方案在不同應用中可能采用不同的實現，導緻分析上的分散。觀測雲通過統一的集成方式，使得這些不同來源的數據在使用上保持一緻性，仿佛它們是專為觀測雲設計的一樣，盡管它們采集的數據内容可能各有差異。

同樣，我們對開源技術的承諾不僅體現在支持 eBPF tracing 上，更在于我們将其開源，以促進統一标準的形成。與國内其他開源廠商不同，我們緻力于生成符合 OpenTelemetry 标準的 span 和 trace。這意味着使用觀測雲采集的 eBPF 數據能夠與其他技術方式接入的數據一同分析，無需額外的後台系統或專用數據庫存儲集群。

　　在技術文檔方面，我們緻力于開放和透明的分享 。觀測雲在技術文檔的公開程度上，自信地處于行業地位。我們公開了大量的技術實現細節，以便于業界同仁學習和參考。

　　用認知驅動取代需求驅動

　　對于熟悉觀測雲的老朋友或初次接觸的新朋友而言，或許已知曉或未曾留意到這樣一個事實：觀測雲不僅提供雲端服務，實現全球無縫接入，同時也支持靈活的私有化部署方案，以滿足不同用戶的特定需求。然而，鮮為人知的是，觀測雲在産品開發上堅守着一個重要原則——我們從未為任何單一客戶定制産品 。從中國的本土版本到海外的國際市場，再到那些部署于客戶私有環境中的定制化方案，盡管部分版本因市場策略或技術疊代進度略有差異，但觀測雲始終如一，堅持為所有用戶提供統一、标準的産品體驗。

　　這是我們的堅持。為什麼呢?

　　首先，觀測雲堅守為客戶負責的原則 。在快速疊代的産品環境中，我們深知保持産品主線的重要性。定制化産品雖看似能即時滿足特定需求，但長遠來看，它們往往與主線版本分離，形成分叉，這不僅損害了客戶的長期利益，也增加了我們維護産品體驗的難度。因此，我們堅決避免任何形式的版本分叉，确保每位客戶都能享受到持續、穩定且高效的産品服務。

　　其次，我們注重有價值需求的快速響應與标準化 。在快速疊代的過程中，我們深知客戶需求的多樣性與複雜性。然而，并非所有需求都能直接轉化為産品功能，特别是當這些需求存在邏輯悖論或表述不清時。作為産品專家，我們傾聽客戶聲音，結合産品架構與行業洞察，将特定需求轉化為标準化的産品功能。這種負責任的做法不僅提升了産品價值，也加深了我們對産品行業的認知，而這些認知又反過來推動我們不斷優化産品，形成良性循環。我們的更新速度遠超客戶自行探索開源方案的效率，确保研發運維工程師們能夠輕松、高效地使用我們的平台。

　　最後，我們緻力于産品的開放性與靈活性 。為了滿足用戶多樣化的個性化需求，我們努力實現各種技術棧的标準化集成，而非依賴定制化。通過構建豐富的靈活性機制，我們完整打造了一整套架構體系，以應對更廣泛的業務場景和需求。這種高度定制化的靈活性要求我們不能簡單地采用開源産品拼湊而成，而是需要自主設計數據引擎、數據庫及UI框架等核心組件，從而确保産品的整體性能和用戶體驗。這種從底層到上層的全面掌控，使得我們的産品能夠靈活應對各種挑戰，為用戶創造更大的價值。

　　觀測雲是我們團隊精心打造的産品，它不僅承載着我們的技術追求，更融入了我們的價值觀。我們緻力于持續優化和完善産品，以确保它能夠為用戶帶來實際的價值。我們的目标是讓觀測雲在企業中發揮關鍵作用，特别是對于工程師團隊。我們相信，通過不斷的努力和創新，觀測雲能夠提升工程師的工作效率，增強企業的運營能力。我們的目标不僅是滿足用戶當前的需求，更是預見并引領未來的技術趨勢，從而為企業帶來長遠的價值。