​
作者｜張安哲（落羽）
來源｜爾達Erda公眾號

導讀：為了讓大家更好的瞭解 MSP 中 APM 系統的設計實現，我們決定編寫一個《詳聊微服務觀測》系列文章，深入 APM 系統的產品、架構設計和基礎技術。本文為該系列文章的第二篇，主要分享了我們自研的儀表盤系統 Erda DashBoard 的使用操作及未來願景。

《詳聊微服務觀測》系列文章：

• 《從監控到可觀測性，我們最終要走向哪裡？》
• 《上手後才知道，這套儀表盤系統用起來是真的爽！》（本文）

​

引言

容器化與微服務，使系統擴充套件性與魯棒性相比以往提升了許多，但隨之也帶來了問題：運維的任務與工作量日漸繁重。

構成這一應用的微服務以及支撐這一應用的所有基礎設施，都會有各自的日誌、指標資料，以及構建在上游的監控、日誌系統。各處分散的資料和系統，會給支援團隊造成極大的負擔，最終也會成為開發運維工作的攔路虎。
​

我們的思考

我們已經統一了不同服務的日誌、資料、指標等的分析與聚合及儲存，但不同租戶、應用、服務、例項可能都需要一套自己的具像化監控用以分析排查，這給監控靈活性帶來了極大挑戰。

時至今日，市面上已然出現了許多自定義、視覺化的開源錶盤，如 Kibana、Grafana、Dash 等，也有一定的缺憾，如使用上手難度大，學習成本高等，但最大的問題是操作不連貫導致無法快速排查問題。還有一些系統自帶的監控圖表，但這些資料範圍與查詢規則、排列組合都是程式固定好的，遇到一些複雜情況，還是需要用到第三方工具進行分析排查，不僅費時還費力。作為 PaaS 平臺，我們研發了 Erda Dashboard，統一了使用體驗。
​

簡介

Erda DashBoard 是一套自研的儀表盤系統，前端基於 Echarts 和 React-grid-layout，後端採用 Influxql 時序查詢語言與自研的 Metrics Search Engine，被 Erda 上絕大多數圖表所採用，包含了自定義儀表盤等功能。
​

架構簡圖

​

出於需要對大量資料進行儲存與分析的考慮，且大多數場景需要藉助時間生成時序圖、需要在數千萬條資料中進行搜尋，壓力非常大；除此之外，我們還有定製化的需求，這就決定了元件必須是開源的。結合以上種種原因，我們採用了分散式開源的 ElasticSearch 進行儲存，並對其進行了改造，結構如下:
​

    {
        "_index": "spot-application_cache-full_cluster-r-000001",
        "_type": "spot",
        "_id": "xxx",
        "_score": 1,
        "_source": {
          "name": "application_cache",
          "timestamp": 1621564500000000000,
          "tags": {
            "_meta": "true",
            "source_application_id": "9",
            "source_application_name": "xxx",
            "source_org_id": "1",
            "source_project_id": "5",
            "source_project_name": "xxx",
            "source_runtime_id": "26",
            "source_runtime_name": "xxx",
            "source_service_id": "xxx",
            "source_service_instance_id": "xxx",
            "source_service_name": "xxx",
            "source_workspace": "DEV",
          },
          "fields": {
            "elapsed_count": 2,
            "elapsed_max": 345831,
            "elapsed_mean": 331554,
            "elapsed_min": 317277,
            "elapsed_sum": 663108
          },
          "@timestamp": 1621564500000
        }
    }
 

​

考慮到易用性與通用性，我們摒棄了原生的 DSL 查詢方式，封裝了時序查詢語言 Influxql 並對其做了定製化作為高階功能，用以實現複雜的查詢與分析。對與普通的分析，我們使用 Low Code + 自定義函式表示式的搭配快速產出分析圖表。
​

初步使用

在 Erda MSP 中，我們提供了大量的內建錶盤來幫助排查系統的常見問題，如程序分析、錯誤分析、鏈路追蹤、事務分析等。

這些錶盤由多個不同的圖表組成，我們可以對其單個圖表進行操作與調整時間範圍：

當時間跨度大，資料量繁多的情況下，可以全屏檢視用以統計走勢或具體分析：
​

產品特性

運維大盤

運維大盤，也稱之為儀表盤，用以給開發人員與運維人員產生高度可定製化的分析圖表，目前存在於多雲管理平臺與微服務治理平臺中，提供高自由度、可擴充套件、高定製化的圖表。
​

​

進入新建運維大盤 ->> 新增圖表後，即可進入圖表編輯器，提供豐富的配置功能：
​

如指標分組（FROM）、維度（GROUP BY）、值（SELECT）、結果篩選器（WHERE）、結果排序（ORDER BY）、結果擷取（LIMIT）等，與 SQL 一一對應，簡單配置後產生圖表，儲存即可生成錶盤。
​

多種不同的時序圖，可以無縫切換圖表型別展現：
​

為支援更多複雜查詢與分析，提供 SQL 方式查詢，自由排列組合：
​

提供匯出功能，一鍵生成錶盤快照、用以共享：
​

擴充套件與自定義函式

Erda Dashboard 提供了豐富的自定義擴充套件方法，例如：
​

• diffps：用以計算磁碟 IO、網路 IO 等速率值。

​

如 docker container 的一些原生指標是沒有速率值，只有 Counter 值，比如網路 IO，這個時候就需要對 Counter 值進行處理以計算速率，一般的解決方案是用流計算引擎類似 Flink 進行二次聚合，但並不通用且會造成依賴，如自定義指標，我們選擇在查詢端實現，並且支援分組。
​

   SELECT time(),application_name::tag,diffps(rx_bytes::field)
   FROM docker_container_summary 
   GROUP BY time(),application_name::tag
   Limit 5

• 使用時序圖+自定義表示式後，更加直觀清晰。

​

願景

未來，Erda Dashboard 將會統一 Erda MSP 上所有圖表，並且會擴充套件更多豐富的圖表型別與自定義方法，以及支援更多的資料來源，在規劃中的模板市場可以實現秒建錶盤、組織內分享、公開市場等，使運維與開發效率達到極大提升。並且與告警系統聯動形成分析報告，早日達成 “1 分鐘發現問題，3 分鐘定位故障跟因” 的目標。
​

歡迎參與開源

Erda 作為開源的一站式雲原生 PaaS 平臺，具備 DevOps、微服務觀測治理、多雲管理以及快資料治理等平臺級能力。點選下方連結即可參與開源，和眾多開發者一起探討、交流，共建開源社群。歡迎大家關注、貢獻程式碼和 Star！
​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官網：https://www.erda.cloud/