*作者：夏明*

## 應用架構與可觀測技術演進歷程

![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/70aa14048d904e0085027a14b91d3b32~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

在軟體開發早期，單體應用架構因其結構簡單，便於測試和部署，得到了廣泛的應用，對應的監控診斷技術主要是基於日誌和日誌關鍵詞的指標監控。隨著軟體複雜度的不斷提升，單體應用架構逐步向分散式和微服務的架構演進，整體的呼叫環境也越來越複雜，僅靠日誌和指標漸漸難以快速定位複雜環境下的問題。

因此，鏈路追蹤技術應運而生。但早期的鏈路追蹤技術和日誌指標的結合比較簡單，更多的是在應用層以 APM 軟體的形式存在。

隨著雲端計算和雲原生理唸的普及，從業務層到應用層，容器和基礎設施之間的邊界不斷地被打破，研發、運維、安全等工種的職責也不斷模糊，因此對於全棧可觀測的訴求也變得愈加強烈，Traces、Metrics 和 Logs 的連線也愈發緊密。

## 一個典型的雲原生架構及可觀測訴求

![2.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/65a72ae30f2942cba80847d4b365edbb~tplv-k3u1fbpfcp-zoom-1.image "2.jpeg")

典型的雲原生架構往往是混合雲的形態，出於安全或容災等方面的考慮，可能會將一部分應用部署在公有云，另一部分部署在自建機房。而出於軟體研發效率和效能的考慮，不同的應用又可能採用多種開發語言，因此可觀測訴求可以被歸納為以下四點：

1、**全棧立體化統一監控與告警**：比如可以將業務層的交易量、支付量的業務指標和應用黃金 3 指標、基礎設施的 CPU 利用率以及網路情況，放在一張大盤上做總體監控，這也是大促期間較為常用的方式。

2、**前後端/多語言全鏈路追蹤**：使用者請求從端上發起，一直到閘道器，再到後端的應用和雲元件之間呼叫軌跡的追蹤，可以快速定位使用者請求在哪裡有異常。

3、**跨雲資料統一視覺化**：將不同型別的資料、不同環境的資料進行統一視覺化，需要有較強的視覺化元件。

4、**開源格式資料二次加工**：出於業務自定義的需求，需要有二次加工與分析。如果能夠基於開源的資料格式標準，很多工作實施起將會比較輕鬆，也可以複用很多現有的東西。

## 為什麼要基於 OPLG 構建統一可觀測平臺

![3.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ce517eadba4f49009feee407dd51ed2e~tplv-k3u1fbpfcp-zoom-1.image "3.jpeg")

而傳統的監控診斷平臺往往存在以下幾個痛點：

1、很多埋點插樁由使用者自己實現，這種閉源實現會導致資料格式不統一，而且埋點在各個系統之間很難複用，接入成本非常高。

2、Metrics 指標孤立地分散在各個監控的子系統，比如有的在網路，有的在應用，有的在容器。排查全鏈路問題時，對開發使用人員的經驗要求非常高，且效率非常低。

3、Traces 會由於埋點覆蓋度不夠或協議不統一而無法串聯，導致經常出現斷連。

4、日誌或鏈路資料的明細資料全量上報到服務端，也會帶非常高的成本，而且查詢率較低，還會引發熱點的效能瓶頸。

5、自建控制檯的前端開發成本高，開發週期長，靈活性較差，很難跟上業務迭代的效率。

6、各個系統的可觀測資料之間缺乏統一的標籤管理，關聯性較差，很難做綜合性的分析。

為了解決上述問題，我們在生產環境中逐漸沉澱下較為可行的方案，即基於 OPLG 建設統一可觀測平臺。此方案主要有以下幾點優勢：

1、**開源開放**：全開源技術棧，藉助社群共建合力，比如可以藉助 OpenTelemetry 的 Traces 埋點，Prometheus指標的 Metrics Exporters ，無需過多開發，即可保障大部分通用元件資料的採集生成上報，降低了接入成本。

2、**統一目標**：開源且基於統一的一套規範，可以很輕鬆地實現內部各個子系統甚至是和外部三方系統之間的打通和關聯分析。

3、**自由靈活**：基於 OPLG 特別是 Grafana 一些比較好的設計，可以非常靈活地組織可觀測資料，能夠靈活地定製每一個場景下需要的大盤圖表，滿足自定義的需求。

4、**邊緣計算**：基於 OpeTelemetry Collector技術，可以將資料處理“左移”到使用者叢集內。透過邊緣計算的技術，能夠提前提煉資料價值，並將提煉好的資料再傳送到服務端，降低公網傳輸的成本以及服務端的儲存成本。

## 基於 OPLG 構建雲原生可觀測平臺方案

![4.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/19185df7703f4d1283de1457a68e2dae~tplv-k3u1fbpfcp-zoom-1.image "4.jpeg")

OPLG 主要由以下四個模組構成：

1、**端側資料生成與上報**：透過 OpenTelemetry 完成 Traces 資料的生成，透過 Prometheus 完成指標類的資料，透過 Loki 的方式完成日誌採用。

2、**邊緣側資料統一處理與路由**：所有資料採集完成之後，可以透過 OpenTelemetry Collector 完成資料統一的邊緣處理和路由轉發。

3、**全託管服務端**：能夠提供更好的效能和更穩定的服務，而且不會繫結技術棧，遷移的自由度和靈活度高。

4、**統一視覺化**：可以透過 Grafana 完成統一的自定義靈活監控，也可以採用雲服務商比如 ARMS 在特定的精細化互動場景提供精細化的互動大盤，提高查詢體驗。此外，如若有自己的需求，也可以透過開源的資料格式或開放的 OpenAPI 建設自己的控制檯。

## 基於 OpenTelemetry Collector 實現統一資料採集與邊緣計算

![5.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d4a5863056b42a09a6e0357f99f7507~tplv-k3u1fbpfcp-zoom-1.image "5.jpeg")

OpenTelemetry Collector 首先會完成統一的資料採集，任何資料型別都可以進行資料採集，然後做通用的處理，比如格式化、資料的標籤打標，還可以進行一些指標的預聚合動作，最常見的比如呼叫鏈，可以根據 service IP 等粒度先將資料聚合再進行取樣，可以保證指標的精準度，而且上傳到服務端也可以降低成本。

OpenTelemetry Collector 還可提供本地儲存的能力，可以將一部分最近的資料先臨時快取，然後進行比如最近 10 分鐘的全量查詢、錯慢全採等，可以更好地利用邊緣的儲存能力。

針對處理好的資料， OpenTelemetry Collector 提供了非常靈活的轉發方式，可以支援不同的協議，比如 Prometheus 協議、OTLP 協議等，也可以支援多資料來源的轉發，可以傳送到雲服務端，也可以轉存到邊緣儲存，更加靈活。

## 基於 ARMS 託管服務端提供快速、穩定的查詢體驗

![6.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/111b62e2755e4424a7b19b5ed81224bb~tplv-k3u1fbpfcp-zoom-1.image "6.jpeg")

基於 ARMS 的託管服務端針對海量的資料場景做了很多查詢效能最佳化加速的技術，比如透過運算元下推的方式，在 70% 以上的場景下查詢效能相對於開源提升了 10 倍以上；而針對 7-10 天等的長週期查詢，透過降取樣技術又進一步地提升了一個數量級的查詢效能；針對 URL 等發散維度，透過自動收斂的技術很好地解決了熱點導致的查詢卡頓問題；針對鏈路資料，做了對應用和 Traces ID 兩級的路由掃描，針對鏈路查詢的使用特徵做了相應的最佳化。

除了海量資料的查詢效能最佳化外，我們在 HA 側也做了體系化的建設，比如預設支援全球部署、多可用區的容災，避免了單個 region 或 AZ 不可用的風險；其次業務經常會遇到突發的流量或使用者快速增長，如果是自建機房則需要考慮容量問題，而使用 ARMS 可以根據流量自適應地做擴充，無需擔心突發流量帶來的效能瓶頸；極端情況下，也可以透過動態配置下推或自動流控降級保障核心功能的可用性；最後，提供了全鏈路 SLA 監控和預警的建設，有 7*24 小時的應急響應，可及時發現可用性問題並快速恢復。

## 基於 Grafana+ARMS 構建靈活、精細的視覺化介面

![7.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4566064deaff452c8c26f62c10d8d934~tplv-k3u1fbpfcp-zoom-1.image "7.jpeg")

此外，基於 Grafana +ARMS 提供了靈活、精細的視覺化體驗。

Grafana 豐富的儀表盤外掛和廣泛的資料來源支援，可以將各種資料都整合在一個大盤裡。而且透過 PromQL、LogQL 等靈活的查詢語法，不需要前端介入。後端的研發，測試，SRE 等可以透過低程式碼的形式快速構建自己的場景大盤，提升可觀測的效率。

得益於 Grafana 的開源屬性，如果想從自建機房遷移到雲上，或在雲之間互相遷移，整個視覺化平臺都能夠透過 JSON 檔案或其他方式快速複製，輕鬆完成端到端的遷移，不會被特定的廠商強繫結。

但是 Grafana 也存在缺陷，比如它在互動場景的體驗不夠好，因此 ARMS 在呼叫鏈的關聯分析、線上診斷、配置管理等強互動的場景提供了更精細化的互動頁面。ARMS 還會進一步增強 Grafana 的圖表外掛，提供新的圖表外掛以提升託管版 Grafana 的視覺化能力。

### Demo 演示 1：如何基於 OpenTemeletry 和 ARMS 實現全鏈路的追蹤和應用診斷

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2978b50ebf246faa40bd8fa24b9f1e4~tplv-k3u1fbpfcp-zoom-1.image "8.png")

