上手後才知道，這套儀表盤系統用起來是真的爽！

​
做者｜張安哲（落羽）
來源｜爾達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/