iT邦幫忙

2022 iThome 鐵人賽

2
DevOps

淺談DevOps與Observability系列 第 33

一起閱讀Grafana Tempo - Configuration Section 1

  • 分享至 

  • xImage
  •  

照著官網進度走, 今天是Configuration

Section 1?
就看到哪裡, 有多少時間就慢慢學到哪裡:)

Tempo的configuration主要由以下配置組成的

  • server
  • distributor
  • ingester
  • metrics-generator
  • query-frontend
  • querier
  • compactor
  • storage
  • memberlist
  • overrides
  • search
  • usage-report

該配置可設置variable在佈署啟動時給予值.
在啟動時帶上--config.expand-env
VAR是變數名稱

${VAR}

也能給予這變數一個預設值

${VAR:-default_value}

例如Loki透過執行檔啟動時, 需要先啟用config.expand-env, 然後把變數的KVpair代入

./loki-linux-amd64 -config.file=loki-local-config.yaml  -config.expand-env=true CHUNKS_DIR=/tmp/chunks

這配置與啟動方式在Tempo與Loki是共同的, 甚至Elastic也是.
Loki environment variable
Elastic environment variable

這裡是Tempo提供的一份基礎的Configuration file
能參照著查看.

這是它對應的Go struct結構的程式碼定義連結

Server

Tempo團隊使用Weaveworks的Common打造出來的服務.
其中Weaveworks這公司就是在2017年提出GitOps的.
Tempo則用了裡面相當多功能組件來打造.

Tempo主要用到這Weavework common的config組件來進行定義與配置連結

決定要不要啟用多租戶, Tempo所有提供的api會不會有自定義的前綴詞,
再來server區塊大多在定義http與grpc相關的port, timeout, bodysize等等的配置.

# Optional. Setting to true enables multitenancy and requires X-Scope-OrgID header on all requests.
[multitenancy_enabled: <bool> | default = false]

# Optional. String prefix for all http api endpoints. Must include beginning slash.
[http_api_prefix: <string>]

server:

Search

就只有設定允不允許Tempo能搜尋, 這是它對應的Go struct結構的程式碼定義連結
enable後在Query type那裡會多出Search

可是其他組件也要有對應的設定才能完整支援,
能參考Tempo Backend Search
主要就看場景設定querier區塊與query_frontend區塊

畢竟查詢的隊列跟啟用去並行搜尋的job thread總不能無限, 這裡大多都是定義上限值.

Metrics-generator

Tempo畢竟也是個服務, 看需求也許有需要提供metric給Prometheus.
這裡的配置就是來啟用產生Prometheus格式的metric data.

啟用方法

metrics_generator_enabled: true

這是它對應的Go struct結構的程式碼定義連結
啟用這設定時, 往往後面還要搭配一組Metrics-generator Config的配置, 裡面有Ring, Processor, Registry, Storage, MetricsIngestionSlack能設定.

該配置對應的Go struct結構的程式碼定義連結

Ring

其實就是常聽到Consistent Hash Ring
Tempo與Loki都有對應的章節在介紹這裡的設定.
Tempo Consistent Hash Ring

Loki Consistent Hash Ring

hmm...糟糕, 想用Go練習寫一個Consistent hash ring了:)
我是覺得光這題目大概就能看好幾天分享好幾天了, 明年吧!

Processor

service_graphs, span_metrics
這兩個改天K到上面的連結時再講.

Registry

主要設定兩個時間,
collection_interval, 預設15s, 決定多久收集一次metric, 且寫入到遠端
stale_duration, 預設15分鐘, 就是把不新鮮沒意義的過往metrics series都刪除掉.

Storage

就是能設定, WAL跟path, 還有remote_write
這remote_write與Prometheus的是一樣的, 能參考Prometheus - remote write
主要就是把metrics data給寫到任何第三方的存儲服務又稱為Remote storage.

一直強調的high-scale distributed
其實Tempo沒提供這麼強大的分散式存儲, 只是提供介面與幾個選項, 能往第三方寫入.
它自己的Metric data存儲亦是如此
只要公司鈔能力夠強, 在存儲上要怎投資多大成本理應上都能:)

參考資料

Grafana Tempo

Weaveworks

Drone envsubst

Kubernetes X CICD X DevOps 成就時間管理大師暨薪水強盜系列 - Day 16 - GitOps的介紹


上一篇
淺談Grafana Tempo DataFlow
下一篇
一起閱讀Grafana Tempo - Configuration Section 2
系列文
淺談DevOps與Observability36
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言