OpenTSDB 2.3+及TCollector 1.3+安裝配置排錯
在這裏必須吐一下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+安裝配置排錯