carbon配置

carbon配置

全部carbon的配置文件都放在/opt/graphite/conf/目錄下。若是你的graphite是新安裝的，那麼conf文件夾下不會有任何.conf的文件存在，可是有不少.conf.example的文件。你只須要把.conf.example相應的文件複製一份，而且把.example後綴去掉，而後就生成了你本身的配置文件，再對配置文件進行配置就能夠了：

pushd /opt/graphite/conf
cp carbon.conf.example carbon.conf
cp storage-schemas.conf.example storage-schemas.conf

carbon.conf

這是一個主要的配置文件，定義了每一個carbon daemon的運行環境。

配置文件裏面的每一個配置項，在配置文件裏面都有相應的註釋和說明。

配置文件被分紅了幾個部分，用來配置不一樣的daemon。carbon-cache使用[cache]這個部分的配置項，carbon-relay使用[relay]這部分的配置項，carbon-aggregator使用[aggregator]這部分的配置項。若是你是第一次使用graphite，除了[cache]這部分配置須要修改外，其餘的兩個部分的配置能夠先不用關心。

提示：

carbon-cache和carbon-relay能夠運行在一臺機器上。試着交換列在[cache]和[relay]下面的LINE_RECEIVER_PORT和PICKLE_RECEIVER_PORT兩個默認的端口，這樣指標發送端不須要作任何修改，就能夠把指標發送給carbon-relay。在設置[relay]下面的DESTINATIONS字段的時候，記得[relay]下面的PICKLE_RECEIVER_PORT端口已經修改爲新的端口了。

storage-schemas.conf

這個配置文件詳細地定義了數據的採樣頻率，存儲時長以及指標的的匹配規則。Whisper數據庫將使用這個配置文件來生成數據庫裏面的全部數據點。

一些重要的提示：

1：這個文件裏面可能會有多個section

2：匹配數據的時候，文件裏面的section是從上到下順序遍歷的。

3：匹配規則使用的是正則表達式

4：第一個匹配上metrics的名字的規則會被使用。

5：收到第一個metrics的時候設置採樣頻率

6：改變這個配置文件不會改變已經生成的.wsp文件，使用whisper-resize.py來改變已經生成的文件。

規則由三行組成：

1：名字，定義在方括號裏面

2：正則表達式，定義方式：pattern=xxx

3：數據採樣頻率，定義方式：retentions=xxx

採樣頻率這一項可必定義多個採樣頻率，使用逗號分隔開

採樣頻率的定義使用到下面一些後綴：

1：s ： 秒

2：m ：分鐘

3：h ：小時

4：d：天

5：y：年

下面是個簡單的例子：

[garbage_collection]
pattern = garbageCollections$
retentions = 10s:14d

名字garbage_collection主要是寫日誌的需求，當有metrics匹配上這個規則後，這個名字會出如今create.log裏面。

全部以garbageCollections結尾的metrics都會匹配到這個規則。好比說com.acmeCorp.instance01.jvm.memory.garbageCollections能夠匹配上這個規則，可是com.acmeCorp.instance01.jvm.memory.garbageCollections.full 不會匹配上這個規則。

retentions這一行的意思是：採樣頻率爲10秒採樣一次，而且保存14天的數據。

下面是個複雜的例子：

[apache_busyWorkers]
pattern = ^servers\.www.*\.workers\.busyWorkers$
retentions = 15s:7d,1m:21d,15m:5y

在這個例子裏面，假設你的指標數據格式是servers.<servername>.<metrics>，這個正則表達式能夠匹配名字以‘www’開頭，接着能夠是任何字符，而後以‘‘.workers.busyWorkers’結尾的服務器名字。

這個例子使用了多個採樣頻率。設置指標採樣頻率的通常規則是高精度短時長到低精度長時長– whisper會根據指定的聚合規則（默認是取平均值）對指標進行聚合。

經過使用多個retentions，你能夠存儲很長時間的數據，可是又不浪費磁盤空間。

好比說你按1m:1y,1h:5y這個retentions來存儲銷售額數據。若是你想知道去年1月1號總共的銷售額，而後你能夠從whisper數據庫裏面查到24個數據點，每一個小時一個數據點。而後你把每一個數據點乘以60，就獲得了每一個小時的總銷售額。

storage-aggregation.conf

這個配置文件裏面定義了怎麼樣把高精度數據聚合成低精度數據的數據聚合規則。定義格式跟storage-schema.conf相似。可是有如下幾點必須注意：

1：這個文件是可選的，若是沒有提供，則會使用默認的配置。

2：配置裏面沒有retentions這一項了，而是增長了xFilesFactor和aggregationMethod這兩項

