Writing Data

您可能想直接进入并开始将数据添加到 TSD 中,但是要 true 利用 OpenTSDB 的功能和灵 Active,您可能需要暂停并考虑一下命名架构。完成此操作后,您可以 continue 通过 Telnet 或 HTTP API 推送数据,或使用具有 OpenTSDB 支持的现有工具,例如“ tcollector”。

Naming Schema

许多 MetricsManagement 员习惯于为其时间序列提供一个名称。例如,习惯于 RRD 风格系统的系统 Management 员可以将其时间序列命名为webserver01.sys.cpu.0.user。该名称告诉我们时间序列正在记录webserver01上 cpu 0在用户空间中的时间量。如果您以后只想检索该特定 Web 服务器上该 cpu 核心的用户时间,这将非常有用。

但是,如果 Web 服务器具有 64 个核心,而您想获得所有核心的平均时间怎么办?某些系统允许您指定通配符(例如webserver01.sys.cpu.*.user),该通配符将读取所有 64 个文件并汇总结果。另外,您可以记录一个名为webserver01.sys.cpu.user.all的新时间序列,该时间序列表示相同的聚合,但现在必须编写“ 64 1”不同的时间序列。如果您有一千个 Web 服务器,并且想要所有服务器的平均 CPU 时间怎么办?您可以制作一个像*.sys.cpu.*.user这样的通配符查询,系统将打开所有 64,000 个文件,汇总结果并返回数据。或者,您可以设置一个过程来预聚合数据并将其写入webservers.sys.cpu.user.all

OpenTSDB 通过引入“标签”的概念来处理事情有所不同。每个时间序列仍然有一个“度量”名称,但它的名称更为通用,可以由许多独特的时间序列共享。相反,唯一性来自标签键/值对的组合,该组合允许使用非常快速的聚合进行灵活的查询。

Note

OpenTSDB 中的每个时间序列都必须至少具有一个标签。

以上一个示例为 Metricswebserver01.sys.cpu.0.user。在 OpenTSDB 中,这可能变成sys.cpu.user host=webserver01, cpu=0。现在,如果我们需要单个核心的数据,我们可以制作一个类似于sum:sys.cpu.user{host=webserver01,cpu=42}的查询。如果我们需要所有内核,我们只需删除 cpu 标记并要求sum:sys.cpu.user{host=webserver01}即可。这将为我们提供所有 64 个内核的汇总结果。如果我们要获得所有 1,000 台服务器的结果,则只需请求sum:sys.cpu.user。基础数据模式将彼此相邻地存储所有sys.cpu.user时间序列,因此聚合各个值非常快速且有效。 OpenTSDB 旨在使这些聚合查询尽可能快,因为大多数用户都是从较高的级别开始的,然后深入了解详细信息。

Aggregations

尽管标记系统很灵活,但是如果您不了解 OpenTSDB 的查询方面,可能会出现一些问题,因此需要预先考虑。以上面的示例查询:sum:sys.cpu.user{host=webserver01}。我们为webserver01记录了 64 个唯一的时间序列,每个 CPU 内核一个时间序列。当我们发出该查询时,将检索,平均和带有标记host=webserver01的度量sys.cpu.user的所有时间序列,并作为一组数字返回。假设时间戳记1356998400的结果平均值为50。现在,我们正在从另一个系统迁移到 OpenTSDB,并且该过程具有预先聚合所有 64 个内核的过程,以便我们可以快速获取平均值,并只需编写一个新的时间序列sys.cpu.user host=webserver01即可。如果我们运行相同的查询,则在1356998400处将获得100的值。发生了什么? OpenTSDB 汇总了所有 64 个时间序列预汇总的时间序列,以达到 100 个时间序列。在存储中,我们将具有以下内容:

sys.cpu.user host=webserver01        1356998400  50
sys.cpu.user host=webserver01,cpu=0  1356998400  1
sys.cpu.user host=webserver01,cpu=1  1356998400  0
sys.cpu.user host=webserver01,cpu=2  1356998400  2
sys.cpu.user host=webserver01,cpu=3  1356998400  0
...
sys.cpu.user host=webserver01,cpu=63 1356998400  1