進入 ARMS 控制檯-接入中心，找到 OpenTelemetry 的接入方式（也可以選擇其他的接入方式）。以 Java 應用為例，可以透過 OT Java Aagent 生成資料，然後修改啟動引數，比如接入點或鑑權的 token 。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aa9f95428fcc4ccca9d24cf744baa83d~tplv-k3u1fbpfcp-zoom-1.image "9.png")

除了直接上報，也可以透過 OT Collector 完成資料轉發，實現無損統計，只需要將 endpoint 改成本地服務。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/642c40a474ee4e72b1fac8db3bcdd202~tplv-k3u1fbpfcp-zoom-1.image "10.png")

安裝完成後，即可透過 ARMS 提供的 Traces Explorer 頁面進行呼叫鏈的分析。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ad37a54dc18d4674a148f437ee8e2b5e~tplv-k3u1fbpfcp-zoom-1.image "11.png")

呼叫鏈的分析是強互動場景，比如可以透過左側的快捷篩選快速過濾出異常呼叫鏈路，然後選擇其中一條鏈路檢視端到端的全鏈路軌跡。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/efd2e9c970a44362a228348d827f3649~tplv-k3u1fbpfcp-zoom-1.image "12.png")

ARMS 在 Java 場景針對介面粒度做了更詳細的本地方法埋點，能夠更好地定位根因。上圖右側可以看到當前 span 相關的附加資訊，包括 JVM 和主機的監控指標。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c156bb05d4864c7e933b4ec4062a6415~tplv-k3u1fbpfcp-zoom-1.image "13.png")