3：xFilesFactor必須是0到1之間的浮點型數值，這個數值指定了高精度的數據必須有多少個非空值，才能把這些高精度值聚合成一個非空的低精度值。默認值是0.5。

4：aggregationMethod指定了用於聚合的函數，合法的函數有：average, sum, min, max和last。默認值是average。

5：當收到第一個指標數據的時候，這些值會被設置。

6：修改這個配置文件對已經生成的.wsp文件不會產生影響。可使用whisper-set-aggregation-method.py來修改已經生成的.wsp文件。

下面是個例子：

[all_min]
pattern = \.min$
xFilesFactor = 0.1
aggregationMethod = min

上面這個例子將匹配全部以.min結尾的指標。使用的聚合方式是取最小值。高精度的數據只須要有10%的非空數據就能聚合成一個低精度數據。

若是xFilesFactor或者aggregationMethod沒有設置，將會使用默認值。

聚合參數和retentions參數分開設置是由於聚合規則的定義由要收集的數據類型決定，而retentions規則由數據的存儲容量和重要性來決定。

relay-rules.conf

當須要把特定的指標數據發送給特定的後端時，須要定義相關的relay規則。Relay規則是由carbon-relay這個模塊來處理的。你可使用正則表達式來過濾指標而且定義過濾出來的指標要被髮送給哪一個後端服務器。

例子：

[example]
pattern = ^mydata\.foo\..+
servers = 10.1.2.3, 10.1.2.4:2004, myserver.mydomain.com

你必須至少定義一個section做爲默認設置。

aggregation-rules.conf

這個配置文件裏面定義的規則能夠幫助你在收集到多個指標的時候，把多個指標聚合成一個指標。跟其餘的配置文件不同，這個配置文件一旦修改，立馬生效。要使用這個功能，必須運行carbon-aggregation。

這個文件裏面每一行的格式以下所示：

<env>.applications.<app>.<server>.<metric>

好比你能夠配置像下面這樣的聚合規則：

<env>.applications.<app>.all.requests (60) = sum <env>.applications.<app>.*.requests
<env>.applications.<app>.all.latency (60) = avg <env>.applications.<app>.*.latency

若是你配置了上面這樣的聚合規則，那麼當你收到以下指標的時候：

prod.applications.apache.www01.requests
prod.applications.apache.www02.requests
prod.applications.apache.www03.requests
prod.applications.apache.www04.requests
prod.applications.apache.www05.requests

這些指標數據會被送到統一的聚合緩衝區裏面，60秒後，carbon-aggregation會把緩衝區裏面的這些指標數據相加，而後生成一個‘prod.applications.apache.all.requests’指標數據。

carbon-aggregation除了這個使用場景外，還有另一個經常使用的使用場景，就是用來對多個一樣的指標數據進行聚合。當你須要從多個主機上收集相同的指標時，或者指標的發送頻率高於事先定義好的收集頻率時，使用carbon-aggregation對這些指標進行聚合會很是方便。

rewrite-rules.conf

rewrite 規則容許你使用Python的正則表達式對收到的指標名進行重命名。跟其餘的配置文件不同，這個配置文件一旦修改，立馬生效。要使用這個功能，必須運行carbon-aggregation。

這個配置文件裏面的每一行，都使用下面的格式定義：

regex-pattern = replacement-text

全部匹配上regex-pattern的指標名稱都會被捕獲，而後被重命名成replacement-text。regex-pattern必須是合法的Python正則表達式，replacement-text能夠是任意的值。你也可使用捕獲組：

^collectd\.([a-z0-9]+)\. = \1.system.

使用這個規則能夠致使下面的結果：

collectd.prod.cpu-0.idle-time => prod.system.cpu-0.idle-item

Rewrite-rules.conf由[pre]和[post]兩個部分組成。指標剛被收到的時候要更名，使用pre裏面的規則。數據聚合之後要更名使用post裏面的規則。

例子：

[post]
_sum$ =
_avg$ =

這個定義的意思是說，數據聚合之後，去掉全部以_sum或者以_avg結尾的指標名稱裏面的_sum或者_avg。

whitelist and blacklist

使用whitelist這個功能可讓carbon daemons只接受白名單裏面的指標，拒絕黑名單裏面的指標。設置carbon.conf裏面的USE_WHITELIST字段能夠啓用這個功能。當不少指標發送給graphite或者有人發送了不少沒有的指標的時候，這個功能會頗有用。

Carbon daemon會在GRAPHITE_CONF_DIR路徑下搜索whitelist.conf 和 blacklist.conf。配置文件裏面的每一行都定義了一個匹配指標的正則表達式。若是whitelist.conf不存在，或者裏面的內容是空的，那麼全部的指標都會被graphite接受。

-----------------------------------------------------

歡迎關注個人微信公衆號 ^_^