如果未提供标签,OpenTSDB 将自动汇总查询中度量的时间序列的所有*。如果定义了一个或多个标签,则无论其他标签如何,聚合都将“包含”与该标签匹配的所有时间序列。对于查询sum:sys.cpu.user{host=webserver01},我们将包括sys.cpu.user host=webserver01,cpu=0以及sys.cpu.user host=webserver01,cpu=0,manufacturer=Intelsys.cpu.user host=webserver01,foo=barsys.cpu.user host=webserver01,cpu=0,datacenter=lax,department=ops。此示例的寓意是:请谨慎使用命名架构

时间序列基数

任何命名架构的关键方面都是要考虑时间序列的基数。基数定义为一组中唯一项的数量。在 OpenTSDB 的情况下,这意味着与度量标准关联的项目数,即所有可能的标签名称和值组合,以及唯一的度量标准名称,标签名称和标签值的数量。由于以下两个原因,基数很重要。

有限的唯一 ID(UID)

每个 Metrics,标签名称和标签值分配的唯一 ID 数量有限。默认情况下,每种类型可能有超过 1600 万个 ID。例如,如果您运行了一种非常流行的 Web Service,并尝试将 Client 的 IP 地址作为标签进行跟踪,例如web.app.hits clientip=38.26.34.10,因为可能有超过 40 亿个 IP 版本 4 地址,所以您可能会很快遇到 UID 分配限制。此外,这种方法会导致创建非常稀疏的时间序列,因为地址38.26.34.10的用户只能偶尔使用您的应用,或者可能永远不会再使用该特定地址。

对于标签很少变化的小型安装(例如,股票代码或一组固定的传感器),UID 大小可能不是问题。为标签值分配了一个与标签名称完全无关的 UID。如果将数字标识符用于标记值,则将为数字分配一次 UID,并且可以将其与许多标记名称一起使用。例如,如果将 UID 分配给数字2,则可以将时间序列与标签对cpu=2interface=2hdd=2fan=2存储在一起,而仅消耗 1 个标签值 UID(2)和 4 个标签名称 UID(cpuinterfacehddfan)。

如果您认为 UID 限制可能会影响您,请首先考虑要执行的查询。如果我们看上面的web.app.hits示例,您可能只关心服务的命中总数,几乎不需要深入到特定的 IP 地址。在这种情况下,您可能希望将 IP 地址存储为 Comments。这样,您仍然可以从低基数中受益,但是如果需要,您可以使用外部脚本搜索该特定 IP 的结果。

当存储具有高基数或更改基数的源的数据时(例如 Docker 群),则可以通过设置tsd.storage.uid.width.metrictsd.storage.uid.width.tagktsd.storage.uid.width.tagv(最大值为 7)来更改 UID 宽度。您只能在创建新的 TSDB 安装时执行此操作。

Warning

您的情况可能需要增加此值。如果选择修改此值,则必须从新数据和新的 UID 表开始。任何用 TSD 编写的,期望 3 字节 UID 编码的数据都将与此更改不兼容,因此,请确保所有 TSD 都以相同的配置运行,并且在进行此更改之前已将存储在 OpenTSDB 中的任何数据导出到一个可以被外部工具操纵的位置。

Query Speed

基数也会极大地影响查询速度,因此请考虑将频繁执行的查询,并针对这些查询优化命名架构。 OpenTSDB 在每个时间序列每小时创建一个新行。如果我们有一台具有单个内核的主机,该主机发出一个时间序列sys.cpu.user host=webserver01,cpu=0,并且每秒写入一次数据,持续 1 天,则将导致 24 行数据或 86,400 个数据点。但是,如果我们有 8 个可能用于该主机的 CPU 内核,那么现在我们有 192 行和 691,200 个数据点。这看起来不错,因为通过发出类似start=1d-ago&m=avg:sys.cpu.user{host=webserver01}的查询,我们可以轻松获得所有内核的 CPU 使用率的总和或平均值。该查询将遍历所有 192 行,并将数据聚合为单个时间序列。