與 span 相關的應用日誌也能很快速地整合，排查業務問題可以結合日誌更好地定位。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a10ebb0950d48e9b71320355a5a2354~tplv-k3u1fbpfcp-zoom-1.image "14.png")

Traces Explorer 除了呼叫鏈的查詢外，也可以做實時的動態分析。比如可以檢視異常鏈路是否集中在某特定 IP ，是否存在單機故障的可能性，或是否集中在特定的介面。也可以將很多呼叫鏈進行全鏈路的聚合，多條鏈路可以看到每一個分支的情況，也可以看到應用維度更直觀的拓撲。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0378ccd84658442bb94e928ad545eb55~tplv-k3u1fbpfcp-zoom-1.image "15.png")

此外，ARMS 還針對 Java 提供了較好的互動圖表。除了 JVM 監控、主機監控外，還包括容器的 Pod 監控、執行緒池監控等。業務高峰期很容易出現資料庫連線池打滿等情況，以往此類問題難以排查.但有了池化監控，即可一眼定位到問題所在。透過上下游的分析，能夠很輕鬆地獲知當前應用呼叫方的情況。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6aef9f238a4747589f9c4d8832d9e778~tplv-k3u1fbpfcp-zoom-1.image "16.png")

在資料庫呼叫裡可以看到 SQL 的明細統計以及快取的操作情況。

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/44629a599c214574af37a24b92a3ae22~tplv-k3u1fbpfcp-zoom-1.image "17.png")

ARMS 還提供了高階的診斷能力，比如執行緒分析，可以針對每一類執行緒池觀察執行緒消耗的 CPU 、耗時以及執行緒數，也可以檢視方法棧。

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f8f5caec32af4b5489775db688e60b8d~tplv-k3u1fbpfcp-zoom-1.image "18.png")

針對 Java 應用的疑難問題，可以透過白屏化的 Arthas 診斷實時抓取捕獲 JVM 執行態的資料，比如檢視方法呼叫的軌跡、引數。

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a28569b691db44e1b66ea7c8ea3686a2~tplv-k3u1fbpfcp-zoom-1.image "19.png")

