go監控方案的概述和作用

這篇文章主要介紹“go監控方案的概述和作用”，在日常操作中，相信很多人在go監控方案的概述和作用問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”go監控方案的概述和作用”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

概述

為什么需要監控

在編寫應用程序的時候，通常會記錄日志以便事后分析，在很多情況下是產生了問題之后，再去查看日志，是一種事后的靜態分析。 在很多時候，我們可能需要了解整個系統在當前，或者某一時刻運行的情況，比如當前系統中對外提供了多少次服務，這些服務的響應時間是多少， 隨時間變化的情況是什么樣的，系統出錯的頻率是多少。這些動態的準實時信息對于監控整個系統的運行健康狀況來說很重要。

由于業務系統數量大，每天都會產生大量的系統日志和業務日志，單流式業務的一臺服務器產生的日志達400M 想直接查看內容打開可能幾分鐘， 而且內容之多根本無法查看，給開發和運維帶來諸多不便，現業務都是分布式的，日志也是分布在每臺服務器上， 所以查看日志和統計更是效率低下。實時收集分布在不同節點或機器上的日志，供離線或在線查閱及分析來提升工作效率的需求異常迫切，

這些動態的準實時信息對于監控整個系統的運行健康狀況來說很重要。

Profiling特別重要。如果能有一個特別強大的Profiling系統，就知道整個系統在哪個地方，哪臺機器上，花了多少CPU、內存、磁盤IO或者網絡帶寬等資源，才能知道優化什么地方效益最大。

監控需要的信息從哪里獲得？

這些信息需要數據作為基礎直接獲得或者計算獲得，那么實時數據怎么去獲取，什么標準來作為測量標準。也就是信息采集的時候，怎么去獲得。如下面這些實時數據如何獲得

1. 響應時間：用戶發送一個請求到用戶接受服務器返回響應的這段時間就是響應時間

2. 吞吐量：單位時間內系統處理的客戶端請求數量

3. 并發用戶數量： 某一個時刻同事向系統提交請求的用戶數

4. TPS： 每秒事務數

5. PV: 訪問一個URL，產生一個PV

6. UV: 用戶訪問站點的所有頁面算一個UV

整套方案需要使用到的技術

1. metrics: 項目代碼中監控信息采集使用, 支持gc、mem 等信息收集

2. statsd: 使用statsd進行udp數據的傳輸，

3. telegraf: 項目外部數據收集使用telegraf

4. influxdb: 使用該時序數據進行數據存儲

5. grafana: 進行數據展示

因為以前沒有涉及過監控相關的技術，所以在做的時候碰到各種問題,這里記錄一下這個過程踩過的坑。

當時做的時候，我的主要是想使用metrics 提供的度量作為數據采集的標準，然后將數據寫入influxdb里面，然后grafana進行展現就好了，但是git上使用的這個metrics 只提供TCP 連接influxdb的方式。 所以滿足不了我的需要。

TCP 因為要握手所以對性能有影響， 想使用UDP 作為傳輸方式， 然后找到 statsd 是支持TCP/UDP 方式進行傳輸的，但是 statsd 支持支持的類型很少，并不能完全滿足采集到的metrics 支持的這些度量標準。 所以需要將metrics 采集以后 復雜的類型轉換成 statsd 基礎類型進行傳輸。

原有系統有用telegraf 支持docker外部的信息采集，并且可以添加statsd插件，這樣既可以采集到代碼之外的性能指標的，也可以方便的將statsd 傳輸數據存入influxdb中， 然后再用grafana 作為展示面板，將數據展現出來，就完成了整套方案。

方案大致流程

到此，關于“go監控方案的概述和作用”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！