但是,如果我们有 20,000 个主机,每个主机有 8 个核心,该怎么办?由于主机值的高基数,现在我们每天将有 380 万行和 17.28 亿个数据点。对主机webserver01的平均核心使用情况的查询将较慢,因为它必须从 380 万中选择 192 行。 (但是,对于 OpenTSDB 2.2,您可以使用显式标签功能来指定cpu=*,模糊过滤器将启动以帮助更快地跳过那些不必要的行.)

这种模式的好处是您的数据具有非常深的粒度,例如,按核心存储使用情况 Metrics。您还可以轻松地进行查询,以获取所有主机的所有内核的平均使用率:start=1d-ago&m=avg:sys.cpu.user。但是,由于要筛选的行更多,因此针对该特定 Metrics 的查询将花费更长的时间。这在所有数据库中都很常见,而不仅仅是 OpenTSDB 的问题。

以下是一些处理基数的常用方法:

Pre-Aggregate -在上面带有sys.cpu.user的示例中,您通常关心主机上的平均使用情况,而不是每个核心的使用情况。尽管数据收集器可以使用上面的标记架构为每个内核发送单独的值,但收集器还可以发送一个额外的数据点,例如sys.cpu.user.avg host=webserver01。现在,您有了一个完全独立的时间序列,每天只有 24 行,并且有 20K 主机,因此只能筛选 48 万行。对于每个主机的平均值,查询将响应更快,并且您仍然具有每个核心的数据可以分别进行深入分析。

转换为 Metrics -如果您真的只关心特定主机的 Metrics,而无需在主机之间进行汇总该怎么办?在这种情况下,您可以将主机名转换为 Metrics。我们之前的示例变为sys.cpu.user.websvr01 cpu=0。针对该架构的查询非常快,因为该 Metrics 每天只有 192 行。但是,要跨主机聚合,您将必须执行多个查询并在 OpenTSDB 外部聚合。 (Future 的工作将包括此功能)。

Naming Conclusion

在设计命名架构时,请牢记以下建议:

  • 与您的命名保持一致,以减少重复。度量,标签名称和值始终使用相同的大小写。

  • 每个 Metrics 使用相同数量和类型的标签。例如。不要存储my.metric host=foomy.metric datacenter=lga

  • 考虑一下您将要执行的最常见查询,并针对这些查询优化方案

  • 考虑一下在查询时您可能想如何下钻

  • 不要使用太多标签,而应将其保持在一个相当小的数目,通常最多 4 或 5 个标签(默认情况下,OpenTSDB 最多支持 8 个标签)。如果绝对需要,您可以_can 随时增加可用于集群的标签数量。

Data Specification

每个时间序列数据点都需要以下数据:

  • metric-时间序列的通用名称,例如sys.cpu.userstock.quoteenv.probe.temp

  • timestamp-Unix/POSIX 纪元时间戳,以秒或毫秒为单位,定义为自 1970 年 1 月 1 日 UTC 时间 00:00:00 起经过的秒数。目前仅支持正时间戳。

  • value-在时间序列的给定时间戳记下存储的数值。这可以是整数或浮点值。

  • 标记-由tagk(键)和tagv(值)组成的键/值对。每个数据点必须至少具有一个标签。

Timestamps

可以以秒或毫秒的分辨率将数据写入 OpenTSDB。时间戳记必须是整数,并且不得超过 13 位数字(请参阅下面的第一个[NOTE])。毫秒时间戳的格式必须为1364410924250,其中最后三位数字表示毫秒。产生超过 13 位数字(即大于毫秒分辨率)的时间戳的应用程序必须在提交前四舍五入到最多 13 位数字,否则会产生错误。

具有秒分辨率的时间戳存储在 2 个字节中,而毫秒分辨率的存储在 4 个字节上。因此,如果您不需要毫秒分辨率或所有数据点都位于 1 秒边界上,我们建议您提交具有 10 位数字的时间戳作为秒分辨率您可以节省存储空间。避免在给定的时间序列中混合秒和毫秒时间戳也是一个好主意。这样做会降低查询速度,因为跨混合时间戳的迭代比只记录一种或另一种类型的时间更长。 OpenTSDB 将存储您提供的任何内容。

