prometheus 實戰
v0.1.0
在過去一年左右時間裡，我們使用 prometheus 完成了對幾個機房的基礎和業務監控，大大提高了服務品質以及 oncall 水準，在此特别感謝 promethues 這樣優秀的開源軟體。
當初選擇 prometheus 并不是偶然，因為：
prometheus 是按照 google sre 運維之道的理念建構的，具有實用性和前瞻性。
prometheus 社群非常活躍，基本穩定在 1個月1個版本的疊代速度，從 2016 年 v1.01 開始接觸使用以來，到目前釋出的 v1.8.2 以及最新最新的 v2.1 ，你會發現 prometheus 一直在進步、在優化。
go 語言開發，性能不錯，安裝部署簡單，多平台部署相容性好。
豐富的資料收集用戶端，官方提供了各種常用 exporter。
豐富強大的查詢能力。
+
prometheus 作為監控後起之秀，雖然還有做的不夠好的地方，但是不妨礙我們使用和喜愛它。根據我們長期的使用經驗來看，它足以滿足大多數場景需求，隻不過對于新東西，往往需要花費更多力氣才能發揮它的最大能力而已。
本書主要根據個人過去一年多的使用經驗總結而成，内容主要包括 prometheus 基本知識、進階、實戰以及常見問題清單等方面，希望對大家有所幫助。
本開源書籍既适用于具備基礎 linux 知識的運維初學者，也可供渴望了解 prometheus 原理和實作細節的進階使用者參考，同時也希望書中給出的實踐案例在實際部署監控中對大家有所幫助。
你準備好了嗎？接下來就讓我們一起開始這段神奇旅行吧！
一、什麼是 prometheus
prometheus 是由 soundcloud 開源監控告警解決方案，從 2012 年開始編寫代碼，再到 2015 年 github 上開源以來，已經吸引了 9k+ 關注，以及很多大公司的使用；2016 年 prometheus 成為繼 k8s 後，第二名 cncf(cloud native computing foundation) 成員。
作為新一代開源解決方案，很多理念與 google sre 運維之道不謀而合。
多元 資料模型（時序由 metric 名字和 k/v 的 labels 構成）。
靈活的查詢語句（promql）。
無依賴存儲，支援 local 和 remote 不同模型。
采用 http 協定，使用 pull 模式，拉取資料，簡單易懂。
監控目标，可以采用服務發現或靜态配置的方式。
支援多種統計資料模型，圖形化友好。
prometheus server， 主要用于抓取資料和存儲時序資料，另外還提供查詢和 alert rule 配置管理。
client libraries，用于對接 prometheus server, 可以查詢和上報資料。
push gateway ，用于批量，短期的監控資料的彙總節點，主要用于業務資料彙報等。
各種彙報資料的 exporters ，例如彙報機器資料的 node_exporter, 彙報 mongodb 資訊的 mongodb exporter 等等。
用于告警通知管理的 alertmanager 。
一圖勝千言，先來張官方的架構圖
從這個架構圖，也可以看出 prometheus 的主要子產品包含， server, exporters, pushgateway, promql, alertmanager, webui 等。
它大緻使用邏輯是這樣：
prometheus server 定期從靜态配置的 targets 或者服務發現的 targets 拉取資料。
當新拉取的資料大于配置記憶體緩存區的時候，prometheus 會将資料持久化到磁盤（如果使用 remote storage 将持久化到雲端）。
prometheus 可以配置 rules，然後定時查詢資料，當條件觸發的時候，會将 alert 推送到配置的 alertmanager。
alertmanager 收到警告的時候，可以根據配置，聚合，去重，降噪，最後發送警告。
可以使用 api， prometheus console 或者 grafana 查詢和聚合資料。
prometheus 的資料是基于時序的 float64 的值，如果你的資料值有更多類型，無法滿足。
prometheus 不适合做審計計費，因為它的資料是按一定時間采集的，關注的更多是系統的運作瞬時狀态以及趨勢，即使有少量資料沒有采集也能容忍，但是審計計費需要記錄每個請求，并且資料長期存儲，這個 prometheus 無法滿足，可能需要采用專門的審計系統。
二、為什麼選擇 prometheus
在前言中，簡單介紹了我們選擇 prometheus 的理由，以及使用後給我們帶來的好處。
在這裡主要和其他監控方案對比，友善大家更好的了解 prometheus。
zabbix 使用的是 c 和 php, prometheus 使用 golang, 整體而言 prometheus 運作速度更快一點。
zabbix 屬于傳統主機監控，主要用于實體主機，交換機，網絡等監控，prometheus 不僅适用主機監控，還适用于 cloud, saas, openstack，container 監控。
zabbix 在傳統主機監控方面，有更豐富的插件。
zabbix 可以在 webgui 中配置很多事情，但是 prometheus 需要手動修改檔案配置。
graphite 功能較少，它專注于兩件事，存儲時序資料， 可視化資料，其他功能需要安裝相關插件，而 prometheus 屬于一站式，提供告警和趨勢分析的常見功能，它提供更強的資料存儲和查詢能力。
在水準擴充方案以及資料存儲周期上，graphite 做的更好。
influxdb 是一個開源的時序資料庫，主要用于存儲資料，如果想搭建監控告警系統， 需要依賴其他系統。
influxdb 在存儲水準擴充以及高可用方面做的更好, 畢竟核心是資料庫。
opentsdb 是一個分布式時序資料庫，它依賴 hadoop 和 hbase，能存儲更長久資料， 如果你系統已經運作了 hadoop 和 hbase, 它是個不錯的選擇。
如果想搭建監控告警系統，opentsdb 需要依賴其他系統。
nagios 資料不支援自定義 labels, 不支援查詢，告警也不支援去噪，分組, 沒有資料存儲，如果想查詢曆史狀态，需要安裝插件。
nagios 是上世紀 90 年代的監控系統，比較适合小叢集或靜态系統的監控，顯然 nagios 太古老了，很多特性都沒有，相比之下prometheus 要優秀很多。
sensu 廣義上講是 nagios 的更新版本，它解決了很多 nagios 的問題，如果你對 nagios 很熟悉，使用 sensu 是個不錯的選擇。
sensu 依賴 rabbitmq 和 redis，資料存儲上擴充性更好。
prometheus 屬于一站式監控告警平台，依賴少，功能齊全。
prometheus 支援對雲或容器的監控，其他系統主要對主機監控。
prometheus 資料查詢語句表現力更強大，内置更強大的統計函數。
prometheus 在資料存儲擴充性以及持久性上沒有 influxdb，opentsdb，sensu 好。
三、安裝prometheus
本章将介紹 prometheus 兩種安裝方式: 傳統二進制包安裝和 docker 安裝方式。
1、二進制包安裝
我們可以到 prometheus 二進制安裝包下載下傳頁面，根據自己的作業系統選擇下載下傳對應的安裝包。下面我們将以 ubuntu server 作為示範。
linux amd64 (ubuntu server)
prometheus 1.6.2
建立下載下傳目錄,以便安裝過後清理掉
使用 wget 下載下傳 prometheus 的安裝包
建立 prometheus 目錄，用于存放所有 prometheus 相關的運作服務
使用 tar 解壓縮 prometheus-1.6.2.linux-amd64.tar.gz
當解壓縮成功後，可以運作 version 檢查運作環境是否正常
如果你看到類似輸出，表示你已安裝成功:
如果 prometheus 正常啟動，你将看到如下資訊：
通過啟動日志，可以看到 prometheus server 預設端口是 9090。
當 prometheus 啟動後，你可以通過浏覽器來通路 <code>http://ip:9090</code>，将看到如下頁面
在預設配置中，我們已經添加了 prometheus server 的監控，是以我們現在可以使用 <code>promql</code> （prometheus query language）來檢視，比如：
可以看出 prometheus 二進制安裝非常友善，沒有依賴，自帶查詢 web 界面。
在生産環境中，我們可以将 prometheus 添加到 init 配置裡，或者使用 supervisord 作為服務自啟動。
2、docker 安裝
首先確定你已安裝了最新版本的 docker, 如果沒有安裝請點選這裡。
下面我将以 mac 版本的 docker 作為示範。
docker 鏡像位址 quay.io
執行指令安裝:
如果安裝成功你可以通路 <code>127.0.0.1:9090</code> 檢視到該頁面:
運作 docker ps 檢視所有服務:
運作 <code>docker start prometheus</code> 啟動服務
運作 <code>docker stats prometheus</code> 檢視 prometheus 狀态
運作 <code>docker stop prometheus</code> 停止服務
四、prometheus基礎概念
本章将介紹 prometheus 一些基礎概念，包括：
資料模型
四種 metric type
作業與執行個體
1、資料模型
prometheus 存儲的是時序資料, 即按照相同時序(相同的名字和标簽)，以時間次元存儲連續的資料的集合。
時序(time series) 是由名字(metric)，以及一組 key/value 标簽定義的，具有相同的名字以及标簽屬于相同時序。
時序的名字由 ascii 字元，數字，下劃線，以及冒号組成，它必須滿足正規表達式 <code>[a-za-z_:][a-za-z0-9_:]*</code>, 其名字應該具有語義化，一般表示一個可以度量的名額，例如: <code>http_requests_total</code>, 可以表示 http 請求的總數。
時序的标簽可以使 prometheus 的資料更加豐富，能夠區分具體不同的執行個體，例如 <code>http_requests_total{method="post"}</code> 可以表示所有 http 中的 post 請求。
标簽名稱由 ascii 字元，數字，以及下劃線組成， 其中 <code>__</code> 開頭屬于 prometheus 保留，标簽的值可以是任何 unicode 字元，支援中文。
按照某個時序以時間次元采集的資料，稱之為樣本，其值包含：
一個 float64 值
一個毫秒級的 unix 時間戳
prometheus 時序格式與 opentsdb 相似：
其中包含時序名字以及時序的标簽。
2、時序 4 種類型
prometheus 時序資料分為 counter, gauge, histogram, summary 四種類型。
counter 表示收集的資料是按照某個趨勢（增加／減少）一直變化的，我們往往用它記錄服務請求總量、錯誤總數等。
例如 prometheus server 中 <code>http_requests_total</code>, 表示 prometheus 處理的 http 請求總數，我們可以使用 <code>delta</code>, 很容易得到任意區間資料的增量，這個會在 promql 一節中細講。
gauge 表示搜集的資料是一個瞬時的值，與時間沒有關系，可以任意變高變低，往往可以用來記錄記憶體使用率、磁盤使用率等。
例如 prometheus server 中 <code>go_goroutines</code>, 表示 prometheus 目前 goroutines 的數量。
histogram 由 <code><basename>_bucket{le="<upper inclusive bound>"}</code>，<code><basename>_bucket{le="+inf"}</code>, <code><basename>_sum</code>，<code><basename>_count</code> 組成，主要用于表示一段時間範圍内對資料進行采樣（通常是請求持續時間或響應大小），并能夠對其指定區間以及總數進行統計，通常它采集的資料展示為直方圖。
例如 prometheus server 中 <code>prometheus_local_storage_series_chunks_persisted</code>, 表示 prometheus 中每個時序需要存儲的 chunks 數量，我們可以用它計算待持久化的資料的分位數。
summary 和 histogram 類似，由 <code><basename>{quantile="<φ>"}</code>，<code><basename>_sum</code>，<code><basename>_count</code> 組成，主要用于表示一段時間内資料采樣結果（通常是請求持續時間或響應大小），它直接存儲了 quantile 資料，而不是根據統計區間計算出來的。
例如 prometheus server 中 <code>prometheus_target_interval_length_seconds</code>。
都包含 <code><basename>_sum</code>，<code><basename>_count</code>
histogram 需要通過 <code><basename>_bucket</code> 計算 quantile, 而 summary 直接存儲了 quantile 的值。
3、作業和執行個體
prometheus 中，将任意一個獨立的資料源（target）稱之為執行個體（instance）。包含相同類型的執行個體的集合稱之為作業（job）。 如下是一個含有四個重複執行個體的作業：
prometheus 在采集資料的同時，會自動在時序的基礎上添加标簽，作為資料源（target）的辨別，以便區分：
如果其中任一标簽已經在此前采集的資料中存在，那麼将會根據 <code>honor_labels</code> 設定選項來決定新标簽。詳見官網解釋： scrape configuration documentation
對每一個執行個體而言，prometheus 按照以下時序來存儲所采集的資料樣本：
其中 <code>up</code> 時序可以有效應用于監控該執行個體是否正常工作。
五、promql
本章将介紹 promql 基本用法、示例，并将其與 sql 進行比較。
1、promql 基本使用
promql (prometheus query language) 是 prometheus 自己開發的資料查詢 dsl 語言，語言表現力非常豐富，内置函數很多，在日常資料可視化以及rule 告警中都會使用到它。
在頁面 <code>http://localhost:9090/graph</code> 中，輸入下面的查詢語句，檢視結果，例如：
字元串: 在查詢語句中，字元串往往作為查詢條件 labels 的值，和 golang 字元串文法一緻，可以使用 <code>""</code>, <code>''</code>, 或者 <code>`` </code>, 格式如：
正數，浮點數: 表達式中可以使用正數或浮點數，例如：
promql 查詢結果主要有 3 種類型：
瞬時資料 (instant vector): 包含一組時序，每個時序隻有一個點，例如：<code>http_requests_total</code>
區間資料 (range vector): 包含一組時序，每個時序有多個點，例如：<code>http_requests_total[5m]</code>
純量資料 (scalar): 純量隻有一個數字，沒有時序，例如：<code>count(http_requests_total)</code>
prometheus 存儲的是時序資料，而它的時序是由名字和一組标簽構成的，其實名字也可以寫出标簽的形式，例如 <code>http_requests_total</code> 等價于 {name="http_requests_total"}。
一個簡單的查詢相當于是對各種标簽的篩選，例如：
查詢條件支援正則比對，例如：
prometheus 查詢語句中，支援常見的各種表達式操作符，例如
算術運算符:
支援的算術運算符有 <code>+，-，*，/，%，^</code>, 例如 <code>http_requests_total * 2</code> 表示将 http_requests_total 所有資料 double 一倍。
比較運算符:
支援的比較運算符有 <code>==，!=，>，<，>=，<=</code>, 例如 <code>http_requests_total > 100</code> 表示 http_requests_total 結果中大于 100 的資料。
邏輯運算符:
支援的邏輯運算符有 <code>and，or，unless</code>, 例如 <code>http_requests_total == 5 or http_requests_total == 2</code> 表示 http_requests_total 結果中等于 5 或者 2 的資料。
聚合運算符:
支援的聚合運算符有 <code>sum，min，max，avg，stddev，stdvar，count，count_values，bottomk，topk，quantile，</code>, 例如 <code>max(http_requests_total)</code> 表示 http_requests_total 結果中最大的資料。
注意，和四則運算類型，prometheus 的運算符也有優先級，它們遵從（^）> (*, /, %) > (+, -) > (==, !=, <=, <, >=, >) > (and, unless) > (or) 的原則。
prometheus 内置不少函數，友善查詢以及資料格式化，例如将結果由浮點數轉為整數的 floor 和 ceil，
檢視 http_requests_total 5分鐘内，平均每秒資料
2、與 sql 對比
下面将以 prometheus server 收集的 <code>http_requests_total</code> 時序資料為例子展開對比。
資料初始完成後，通過查詢可以看到如下資料：
假設目前時間為 2017/5/22 14:48:30
查詢目前所有資料
我們查詢 mysql 資料的時候，需要将目前時間向前推一定間隔，比如這裡的 10s (prometheus 資料抓取間隔)，這樣才能確定查詢到資料，而 promql 自動幫我們實作了這個邏輯。
條件查詢
模糊查詢: code 為 2xx 的資料
比較查詢: value 大于 100 的資料
範圍區間查詢: 過去 5 分鐘資料
count 查詢: 統計目前記錄總數
sum 查詢: 統計目前資料總值
avg 查詢: 統計目前資料平均值
top 查詢: 查詢最靠前的 3 個值
irate 查詢，過去 5 分鐘平均每秒數值
通過以上一些示例可以看出，在常用查詢和統計方面，promql 比 mysql 簡單和豐富很多，而且查詢性能也高不少。
六、資料可視化
收集到資料隻是第一步，如果沒有很好做到資料可視化，有時很難發現問題。
本章将介紹使用 prometheus 自帶的 web console 以及 grafana 來查詢和展現資料。
prometheus web
prometheus 自帶了 web console， 安裝成功後可以通路 <code>http://localhost:9090/graph</code> 頁面，用它可以進行任何 promql 查詢和調試工作，非常友善，例如：
通過上圖你不難發現，prometheus 自帶的 web 界面比較簡單，因為它的目的是為了及時查詢資料，友善 promeql 調試。
它并不是像常見的 admin dashboard，在一個頁面盡可能展示多的資料，如果你有這方面的需求，不妨試試 grafana。
grafana 使用
grafana 是一套開源的分析監視平台，支援 graphite, influxdb, opentsdb, prometheus, elasticsearch, cloudwatch 等資料源，其 ui 非常漂亮且高度定制化。
這是 prometheus web console 不具備的，在上一節中我已經說明了選擇它的原因。
mac version 4.3.2
這裡我使用 brew 安裝，指令為
當安裝成功後，你可以使用預設配置啟動程式
如果順利，你将看到如下日志
此時，你可以打開頁面 <code>http://localhost:3000</code>， 通路 grafana 的 web 界面。
grafana 本身支援 prometheus 資料源，故不需要安裝其他插件。
使用預設賬号 admin/admin 登入 grafana
在 dashboard 首頁，點選添加資料源
配置 prometheus 資料源
目前為止，grafana 已經和 prometheus 連上了，你将看到這樣的 dashboard
由頂部 <code>manage dashboard</code> -> <code>settings</code> 進入管理頁面
在管理頁面中取消 <code>hide controls</code>
點選頁面底部 <code>+ add row</code> 按鈕, 并選擇 <code>graph</code> 類型
點選 <code>panel title</code> -> <code>edit</code> 進入 panel 編輯頁面，并在 <code>metrics</code> 中 的 <code>metric lookup</code> 選擇 <code>go_goroutines</code>
你也可以直接在管理界面中填寫 prometheus 的查詢語句，以及修改查詢的 step 數值。
當你修改了 dashboard 後，記得點選頂部的 <code>save dashboard</code> 按鈕，或直接 <code>ctrl+s</code> 儲存。
至此，我們自定義的 panel 已添加完成
我們可以通過拖拽，拉升調節 panel 的位置和尺寸，我們調節的目的是盡量在一個螢幕顯示更多資訊。
grafana 是一款非常漂亮，強大的監視分析平台，本身支援了 prometheus 資料源，是以在做資料和監視可視化的時候，grafana + prometheus 是個不錯的選擇。
配置
prometheus 啟動的時候，可以加載運作參數 <code>-config.file</code> 指定配置檔案，預設為 <code>prometheus.yml</code>。
在配置檔案中我們可以指定 global, alerting, rule_files, scrape_configs, remote_write, remote_read 等屬性。
其代碼結構體定義為：
配置檔案結構大概為：
全局配置
<code>global</code> 屬于全局的預設配置，它主要包含 4 個屬性，
scrape_interval: 拉取 targets 的預設時間間隔。
scrape_timeout: 拉取一個 target 的逾時時間。
evaluation_interval: 執行 rules 的時間間隔。
external_labels: 額外的屬性，會添加到拉取的資料并存到資料庫中。
告警配置
通常我們可以使用運作參數 <code>-alertmanager.xxx</code> 來配置 alertmanager， 但是這樣不夠靈活，沒有辦法做到動态更新加載，以及動态定義告警屬性。
是以 <code>alerting</code> 配置主要用來解決這個問題，它能夠更好的管理 alertmanager, 主要包含 2 個參數：
alert_relabel_configs: 動态修改 alert 屬性的規則配置。
alertmanagers: 用于動态發現 alertmanager 的配置。
其中 alertmanagers 為 alertmanager_config 數組，而 alertmanager_config 的代碼結構體為,
配置檔案結構大概為:
規則配置
<code>rule_files</code> 主要用于配置 rules 檔案，它支援多個檔案以及檔案目錄。
其代碼結構定義為：
配置檔案結構大緻為：
資料拉取配置
scrape_configs 主要用于配置拉取資料節點，每一個拉取配置主要包含以下參數：
job_name：任務名稱
honor_labels： 用于解決拉取資料标簽有沖突，當設定為 true, 以拉取資料為準，否則以服務配置為準
params：資料拉取通路時帶的請求參數
scrape_interval： 拉取時間間隔
scrape_timeout: 拉取逾時時間
metrics_path： 拉取節點的 metric 路徑
scheme： 拉取資料通路協定
sample_limit： 存儲的資料标簽個數限制，如果超過限制，該資料将被忽略，不入存儲；預設值為0，表示沒有限制
relabel_configs： 拉取資料重置标簽配置
metric_relabel_configs：metric 重置标簽配置
以上配置定義中還包含 servicediscoveryconfig，它的代碼定義為：
servicediscoveryconfig 主要用于 target 發現，大體分為兩類，靜态配置和動态發現。
是以，一份完整的 scrape_configs 配置大緻為：
遠端可寫存儲
<code>remote_write</code> 主要用于可寫遠端存儲配置，主要包含以下參數：
url: 通路位址
remote_timeout: 請求逾時時間
write_relabel_configs: 标簽重置配置, 拉取到的資料，經過重置處理後，發送給遠端存儲
其代碼結構體為：
一份完整的配置大緻為:
注意： remote_write 屬于試驗階段，慎用，因為在以後的版本中可能發生改變。
遠端可讀存儲
<code>remote_read</code> 主要用于可讀遠端存儲配置，主要包含以下參數：
注意： remote_read 屬于試驗階段，慎用，因為在以後的版本中可能發生改變。
服務發現
在 prometheus 的配置中，一個最重要的概念就是資料源 target，而資料源的配置主要分為靜态配置和動态發現, 大緻為以下幾類：
static_configs: 靜态服務發現
dns_sd_configs: dns 服務發現
file_sd_configs: 檔案服務發現
consul_sd_configs: consul 服務發現
serverset_sd_configs: serverset 服務發現
nerve_sd_configs: nerve 服務發現
marathon_sd_configs: marathon 服務發現
kubernetes_sd_configs: kubernetes 服務發現
gce_sd_configs: gce 服務發現
ec2_sd_configs: ec2 服務發現
openstack_sd_configs: openstack 服務發現
azure_sd_configs: azure 服務發現
triton_sd_configs: triton 服務發現
它們具體使用以及配置模闆，請參考服務發現配置模闆。
它們中最重要的，也是使用最廣泛的應該是 <code>static_configs</code>, 其實那些動态類型都可以看成是某些通用業務使用靜态服務封裝的結果。
配置樣例
prometheus 的配置參數比較多，但是個人使用較多的是 global, rules, scrap_configs, statstic_config, rebel_config 等。
我平時使用的配置檔案大緻為這樣：
exporter
在 prometheus 中負責資料彙報的程式統一叫做 exporter, 而不同的 exporter 負責不同的業務。 它們具有統一命名格式，即 xx_exporter, 例如負責主機資訊收集的 node_exporter。
prometheus 社群已經提供了很多 exporter, 詳情請參考這裡 。
文本格式
在讨論 exporter 之前，有必要先介紹一下 prometheus 文本資料格式，因為一個 exporter 本質上就是将收集的資料，轉化為對應的文本格式，并提供 http 請求。
exporter 收集的資料轉化的文本内容以行 (<code>\n</code>) 為機關，空行将被忽略, 文本内容最後一行為空行。
文本内容，如果以 <code>#</code> 開頭通常表示注釋。
以 <code># help</code> 開頭表示 metric 幫助說明。
以 <code># type</code> 開頭表示定義 metric 類型，包含 <code>counter</code>, <code>gauge</code>, <code>histogram</code>, <code>summary</code>, 和 <code>untyped</code> 類型。
其他表示一般注釋，供閱讀使用，将被 prometheus 忽略。
内容如果不以 <code>#</code> 開頭，表示采樣資料。它通常緊挨着類型定義行，滿足以下格式：
下面是一個完整的例子：
需要特别注意的是，假設采樣資料 metric 叫做 <code>x</code>, 如果 <code>x</code> 是 <code>histogram</code> 或 <code>summary</code> 類型必需滿足以下條件：
采樣資料的總和應表示為 <code>x_sum</code>。
采樣資料的總量應表示為 <code>x_count</code>。
<code>summary</code> 類型的采樣資料的 quantile 應表示為 <code>x{quantile="y"}</code>。
<code>histogram</code> 類型的采樣分區統計資料将表示為 <code>x_bucket{le="y"}</code>。
<code>histogram</code> 類型的采樣必須包含 <code>x_bucket{le="+inf"}</code>, 它的值等于 <code>x_count</code> 的值。
<code>summary</code> 和 <code>historam</code> 中 <code>quantile</code> 和 <code>le</code> 必需按從小到大順序排列。
sample exporter
既然一個 exporter 就是将收集的資料轉化為文本格式，并提供 http 請求即可，那很容自己實作一個。
下面我将用 <code>golang</code> 實作一個簡單的 <code>sample_exporter</code>, 其代碼大緻為：
當運作此程式，你通路 <code>http://localhost:8080/metrics</code>, 将看到這樣的頁面：
我們可以利用 prometheus 的 static_configs 來收集 <code>sample_exporter</code> 的資料。
打開 <code>prometheus.yml</code> 檔案, 在 <code>scrape_configs</code> 中添加如下配置：
重新開機加載配置，然後到 prometheus console 查詢，你會看到 <code>simple_exporter</code> 的資料。
![資料遷移方法資料遷移原則資料遷移之雙寫方案資料遷移之級聯同步方案[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)