除此之外，還可將 APM 的指標資料寫到 Prometheus，透過 Grafana 做展示。使用者可以透過 PromQL 定製自己想要的 APM 大盤，可以將 APM 資料和其他指標資料比如業務、基礎設施、雲元件、資料庫服務端、容器等放在一起，定製自己的大盤形態。

### Demo 演示 2：:如何基於 Prometheus 和 Grafana 做統一的監控和告警

首先，在接入中心選擇要接入的元件，有 MySQL 、Redis 、ES 等，預設支援阿里雲上的很多元件。

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1701b6340c1944cfb1cbc27981cbaf0b~tplv-k3u1fbpfcp-zoom-1.image "20.png")

以 MySQL 為例，首先選擇要接入的例項，填寫 exporter 名稱，選擇地址，再寫入使用者密碼，此處也可以檢視當前 exporter 採集的指標。

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/59cbf3eedc2841ae8c0582bae9d9ba5a~tplv-k3u1fbpfcp-zoom-1.image "21.png")

如果例項未接入，可以選擇新建例項。比如針對 ECS 環境或自建機房，可以透過下載 ARMS 提供的 helm 安裝 Prometheus Agent ，也可以透過 Remote Write 的方式直接上報資料。如果希望將多個地域的資料來源放在一起檢視，也可以透過 Global View 全域性介面例項將多個資料進行統一展示。

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2e67d573f2ad45f798a723ecac1a8296~tplv-k3u1fbpfcp-zoom-1.image "22.png")

進入整合中心後，可以看到當前例項已經安裝的元件，可以檢視元件採集的指標，可以更精細化地選擇哪些指標需要採集，哪些不需要。

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/435a5f4e5ad14dd2832a050621d6a064~tplv-k3u1fbpfcp-zoom-1.image "23.png")

大盤列表裡，ARMS 提供了非常多預置的 Grafana 大盤，比如 K8s 的總覽檢視或 node 詳情檢視，可以檢視當前節點各種狀態，使用者也可以基於檢視自己編輯新的圖表。

![24.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7fd6cfdc2ca247339c322f030c094516~tplv-k3u1fbpfcp-zoom-1.image "24.png")

因為資料都寫到 Prometheus，所以告警也可以基於 PromQL 擴充套件。我們提供了很多預設的告警模板，比如節點的 CPU 使用率等。除了可以定製告警內容，還可以選擇通知策略，比如不同的告警發給不同的值班人員。

Grafana ARMS 提供了兩種型別的 Grafana，分別是共享版本和託管的獨佔版本。我們更推薦開通獨佔的託管版本，可以做自定義的賬號管理，也可以得到更好的可用性和安全性保障。

### Demo 演示 3：基於 Loki 的日誌查詢分析

由於 ARMS 目前還沒有提供商業化的 Loki 服務，因此本文將以官網的 Grafana 示例演示 Loki 的接入效果。

![25.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8a98f7c036d3472a895dd548bd02953d~tplv-k3u1fbpfcp-zoom-1.image "25.png")

完成日誌接入之後，可以基於 Loki 提供的 LokiQL 快速過濾。它還針對關鍵的索引欄位建立了索引，基於這些欄位可以進一步提升檢索速度。

![26.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f2d0c65e1df8487fbc0d45fab25ea723~tplv-k3u1fbpfcp-zoom-1.image "26.png")

基於 Loki 可以定製形態較為豐富的圖表。上圖為官網提供的 Loki Nginx 大盤，統計的數值或地域的分佈等都可以透過 LogQL 定製，非常靈活。

### Demo 演示 4：基於 RASP 的應用安全防護

-   **危險元件檢測**

![27.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ceb19669442e48f7b5a74f039a13b4f8~tplv-k3u1fbpfcp-zoom-1.image "27.png")

應用接入 RUSP 之後，可以自動根據 cve 標準掃描出當前應用是否存在危險元件，能夠快速提示應用當前可能存在的風險。

![28.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/08c401bea50746d591c5beec2d31e0e7~tplv-k3u1fbpfcp-zoom-1.image "28.png")

可以檢視例項詳情和漏洞詳情，包括具體的漏洞描述以及相應的修復方案，根據這個修復方案，即可完成漏洞修復。

除了已知的危險元件，也可以基於還未上報或特有的元件做全量元件自查。

-   **應用安全的攻擊防護**