Note

写入 telnet 接口时,可以选择以1364410924.250的形式写入时间戳,其中在毫秒后放置代表毫秒的三位数字。通过 HTTP 发送到/api/put终结点的时间戳*必须为整数,并且不能包含句点。目前只能通过/api/query端点或 CLI 命令提取具有毫秒分辨率的数据。有关详细信息,请参见查询/索引。

Note

提供毫秒分辨率并不一定意味着 OpenTSDB 在许多时间序列上支持每毫秒 1 个数据点的写入速度。虽然单个 TSD 可能每秒可以处理数千次写入,但是如果您尝试每毫秒存储一个点,则仅涵盖几个时间序列。相反,OpenTSDB 旨在提供更高的测量精度,并且通常应避免以这种速度记录数据,特别是对于长时间运行的序列。

Metrics 和标签

以下规则适用于 Metrics 和标签值:

  • 字符串区分大小写,即“ Sys.Cpu.User”将与“ sys.cpu.user”分开存储

  • 不允许有空格

  • 仅允许以下字符:azAZ09-_./或 Unicode 字母(根据规范)

度量标准和标记的长度没有限制,尽管您应尝试使值保持较短。

Integer Values

如果解析来自put命令的值时不带小数点(.),则将其视为有符号整数。整数以可变长度编码存储,无符号,因此数据点可能只占用 1 个字节的空间或最多 8 个字节的空间。这意味着数据点的最小值为-9,223,372,036,854,775,808,最大值为 9,223,372,036,854,775,807(含)。整数不能包含逗号或除数字和破折号(用于负值)以外的任何字符。例如,为了存储最大值,必须以9223372036854775807的形式提供。

浮点值

如果将put命令中的值解析为小数点(.),它将被视为浮点值。当前,所有浮点值均以 4 字节单精度存储,并在 2.4 及更高版本中支持 8 字节双精度。浮点数以 IEEE 754 浮点“单一格式”存储,支持正负值。不支持 Infinity 和非数字值,如果提供给 TSD,则会抛出错误。有关详情,请参见WikipediaJava Documentation

Note

由于 OpenTSDB 仅支持浮点值,因此不适用于存储需要精确值(例如货币)的度量。这就是为什么在存储类似15.2的值时数据库可能返回15.199999809265137的原因。

Ordering

与其他解决方案不同,OpenTSDB 允许以所需的任何 Sequences 写入给定时间序列的数据。这样可以在将数据写入 TSD 时提供极大的灵 Active,从而可以从系统中填充当前数据,然后在以后导入历史数据。

重复的数据点

在 OpenTSDB 中写入数据点通常在原始写入后的一个小时内是幂等的。这意味着您可以在时间戳1356998400处写入值42,然后在同一时间再次写入42,不会发生任何不良情况。但是,如果启用压缩以减少存储消耗并在压缩该行数据之后写入相同的数据点,则在该行上查询时可能会返回异常。如果您尝试使用相同的时间戳写入两个不同的值,则在查询期间可能会引发重复的数据点异常。这是由于对 1、2、4 或 8 个字节的整数和浮点数进行编码的差异。如果第一个值是整数,第二个值是浮点数,则始终会引发重复错误。但是,如果两个值都是浮点数,或者都是可以以相同长度编码的整数,那么如果未在行上进行压缩,则原始值可能会被覆盖。

在大多数情况下,如果写入重复的数据点,通常表明数据源出了点问题,例如进程意外重启或脚本中的错误。当您在具有一个或多个重复项的行中查询时,OpenTSDB 将抛出异常,从而“安全”失败,从而可以解决问题。

使用 OpenTSDB 2.1,可以通过将tsd.storage.fix_duplicates配置值设置为true来启用最后写入胜出。启用此标志后,在查询时,将返回记录的最新值,而不是引发异常。还将向日志文件中写入警告,指出已找到重复项。如果还启用了压缩,则原始压缩值将被最新值覆盖。

Input Methods

