安装
OpenTSDB可以通过源码或安装包的方式进行安装. 在Github可以找到该程序的发行版.
运行要求
要运行OpenTSDB, 你需要满足以下条件:
- Linux系统 (or Windows with manual building)
- 1.6或更高版本的Java运行环境.
- 0.92或更高版本的HBase
- 4.2或更高版本的GnuPlot
安装
首先,你需要安装HBase. 如果你刚开始使用HBase和OpenTSDB这两者之一, 我们推荐你使用单独的实例来进行测试,这是安装成功并使其运行最简单的方法.Apache Quick Start 是开始学习最好的地方. 另外你也可以尝试Cloudera's CDH,Hortonworks HDP或者`MapR<https://www.mapr.com/>`_.打包发行的版本.
在开始安装OpenTSDB前, 确认Zookeeper可以正常访问. 一个简单的办法是telnet到正确端口,然后运行stats命令
.
root@host:~# telnet localhost 2181
Trying 127.0.0.1...
Connected to myhost.
Escape character is '^]'.
stats
Zookeeper version: 3.4.3-cdh4.0.1--1, built on 06/28/2012 23:59 GMT
Clients:
Latency min/avg/max: 0/0/677
Received: 4684478
Sent: 4687034
Outstanding: 0
Zxid: 0xb00187dd0
Mode: leader
Node count: 127182
Connection closed by foreign host.
如果你无法连接至Zookeeper,检查IP地址和域名解析. HBase can be finicky.
如果HBase正在运行,你可以选择使用安装包安装 OpenTSDB (发行版位于GitHub) 或使用git下载源码或压缩包.
源码编译
编译要求:
- Linux
- 1.6或更高版本的Java运行环境
- 4.2或更高版本的GnuPlot
- Autotools
- Make
- Python
- Git
- 网络连接
使用gitclone
命令下载最新版本,或在官网及github下载发行版 . 如何只需运行build.sh脚本
. 这个脚本会帮助运行编译OpenTSDB所需的所有处理 : 它会运行./bootstrap
(只在第一次运行),然后运行./configure
和make
命令. 编译好的文件会放置在build
目录,OpenTSDB所必须的jar文件也会自动下载至该目录.
git clone git://github.com/OpenTSDB/opentsdb.git
cd opentsdb
./build.sh
编译成功后, you should have a tsdb jar file in./build
目录下会出现一个名为tsdb的jar文件,同时也会存在一个文件名为tsdb
的脚本.
现在你可以使用执行命令行调用./build/tsdb
也可以运行makeinstall
来把 OpenTSDB 安装至你的系统上. 你也可以随时运行makeuninstall
来执行卸载,它不需要附加字符串参数.
如果你需要把 OpenTSDB 安装到没有网络连接的其他服务器, 使用./build.sh dist
命令会把build命令直接打包,然后你就可以复制到其他服务器上了 .
源码分支
在git上共有4个主要分支.
- 主版本(master) 这是OpenTSDB现在的发行版. 它在版本之间被标记为文档, 只会修复bug. 适用于生产环境.
- 维护(maintenance) 这是过去版本的OpenTSDB ,版本间会存在bug修复.
- 下一个(next) 现在仍处于开发状态的OpenTSDB版本. 这个版本适用于开发环境,并且会存在新的特性和bug修复. 如果发行候选被删除, 这个分支将会只包含bug修复 ,这适用于模拟环境.
- 提名(put) 下个版本的 OpenTSDB ,当一个发布候选人出现在next分支可能有新特性.
Deb 包
你可以使用shbuild.shdebian
生成deb包. 生成的包会位于./build/opentsdb-2.x.x/opentsdb-2.x.x_all.deb
. 然后根据你的想法简单的分配安装. 例如dpkg-iopentsdb-2.0.0_all.deb
.
Deb包会创建以下目录:
- /etc/opentsdb - 配置文件
- /tmp/opentsdb - 临时缓存文件
- /usr/share/opentsdb - 应用程序
- /usr/share/opentsdb/bin - "tsdb" 启动TSD的脚本或命令行工具
- /usr/share/opentsdb/lib - Java JAR 库文件
- /usr/share/opentsdb/plugins -插件和依赖文件的存放位置
- /usr/share/opentsdb/static - GUI静态文件
- /usr/share/opentsdb/tools - 脚本和其他工具
- /var/log/opentsdb -日志
安装包含一个初始化脚本位置/etc/init.d/opentsdb
,可以启动, 停止和重启 OpenTSDB. 简单的命令,service opentsdb start
来开启tsd,service opentsdb stop
来优雅关闭程序. 注: 安装完成后, tsd不会自动运行,以便你编辑修改配置文件. 编辑配置文件,然后开启 TSD.
Deb包也会创建一个opentsdb
用户和组,使TSD运行来增强安全性. TSD 只需要在log目录和缓存目录的写权限. 如果你不使用默认位置, 请在/etc/opentsdb/opentsdb.conf和/etc/opentsdb/logback.xml
配置文件修改它们,并为opentsdb
用户分配适当的权限.
如果你第一次安装OpenTSDB, 你需要使用位于/usr/share/opentsdb/tools/create_table.sh
的脚本来建一个 HBase 表. 后续步骤.
创建表
如果这是你第一次使用HBase 实例来运行 OpenTSDB , 你首先需要创建必要的 HBase 表.这里提供一个简单的脚本来创建具有是否启用压缩的表 . 执行:
env COMPRESSION=NONE HBASE_HOME=path/to/hbase-0.94.X ./src/create_table.sh
COMPRESSION
可以是NONE
,LZO
,GZIP
orSNAPPY
. 这将会分别创建:tsdb
,tsdb-uid
,tsdb-tree
andtsdb-meta
.如果你只是评估 OpenTSDB, 现在不需要着急关于压缩的问题. 在生产和规模上,确保使用一个有效的压缩库将节省大量的存储空间.
启动 TSD
OpenTSDB 2.3的守护进程和命令行工具共享于同一个配置文件.如果你是通过源码编译, 复制./src/opentsdb.conf
文件到一个正确的目录,如何根据配置文档去编辑下面的必选项:
- tsd.http.cachedir
- 缓存文件写入目录
- tsd.http.staticroot
- 静态GUI文件
./build/staticroot
- 静态GUI文件
- tsd.storage.hbase.zk_quorum
- 如果 HBase 和 Zookeeper 没有在这个主机上运行, 在这里指定主机和端口.
配置文件编辑完成后, 你可以这样启动tsd:
./build/tsdb tsd
另外, 你也可以使用下面的命令行来创建一个缓存目录并通过命令行参数启动:
tsdtmp=${TMPDIR-'/tmp'}/tsd # For best performance, make sure
mkdir -p "$tsdtmp" # your temporary directory uses tmpfs
./build/tsdb tsd --port=4242 --staticroot=build/staticroot --cachedir="$tsdtmp" --zkquorum=myhost:2181
通过http://127.0.0.1:4242 你可以连接到web接口(当它在你本地服务器运行的时候).
注意
当图像通过GUI请求创建的时候,缓存目录会临时存储这些文件. 这些文件应该定期予以删除. OpenTSDB 这时候不会自动删除, tools/clean_cache.sh
脚本应该作为计划任务,至少每天运行一次.
Upgrading from 1.x
OpenTSDB 2.3 is fully backwards compatible with 1.x data. We've taken great pains to make sure you can download 2.3, compile, stop your old TSD and start the new one. Your existing tools will read and write to the TSD without a problem. 2.3 introduces two new tables to HBase schema for storing meta-data. From the directory where you downloaded the source (or the tools directory if installed with the Debian package), execute:
env COMPRESSION=NONE HBASE_HOME=path/to/hbase-0.94.X ./src/upgrade_1to2.sh
whereCOMPRESSION
is the same as your existing production table compression format.
While you can start a 2.3 TSD with the same command line options as a 1.0 TSD, we highly recommend that you create a configuration file based on the config included at./src/opentsdb.conf
. Or if you install from a package, you'll want to edit the included default config. The config file includes many more options than are accessible via command line and the file is shared with CLI tools. SeeConfigurationfor details.
You do not have to upgrade all of your TSDs to 2.3 at the same time. Some users upgrade their read-only TSDs first to gain access to the full HTTP API and test the new features. Later on you can upgrade the write-only TSDs at leisure. You can also perform a rolling upgrade without issues. Simply stop traffic to one TSD, upgrade it, restore traffic, and continue on until you have upgraded all of your TSDs.
If you do perform a rolling upgrade where you have multiple TSDs, heed the following warning:
Warning
Do not writeAnnotationsorData point with Millisecond Timestampswhile you run a mixture of 1.x and 2.x. Because these data are stored in the same rows as regular data points, they can affect compactions and queries.
Before upgrading to 2.x, you may want to upgrade all of your TSDs to OpenTSDB 1.2. This release is fully forwards compatible in that it will ignore annotations and millisecond timestamps and operate as expected. With 1.2 running, if you accidentally record an annotation or millisecond data point, your 1.2 TSDs will operate normally.
Upgrading from 2.x to a Later 2.x
In general, upgrading within a single major release branch is simply a matter of updating the binaries or package and restarting a TSD. Within a branch we'll maintain settings, APIs and schema. However new features may be added with each minor version that include new configuration settings with useful defaults.
Note
The exception so far has been the introduction of salted rows in 2.2.0. Disabled by default, using this feature requires creating a new HBase table with a new set of pre-splits and modifying the configuration of every TSD to use the new table with salting enabled. The schema for salted and unsalted tables is incompatible so if users have a lot of data in a previous table, it may be best to leave a few TSDs running to query against the old table and new TSDs to write to and read from the new salted table. For smaller amounts of data, thescantool can be used to export and re-import your data.
Note
Likewise with 2.3, the introduction of new backends (Bigtable or Cassandra) requires setting up new storage tables and migrating data.
Downgrading
Because we've worked hard to maintain backwards compatibility, you can turn off a 2.x TSD and restart your old 1.x TSD. The only exceptions are if you have written annotations or milliseconds as you saw in the warning above. In these cases you must downgrade to 1.2 or later. You may also delete thetsdb-tree
andtsdb-meta
tables if you so desire.
Downgrades within a major version are idempotent.
Warning
If you wrote data using a salted table or changed the UID widths for metrics, tag keys or tag values then you cannot downgrade. Create a new table and export the data from the old table, then re-write the data to the new table using the older TSD version.