![29.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/be193ae217a34c0bbd02f3de7d8de207~tplv-k3u1fbpfcp-zoom-1.image "29.png")

遭到惡意攻擊後，系統能夠自動識別出當前存在的惡意攻擊行為，且可以看到攻擊發生在哪個節點以及請求的引數和呼叫攻擊的堆疊情況。

除了攻擊識別外，還可以做主動防護，將防護模式從監控設定為監控並阻斷。

![30.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/51705495b10a4c4c83827ed072660dd6~tplv-k3u1fbpfcp-zoom-1.image "30.png")

修改防護模式後，針對最新的攻擊行為，平臺不只進行監控，還能夠將它直接阻斷，不影響業務的具體邏輯。同時丟擲異常，提示當前風險行為已經被阻斷。

### Demo 演示 5：ARMS 提供的使用者體驗監控

![31.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9014e454e4d14b8c9b62630d653c36e1~tplv-k3u1fbpfcp-zoom-1.image "31.png")

在接入中心，可以針對不同型別的端側裝置進行監控。以 web 端為例，可以新建站點，選擇相應的配置，然後透過 CDN 或 NPM 包的方式完成接入。

![32.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/caa2eb59148347caa716131a66c4c52d~tplv-k3u1fbpfcp-zoom-1.image "32.png")

接入完成後，可檢視當前控制檯 PV、UV 以及 API 的請求成功率，並且可以看到請求分佈在哪些地理位置、運營商或瀏覽器。

![33.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/23e586358a804dd2a71f4aa44cd88330~tplv-k3u1fbpfcp-zoom-1.image "33.png")

比如新開發了功能頁面，可以檢視頁面 top 20 使用者訪問的情況，也可以選擇具體的使用者，透過會話追蹤檢視使用者如何使用此產品，能夠更好地觀測使用者行為。

![34.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e4f23592fd9248f6aa8e5b2d7ad803f2~tplv-k3u1fbpfcp-zoom-1.image "34.png")

應用前端監控還可以與撥測結合使用，可以透過撥測模擬真實的使用者行為，對網站質量、網頁效能、檔案下載或 API 的效能做模擬，提前發現問題，先於使用者感知到可能存在的風險。發現可用性出現異常後，可以針對不同的站點自動傳送通知。

![35.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3fce8357fa8041d0a4e51e1cf89dda18~tplv-k3u1fbpfcp-zoom-1.image "35.png")

上圖為已建立的 demo 任務，可以觀測到網站的時延、丟包率以及每一次撥測的狀態和結果，並且透過多維的報告檢視問題聚焦在哪些地區等。

雖然 OPLG 並不能覆蓋所有可觀測領域，但它為可觀測提供了非常良好的底座和規範。在這套體系的基礎之上，可以不斷地將其他可觀測技術或產品能力整合進來，滿足各種場景的可觀測訴求，從而應對愈加複雜多變的環境帶來的挑戰。

## 雲原生時代可觀測技術的趨勢與技術選型

![36.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9b33c217cf0c42129aca70692e1f2160~tplv-k3u1fbpfcp-zoom-1.image "36.jpeg")

雲原生時代的可觀測技術，在軟體架構層面會更多地向分散式雲和混合雲的方向發展。同時容器化、微服務、 DevOps 甚至 DevSecOps 也將逐漸成為主流。

可觀測技術趨勢包括以下幾個方面：

1、**標準逐漸成型收斂**。技術棧會向 OpenTelemetry、Prometheus 等方向收斂。而基於更加標準的資料，自動化的成本將會更低，效率將會更高。分層之間的監控邊界被打破之後，監控立體化也將愈發成熟。

2、**基於 eBPF 的網路和核心的無侵入探測**，帶來更多觀測技術的可能性。

3、**去** **中心化趨勢**。首先，資料去中心化，比如基於 OpenTelemetry Collector 可以將很多可觀測的預處理左移到使用者叢集內，降低中心化服務端的壓力。其次，協同去中心化，不僅可以在統一的控制檯檢視可觀測資料，也可以在即時通訊軟體比如釘釘完成整個協作的過程。

## 更多產品限時特惠

![37.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/78a9a64846314900b96beafb60fab8f6~tplv-k3u1fbpfcp-zoom-1.image "37.jpeg")

點選[此處](https://www.aliyun.com/product/arms)，檢視更多雲原生可觀測相關資訊~

基於 OPLG 從 0 到 1 構建統一可觀測平臺實踐

相關文章