OpenTSDB 2.3+及TCollector 1.3+安裝配置排錯

標籤：opentsdb   tcollector   資料擷取   監控   hbase   

其實不太想用opentsdb，一直以來用influxdb+grafana挺方便的，而且tsdb依賴hbase，雖說容量和速度有保證，但是分布式系統對於一個監控平台來說，終歸還是有些重了，出問題定位更繁瑣，但領導說用那就用吧。

在這裡必須吐一下OpenTSDB和Tcollector的文檔更新，太落後，看官方文檔根本找不到設定檔的位置。最後還得看源碼，尤其是TCollector，這個tsdb官方推出的資料擷取器。不光文檔落後，除了核心，周邊輔助的代碼也落後。而且外掛程式方式設計的各種資料收集器太奇葩了，運行不了就狂報錯。

安裝tsdb還是比較方便的，找一台hbase的regionserver直接rpm就可以。主要是搞了tcollector以後排錯，不過問題主要是在tcollector上，不賴tsdb。

不過tsdb裝完以後，需要自己運行一個指令碼叫create_table.sh來在hbase裡建立tsdb需要的表。這塊坑了我幾分鐘，安裝官方文檔的說法，建立表格時採用何種壓縮方式並不重要，然後運行指令碼，半個小時表都沒建立起來，指令碼預設會採用LZO方式選擇壓縮，就是建不起來，必須在命令列寫env COMPRESSION='NONE' ... 才可以。不過我這叢集是支援lzo的啊。不過跟tcollector相比，這就不算事。

tsdb的配置也算簡單，就不細說了。

tcollector是opentsdb官方推出的資料擷取器，符合個人開源風格，文檔長期不更新。參看官方文檔硬是找不到在哪配置能訪問opentsdb，文檔寫的檔案根本在代碼裡不存在，只能翻源碼。

tcollector安裝也不複雜，內建一個rpm的打包Makefile，直接make rpm就可以打包成rpm，然後放到repo裡面yum安裝即可，主要問題是安裝以後跑起來沒資料。

那就開始排錯吧，首先確定opentsdb能不能接收到資料。停掉tsdb，用 nc -l 4242 啟動一個TCP Server，監聽在原tsdb的連接埠上，然後啟動tcollector，nc接收到一個version，然後就沒了。好吧，去看tcollector的源碼。

        # we use the version command as it is very low effort for the TSD        # to respond        LOG.debug('verifying our TSD connection is alive')        try:            self.tsd.sendall('version\n')        except socket.error, msg:            self.tsd = None            self.blacklist_connection()            return False

嗯，version其實是相當於發送一個ping命令，如果沒有響應，就把伺服器放到黑名單裡。我不明白，往單一伺服器發送的程式，要黑名單幹什麼。

繼續nc -l，收到version給個響應。

收到version以後，直接在nc控制台裡打2，隨便給個響應就行，立刻資料就上來了。好吧，tcollector發送資料其實沒問題，那問題一定是在tsdb這邊了。

開啟tsdb的日誌，沒有任何報錯。

開啟 /etc/opentsdb/logback.xml 將日誌等級從INFO提升為DEBUG，opentsdb採用slf4j作為日誌記錄。

  <root level="DEBUG">    <!-- <appender-ref ref="STDOUT"/> -->    <appender-ref ref="CYCLIC"/>    <appender-ref ref="FILE"/>  </root>

重啟tsdb，再去看日誌，來了。

16:58:27.470 DEBUG [PutDataPointRpc.execute] - put: unknown metric: No such name for 'metrics': 'tcollector.reader.lines_collected'

說hbase的tsdb表裡沒有metrics這個列名，翻看官方文檔，有個配置叫

tsd.core.auto_create_metrics = true

預設是false，設定成true以後重啟tsdb，資料進入hbase，沒有問題了。

不過資料進到hbase裡面又出現一個問題，沒有cpu的度量資訊，看源碼得知cpu資訊在collector裡面的sysload.py裡面，不過翻看Makefile打包出來的rpm，裡面不包含這個檔案。沒辦法，接著回去看tcollector的Makefile和rpm的spec檔案，順手修複了一下centos6下的bug。

Makefile倒是沒看出什麼問題，幾個選項，all, rpm, clean, distclean, swix，分別對應 make all， make rpm， make clean等，那應該就是在spec檔案裡面了。

果然，spec檔案的第一個問題是rpm調用的python被硬指向了python 2.7，而centos6裡面是沒有2.7的，順手改之。

%global py2_sitelib   /usr/lib/python2.6/site-packages

第二個問題，安裝的外掛程式指向的是具體檔案。

%files collectors    %{tcollectordir}/collectors/0/dfstat.py    %{tcollectordir}/collectors/0/ifstat.py    %{tcollectordir}/collectors/0/iostat.py    %{tcollectordir}/collectors/0/netstat.py    %{tcollectordir}/collectors/0/procnettcp.py    %{tcollectordir}/collectors/0/procstats.py    %{tcollectordir}/collectors/0/smart_stats.py

所以結果是這幾個檔案才會被打包到rpm，這明顯是主要代碼更新了，而周邊輔助的代碼沒更新導致的。

不過改成 * 是不優雅的，因為有些新增的外掛程式因為調用依賴問題，啟動後會一直報錯，所以，需要根據具體需求來執行都安裝哪些外掛程式，所以，從這一點上說，這部分代碼的產品化程度還遠遠不夠，最起碼要做出外掛程式判斷啊，缺少依賴就別運行了。

更新了spec，重新打包，需要的資料就都進入hbase了。

而tcollector的配置是最大的槽點，放到最後壓軸來說，根據官方文檔，理應有一個startstop指令碼，將上報伺服器配置為opentsdb的伺服器，結果源碼裡死都找不到這個startstop指令碼。然後通過閱讀源碼得知，他娘的核心設定檔是放在外掛程式檔案夾裡的，這思路，簡直是災難啊。在 tcollector/collectors/etc/config.py裡面，其實並不複雜，但是比較煩人。

    defaults = {        'verbose': False,        'no_tcollector_stats': False,        'evictinterval': 6000,        'dedupinterval': 300,        'deduponlyzero': False,        'allowed_inactivity_time': 600,        'dryrun': False,        'maxtags': 8,        'max_bytes': 64 * 1024 * 1024,        'http_password': False,        'reconnectinterval': 0,        'http_username': False,        'port': 4242,        'pidfile': '/var/run/tcollector.pid',        'http': False,        'http_api_path': "api/put",        'tags': [],        'remove_inactive_collectors': False,        'host': 'to.your.opentsdb.server',        'backup_count': 1,        'logfile': '/var/log/tcollector.log',        'cdir': default_cdir,        'ssl': False,        'stdin': False,        'daemonize': False,        'hosts': False    }

嗯，這是我目前逛街發現的最坑的有公司維護的開原始碼了，設計出這個代碼結構的工程師應該拉出去槍斃半小時。浪費我2小時寶貴的擼碼時間裝這破玩意。

然後，我發現我司有一台伺服器上面是有tcollector的代碼的，檔案建立時間是15年，那會我還沒來，說明其實我司早就調研過這個，但是一直沒搞起來可能，這東西沒多難，但是文檔確實坑人。

感覺產品設計，從來就不是互連網碼農的強項，快速開發實現功能就行了，從不考慮產品化工程化代碼結構最佳化的問題。

最後，領導願意看用gnuplot畫的圖我也就不說什麼了。我還是把opentsdb作為資料來源接入到grafana裡面，用那個看更漂亮一點。

OpenTSDB 2.3+及TCollector 1.3+安裝配置排錯