当前有三种将数据获取到 OpenTSDB 的主要方法:Telnet API,HTTP API 和从文件批量导入。或者,您可以使用提供 OpenTSDB 支持的工具,或者,如果您非常喜欢冒险,请使用 Java 库。

Warning

请勿尝试直接写入基础存储系统,例如 HBase。只是不要。很快就会变得凌乱。

Note

如果tsd.mode设置为ro而不是rw,则 TSD 将不会通过 RPC 调用接受数据点。 Telnet 样式调用将引发异常,并且对 HTTP 端点的调用将返回 404 错误。但是,当模式设置为只读时,仍然可以通过 JAVA API 进行写入。

Telnet

开始使用 OpenTSDB 的最简单方法是打开一个终端或 telnetClient 端,连接到您的 TSD 并发出put命令并点击“ enter”。如果要编写程序,只需打开一个套接字,用新行打印 string 命令并发送数据包。 telnet 命令格式为:

put <metric> <timestamp> <value> <tagk1=tagv1[ tagk2=tagv2 ...tagkN=tagvN]>

For example:

put sys.cpu.user 1356998400 42.5 host=webserver01 cpu=0

每个put只能发送一个数据点。不要忘记换行符,例如\n在命令末尾。

Note

不鼓励使用 Telnet 写入方法,因为它没有提供确定由于格式化或存储错误而导致哪些数据点写入失败的方法。而是使用 HTTP API。

Http API

从 2.0 版开始,可以通过“ Serializer”插件支持的格式通过 HTTP 发送数据。可以在单个 HTTP POST 请求中发送多个不相关的数据点,以节省带宽。有关详细信息,请参见../api_http/put。

Batch Import

如果要从另一个系统导入数据,或者需要回填历史数据,则可以使用import CLIUtil。有关详细信息,请参见 cli/import。

Write Performance

OpenTSDB 可以扩展到在具有常规旋转硬盘的商品服务器上每秒“写入”数百万个数据点。但是,如果用户只能以每秒数百个点的速度写入数据,则对以独立模式使用 HBase 启动 VM 并尝试在全新的 TSD 上捕获数百万个数据点的用户感到失望。这是您进行扩展以进行全新安装或测试以及扩展现有系统所需要做的。

UID Assignment

人们遇到的第一个症结是“ uid 分配”。在可以存储数据点之前,必须为度量,标记键和标记值的每个字符串分配一个 UID。例如,度量标准sys.cpu.user可能在 TSD 首次遇到时被分配000001的 UID。此分配需要花费大量时间,因为它必须获取可用的 UID,将 UID 写入名称 Map,并将名称写入 UIDMap,然后使用 UID 写入数据点的行键。 UID 将存储在 TSD 的缓存中,以便下次使用相同度量时,它可以非常快速地找到 UID。

因此,我们建议您将 UID“预分配”给尽可能多的度量标准,标记键和标记值。如果按照上面的建议设计了命名模式,则将知道要分配的大多数值。您可以使用 CLI 工具 cli/mkmetric,cli/uid 或 HTTP API ../api_http/uid/index 执行预分配。每当您要向运行中的 OpenTSDB 集群发送大量新 Metrics 或标签时,请尝试进行预分配,否则 TSD 在获取新数据时会陷入困境。

Note

如果重新启动 TSD,则必须为每个度量标准和标记查找 UID,因此在填充高速缓存之前,性能会有些慢。

随机 MetricsUID 分配

使用 2.2,您可以将 UID 随机分配给 Metrics,以实现更好的区域服务器写分配。由于度量标准 UID 位于行键的开头,因此,如果创建了一组新的繁忙度量标准,则这些度量标准的所有写入都将在同一服务器上,直到该区域拆分为止。启用随机 UID 生成后,新 Metrics 将分布在关键空间中,并可能会出现在不同服务器上的不同区域中。

可以通过修改tsd.core.uid.random_metrics标志随时启用或禁用随机度量标准生成,并且数据一直向下兼容 OpenTSDB 1.0. 但是,建议您根据完整的度量 UID 空间预先分割 TSDB 数据表。例如。如果您在 OpenTSDB 中使用默认的 UID 大小,则 UID 的宽度为 3 个字节,因此可以有 16,777,215 个值。如果 TSDB 表中已经有数据并选择启用随机 UID,则可能要创建新区域。

生成随机 ID 时,TSDB 最多尝试 10 次以分配 UID 而不会发生冲突。因此,随着分配的度量标准数量的增加,冲突的数量和数据点可能由于重试而丢失的可能性也会随之增加。如果启用随机 ID 并 continue 添加更多 Metrics,则可能需要增加 MetricsUID 的字节数。请注意,UID 更改不向后兼容,因此您必须创建一个新表并迁移旧数据。

Salting

在 2.2 中,支持加盐以大大增加跨区域服务器的写入分布。启用后,每个行键之前都会配置一定数量的字节。然后,将每个度量标准和标签组合散列到一个“存储桶”中,其“ ID”被写入盐字节。由于时间序列跨已配置的存储桶数分配,因此特别针对高基数 Metrics(具有大量标签组合的 Metrics)改善了分配,从而将其路由到不同的区域和不同的服务器。例如,在不加盐的情况下,具有一百万个系列的度量将被写入单个服务器上的单个区域。启用加盐功能后,存储区大小为 20,则该系列将分为 20 个区域(如果群集具有那么多的主机,则分为 20 个服务器),每个区域具有 50,000 个系列。

Warning

由于加盐会修改存储格式,因此您一时无法启用或禁用加盐。如果已有数据,则必须启动一个新数据表并将数据从旧表迁移到新表中。无法从早期版本的 OpenTSDB 中读取含盐数据。

要启用盐析,您必须修改配置文件参数tsd.storage.salt.width,也可以修改tsd.storage.salt.buckets。我们建议将盐的宽度设置为1,并根据集群中区域服务器数量的因素确定存储桶的数量。请注意,在查询时,TSD 将触发tsd.storage.salt.buckets数量的扫描仪以获取数据。盐桶的正确数量必须通过实验确定,因为在某些时候,由于打开太多的扫描器并整理结果,查询性能可能会受到影响。将来盐的宽度和水桶可能是可配置的,但我们不希望人们在发生事故时更改设置并丢失数据。

Appends

同样在 2.2 中,现在支持通过追加写入 HBase 列。这可以提高读取和写入性能,因为 TSD 将不再在每个小时结束时维护要压缩的行队列,从而防止了 HBase 中的大量读取和重写操作。但是,由于附加操作在 HBase 中的操作方式,区域服务器上 CPU 使用率,存储文件大小和 HDFS 流量都会增加。确保密切监视 HBase 服务器。

在读取时,每行仅返回一列,类似于 TSD 压缩后行。但是请注意,如果启用了tsd.storage.repair_appends,则当列中有重复数据或数据混乱时,它将被重新写入 HBase。同样,包含很多重复项或排序问题的列也可能减慢查询速度,因为必须在回答呼叫者之前解决它们。

可以随时启用和禁用附加。但是,2.2 之前的 OpenTSDB 版本将跳过附加值。

预分割 HBase 区域

对于全新安装,无论您是在独立服务器上进行测试还是在运行完整集群时,如果在 HBase 中预分割区域,您都会看到更好的性能。 HBase 区域处理定义的行键范围,并且实质上是单个文件。当您创建tsdb表并首次开始写入数据时,所有这些数据点都将发送到一个服务器上的该文件中。当某个区域填满时,HBase 会自动将其拆分为不同的文件,并将其移至群集中的其他服务器,但是当发生这种情况时,TSD 无法写入该区域,并且必须缓冲数据点。因此,如果您可以在开始写入之前预先分配多个区域,则 TSD 可以将数据发送到多个文件或服务器,您将立即利用线性可伸缩性。

预分割tsdb表区域的最简单方法是估计将要记录的唯一度量标准名称的数量。如果您已经设计了一个命名模式,那么您应该有一个很好的主意。假设我们将在系统中跟踪 4,000 个 Metrics。这并不是说有 4,000 个时间序列,因为我们还没有计算标签,仅是 Metrics 名称,例如“ sys.cpu.user”。数据点写入行键,其中度量标准的 UID 包含前几个字节,默认情况下为 3 个字节。第一个 Metrics 将被分配000001的 UID 作为十六进制编码值。第 4,000 个度量标准的 UID 为000FA0(十六进制)。您可以将它们用作HBase Book脚本中的开始键和结束键,以将表拆分为任意数量的区域。 256 个区域可能是一个不错的起点,具体取决于每个 Metrics 共享多少时间序列。

hbase org.apache.hadoop.hbase.util.RegionSplitter tsdb UniformSplit -c 256 -f t

上面的简单拆分方法假设每个 Metrics 的时间序列数量大致相等(即基数相当一致)。例如。 UID 为000001的 Metrics 可能有 200 个时间序列,而000FA0则有约 150 个时间序列。如果每个 Metrics 的时间序列范围很广,例如000001具有 10,000 个时间序列,而000FA0仅具有 2 个时间序列,您可能需要开发更复杂的拆分算法。

但是,不必担心拆分。如上所述,HBase 会自动为您分割区域,因此随着时间的推移,数据将相当平均地分布。

Distributed HBase

HBase 将以独立模式运行,它将使用本地文件系统存储文件。它仍将使用多个区域并具有与基础磁盘或 RAID 阵列相同的性能。您肯定要在 HBase 下使用 RAID 阵列,以便在驱动器发生故障时可以替换它而不会丢失数据。这种设置非常适合测试或非常小的安装,并且您应该能够每秒获得数千个数据点。

但是,如果要提高吞吐量和可伸缩性,则必须设置具有多个服务器的 Hadoop 和 HBase 集群。在分布式设置中,HDFSManagement 区域文件,自动将副本分发到其他服务器以实现容错功能。 HBase 将区域分配给不同的服务器,OpenTSDB 的 Client 端会将数据点发送到将要存储它们的特定服务器。您现在可以在多个服务器之间分散操作,从而提高性能和存储量。如果您需要更高的吞吐量或存储空间,只需添加节点或磁盘即可。

设置 Hadoop/HBase 集群和进行各种调整的方法有很多种,因此 Google 到处找用户群寻求建议。一些一般性建议包括:

  • 为名称节点专用一对高内存,低磁盘空间的服务器。使用 Heartbeat 和 Pacemaker 等将它们设置为高可用性。

  • 在至少 3 台服务器上设置 Zookeeper 以实现容错功能。它们必须具有大量的 RAM 和相当快的磁盘才能进行日志写入。在小型群集上,它们可以在“名称”节点服务器上运行。

  • HDFS 数据节点的 JBOD

  • HBase 区域服务器可以与 HDFS 数据节点并置

  • 服务器之间的链接至少为 1 gbps,最好为 10 gbps。

  • 将群集保留在单个数据中心中

Multiple TSDs

一个 TSD 每秒可以处理数千次写入。但是,如果您有许多来源,则最好通过运行多个 TSD 并使用负载均衡器(例如 Varnish 或 DNS 循环)来扩展写入,以进行扩展。当群集专用于 OpenTSDB 时,许多用户在其 HBase 区域服务器上放置 TSD。

Persistent Connections

在 TSD 中启用保持活动状态,并确保用于发送时间序列数据的任何应用程序保持其连接打开,而不是每次写入都打开和关闭。有关详细信息,请参见配置。

禁用元数据和实时发布

OpenTSDB 2.0 引入了元数据,用于跟踪系统中的数据种类。启用跟踪后,每个写入的数据点都会增加一个计数器,新的 UID 或时间序列将生成元数据。数据可以推送到搜索引擎或通过树生成代码传递。这些过程在 TSD 中需要更大的内存,并可能影响吞吐量。跟踪默认情况下处于禁用状态,因此请在启用此功能之前对其进行测试。

2 .0 还引入了一个实时发布插件,在该插件中,传入的数据点在排队存储后可以立即发送到另一个目标。默认情况下禁用此功能,因此在生产环境中部署之前,请测试您感兴趣的所有插件。