InfluxDB是一个由InfluxData开发的开源时序型数据库。它由Go写成，着力于高性能地查询与存储时序型数据。InfluxDB被广泛应用于存储系统的监控数据，

它还是没有额外依赖的开源时序数据库，用于记录 metrics、events，进行数据分析。何谓时间序列数据库？

什么是时间序列数据库，最简单的定义就是数据格式里包含Timestamp字段的数据，比如某一时间环境的温度，CPU的使用率等。但是，有什么数据不包含Timestamp呢？几乎所有的数据其实都可以打上一个Timestamp字段。时间序列数据的更重要的一个属性是如何去查询它，包括数据的过滤，计算等等。一般时间序列数据都具备如下两个特点：

数据结构简单数据量大所谓的结构简单，可以理解为某一度量指标在某一时间点只会有一个值，没有复杂的结构（嵌套、层次等）和关系（关联、主外键等）。

数据量大则是另一个重要特点，这是由于时间序列数据由所监控的大量数据源来产生、收集和发送，比如主机、物联网设备、终端或App等。

一、InfluxDB 简介

InfluxDB主要特色功能 1.基于时间序列，支持与时间有关的相关函数（如最大，最小，求和等）

2.可度量性：你可以实时对大量数据进行计算

3.基于事件：它支持任意的事件数据

InfluxDB的主要特点 1.无结构（无模式）：可以是任意数量的列

2.可拓展的

3.支持min, max, sum, count, mean, median 等一系列函数，方便统计

4.原生的HTTP支持，内置HTTP API

5.强大的类SQL语法

6.自带管理界面，方便使用

官网文档：https://docs.influxdata.com/influxdb/v1.7/

二、InfluxDB安装

本文以操作系统RedHat & CentOS为例，介绍下InfluxDB最新版本的安装。RedHat和CentOS用户可以直接用yum包管理来安装最新版本的InfluxDB。

cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF

一旦加到了yum源里面，就可以运行下面的命令来安装和启动InfluxDB服务：

sudo yum install influxdb

目前最新版本为1.7.3-1

三、InfluxDB启动

1.服务端启动如果是通过包安装的，可以使用如下语句启动：

sudo service influxdb start 这样就启动了服务端

2.客户端在usr/bin里使用influx即可登入Influx服务器。也可以将路径加入环境变量中，这样既可在任意地方使用influx。

命令启动客户端，如下图：

早期版本的InfluxDB自带web管理界面，在浏览器中输入 http://服务器IP:8083 即可进入web管理页面。

不过从版本1.3开始，Web管理界面在InfluxDB中不再可用。而官方给出使用Chronograf用于查询数据，写入数据和数据库管理的改进工具取代了Web管理界面。

后面我们详细介绍一下Chronograf

四、InfluxDB相关操作

1.开启认证

创建管理员

修改配置文件，开启认证

重启InfluxDB：

systemctl restart influxdb

再次登录

客户端工具连接数据库：

注：这里的-precision参数指定了时间戳的格式为rfc3339，也可以不使用该参数。

2.相关概念 influxDB相关名词

database：数据库。

measurement：数据库中的表。它就是tag，field，time的容器；对于influxDB的measurement来说，field是必须的，并且不能根据field来排序；

Tag是可选的，tag可以用来做索引，tag是以字符串的形式存放的。

points：表里面的一行数据。

influxDB中独有的概念

（1）Point由时间戳（time）、数据（field）和标签（tags）组成。

time：每条数据记录的时间，也是数据库自动生成的主索引；

fields：各种记录的值；

tags：各种有索引的属性。

InfluxDB不需要做schema定义，这意味着你可以随意的添加measurements, tags, and fields at any time。

（2）series

所有在数据库中的数据，都需要通过图表来展示，而这个series表示这个表里面的数据，可以在图表上画成几条线：通过tags排列组合算出来。

其实一个series就是一个测点，或者说一条曲线，那么retention policy, measurement, tagset就共同组成了一个定位测点序列的唯一标识。

point，就是某个series的同一个时刻的多个field的value，就组成了一个point；其实就是一条曲线上的一个点。

influxDB与传统数据库中的名词做比较

（3）retention policy

保留策略，用于决定要保留多久的数据，保存几个备份，以及集群的策略等。

3.相关操作

查看数据库：

创建数据库：

使用数据库：

插入数据：

influxDB存储数据采用的是Line Protocol格式。

Line Protocol格式：写入数据库的Point的固定格式。格式如下：

<measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [unix-nano-timestamp]

比如：

> INSERT cpu,host=serverA,region=us_west value=0.64

其中：

cpu是表名

host=serverA,region=us_west 是tag

value=0.64是field

查询数据：

influxDB是支持类sql语句的，具体的查询语法都差不多。

比如：select * from cpu

注：InfluxDB集群功能已经不再开源。要想使用集群服务需要购买企业版。

开源版和企业版的主要区别就是企业版的InfluxDB支持集群，而开源版不支持，此外企业版提供了先进的备份/恢复功能，而开源版本没有。

但InfluxDB单机版性能也足够支撑中小公司的业务了。

4.数据保存策略

InfluxDB每秒可以处理成千上万条数据，要将这些数据全部保存下来会占用大量的存储空间，有时我们可能并不需要将所有历史数据进行存储。

因此，InfluxDB推出了数据保留策略（Retention Policies），用来让我们自定义数据的保留时间。InfluxDB的数据保留策略用来定义数据在InfluxDB中存放的时间，或者定义保存某个期间的数据。

一个数据库可以有多个保留策略，但每个策略必须是独一无二的。

查询策略

可以通过如下语句查看数据库的现有策略：

数据库telegraf只有一个策略，各字段的含义如下：

name：名称，此示例名称为 autogen。当你创建一个数据库的时候，InfluxDB会自动为数据库创建一个名叫 autogen 的策略，这个策略会永久保存数据。你可以重命名这个策略，并且在InfluxDB的配置文件中禁止掉自动创建策略。

duration：数据保存时间，0代表无限制 shardGroupDuration：shardGroup的存储时间，shardGroup是InfluxDB的一个基本储存结构。 replicaN：全称是REPLICATION，副本个数 default：是否是默认策略。这里有两个概念：

shard：

shard 在 InfluxDB 中是一个比较重要的概念，它和 retention policy（数据保留策略）相关联。每一个存储策略下会存在许多 shard，每一个 shard 存储一个指定时间段内的数据，

并且不重复，例如 7点-8点的数据落入 shard0 中，8点-9点的数据则落入 shard1 中。每一个 shard 都对应一个底层的 TSM 存储引擎，有独立的 cache、wal、tsm file。

创建数据库时会自动创建一个默认存储策略，永久保存数据，对应的在此存储策略下的 shard 所保存的数据的时间段为 7 天，也就是上面查询时看到的168h。

如果创建一个新的 retention policy 设置数据的保留时间为 1 天，则单个 shard 所存储数据的时间间隔为 1 小时，超过1个小时的数据会被存放到下一个 shard 中。

shard group：

shard group是shards的逻辑容器。

创建策略

语法：

CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]

：SHARD DURATION子句决定了每个shard group存储的时间间隔，在永久存储的策略里这个子句是无效的。这个子句是可选的。shard group duration默认由策略的 duration 决定。

示例1：为数据库telegraf创建一个策略

CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 1d REPLICATION 1

示例2：为数据库telegraf创建一个默认策略

CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 24h REPLICATION 1 DEFAULT

修改策略

语法：

ALTER RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> SHARD DURATION <duration> DEFAULT

删除策略

语法：

DROP RETENTION POLICY <retention_policy_name> ON <database_name>

注：当一个表使用的策略不是默认策略时，在进行操作时一定要显式的指定策略名称，否则会出现错误。

InfluxDB命令集合：

SHOW MEASUREMENTS --查询当前数据库中含有的表

SHOW FIELD KEYS --查看当前数据库所有表的字段

SHOW series from pay --查看key数据

SHOW TAG KEYS FROM "pay" --查看key中tag key值

SHOW TAG VALUES FROM "pay" WITH KEY = "merId" --查看key中tag 指定key值对应的值

SHOW TAG VALUES FROM cpu WITH KEY IN ("region", "host") WHERE service = 'redis'

DROP SERIES FROM <measurement_name[,measurement_name]> WHERE <tag_key>='<tag_value>' --删除key

SHOW CONTINUOUS QUERIES --查看连续执行命令

SHOW QUERIES --查看最后执行命令

KILL QUERY --结束命令

SHOW RETENTION POLICIES ON mydb --查看保留数据

查询数据

SELECT * FROM /.*/ LIMIT 1 --查询当前数据库下所有表的第一行记录

select * from pay order by time desc limit 2

select * from db_name."POLICIES name".measurement_name --指定查询数据库下数据保留中的表数据 POLICIES name数据保留

删除数据

delete from "query" --删除表所有数据，则表就不存在了

drop MEASUREMENT "query" --删除表（注意会把数据保留删除使用delete不会）

DELETE FROM cpu

DELETE FROM cpu WHERE time < '2000-01-01T00:00:00Z'

DELETE WHERE time < '2000-01-01T00:00:00Z'

DROP DATABASE “testDB” --删除数据库

DROP RETENTION POLICY "dbbak" ON mydb --删除保留数据为dbbak数据

DROP SERIES from pay where tag_key='' --删除key中的tag

SHOW SHARDS --查看数据存储文件

DROP SHARD 1

SHOW SHARD GROUPS

SHOW SUBSCRIPTIONS

5.Chronograf

Influxdb在1.3以后版本已经关闭了内置的8086的web管理功能，需要单独的工具来管理。而这个工具就是Chronograf。

其实Chronograf是TICK技术栈的一个组成部分。TICK是InfluxdDB公司推出的监控套件，承包指标采集、分析、画图等时序数据库上下游的工作，有点模仿日志分析系统ELK套件的意思。TICK包含：

Telegraf：数据采集

InfluxDB：数据接收和存储

Chronograf：数据汇总展示，报警等

Kapacitor：数据处理，比如监控策略等

下载Chronograf

下载地址：https://portal.influxdata.com/downloads

安装Chronograf

启动Chronograf

systemctl start chronograf

访问Chronograf

浏览器输入http://IP:8888

查询：

丰富的界面操作，易于查询、查看、统计分析等，使用起来非常方便。

五、数据备份与恢复

备份数据的命令格式

influxd backup -database [name] [path-to-backup]

远程备份：

influxd backup -database myinfo -host 0.0.0.0:8088 /home/gooagoo/influxDB/backup

0.0.0.0替换为ip地址

恢复数据的命令格式

 influxd restore [ -metadir | -datadir ] <path-to-meta-or-data-directory> <path-to-backup>

六、综合案例：Telegraf + InfluxDB + Grafana

1.Telegraf

Telegraf 是用Go写的代理程序，可以用于收集系统和服务的统计数据，是TICK技术栈的一部分。它具备输入插件，可以直接从系统获取指标数据，从第三方API获取指标数据，甚至可以通过Kafka获取指标数据。它还具备输出插件，可以将采集的指标发送到各种数据存储，服务和消息队列。比如InfluxDB，Graphite，OpenTSDB，Datadog，Librato，Kafka，MQTT等等。

下载安装Telegraf

wget https://dl.influxdata.com/telegraf/releases/telegraf-1.9.3-1.x86_64.rpm

sudo yum install telegraf-1.9.3-1.x86_64.rpm

telegraf -version

如果你的telegraf是安装的，其配置文件位置为：

/etc/telegraf/telegraf.conf

编辑配置文件，将我们配置好的Influxdb数据库指定为期望的输出源：

[[outputs.influxdb]]

urls=["http://localhost:8086"]

启动服务、添加开机启动：

sudo systemctl start telegraf.service

sudo service telegraf status

sudo systemctl enable telegraf.service

在InfluxDB上检查默认配置下Telegraf采集了哪些数据：

> show databases
> use telegraf
> show measurements
> SHOW FIELD KEYS

如何进行配置：

# Read metrics about cpu usage
# 读取有关CPU使用情况的指标
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false
## If true, compute and report the sum of all non-idle CPU states.
report_active = false

# Read metrics about disk usage by mount point
# 通过mount point读取有关磁盘使用情况的指标
[[inputs.disk]]
## Ignore mount points by filesystem type.
ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"]

# Read metrics about disk IO by device
# 通过device读取有关磁盘IO的指标
[[inputs.diskio]]

# Get kernel statistics from /proc/stat
# 通过/proc/stat获取内核统计信息
[[inputs.kernel]]
# no configuration

# Read metrics about memory usage
# 读取有关内存使用量的指标
[[inputs.mem]]
# no configuration

# Get the number of processes and group them by status
# 获取进程的数量并按状态分组
[[inputs.processes]]
# no configuration

# Read metrics about swap memory usage
# 读取有关交换内存使用量的指标
[[inputs.swap]]
# no configuration

# Read metrics about system load & uptime
# 读取有关系统负载和运行时间的指标
[[inputs.system]]
# no configuration

如何查找指标及其采集数据

telegraf主要分为输入插件和输入插件，其源码目录分别对应plugins/inputs和plugins/outputs，你只要参考telegraf官档找到你所需要的插件然后去到源码对应的目录找到相应的.md文件，按照提示获取相关信息进行配置即可。

启用telegraf服务后，你会发现在InfluxDB中多了一个telegraf的库，其中有多个measurement，这说明我们的数据采集已经成功了。有了数据以后，我们需要关心的是如何把数据聚合然后进行展示。

2.Grafana展示

下载安装基本配置请参考wiki：大数据图表监控分析工具Grafana

这里简单讲解一下如何使用Grafana展示Telegraf收集的相关数据。

启动服务后访问 http://ip:3000，默认端口为3000，可在配置文件修改。登录后按照提示配置数据源，我们选择InfluxDB作为数据源：

根据配置信息填写相关的InfluxDB的配置项

接着创建一个dashboard：

我们先选择导入模板的方式来预览效果，再来了解grafana/dashboard的相关配置，这里选择官方提供的一套Telegraf: system dashboard，地址。请你根据它的提示配置你的telegraf。然后在dashboards中选择import->Upload.jsonFile，将下载的模板导入：

查看结果：

Grafana的功能非常丰富，在这里不能详细叙述，请您参考官档了解更多：http://docs.grafana.org/

七、InfluxDB硬件规模指南

单节点还是集群？ InfluxDB单节点实例是完全开源的。InfluxDB集群需要我们的闭源商业产品。单节点实例不提供冗余。如果服务器不可用，则写入和查询将立即失败。

群集提供高可用性和冗余。多个数据副本分布在多个服务器上，任何一个服务器的丢失都不会对集群产生重大影响。如果您的性能要求属于中等或低负载范围，

那么您可能会使用InfluxDB的单个节点实例。如果您的性能要求中至少有一个属于可能不可行的类别，那么您可能需要使用群集在多个服务器之间分配负载。

1、单节点

注：查询对系统的影响差异很大。

简单查询：

几乎没有函数也没有正则表达式

是时间限制在几分钟，几小时或一天

通常在几毫秒到几十毫秒内执行

中等查询：

有多个函数和一个或两个正则表达式

也可能有复杂的GROUP BY条款或抽样多个星期的时间范围

通常在几百或几千毫秒内执行

复杂查询：

具有多个聚合或转换函数或多个正则表达式

可以抽样几个月或几年的非常大的时间范围

通常需要多秒才能执行

低负荷建议：

CPU：2-4核心

RAM：2-4 GB

IOPS：500

适度的负载建议：

CPU：4-6核

RAM：8-32 GB

IOPS：500-1000

高负荷建议：

CPU：8+核心

RAM：32+ GB

IOPS：1000+

2、集群

元节点

群集必须至少具有三个独立的元节点才能在丢失服务器后继续存在。具有2n + 1元节点的集群可以容忍元节点的丢失n。群集应该具有奇数个元节点。没有理由拥有偶数个元节点，并且它可能导致某些配置出现问题。

元节点不需要很大的计算能力。无论群集负载如何，我们建议对元节点使用以下内容：

普遍推荐

CPU：1-2核心

RAM：512 MB - 1 GB

IOPS：50

数据节点

只有一个数据节点的集群有效，但没有数据冗余。冗余由写入数据的保留策略上的复制因子设置。群集可能会丢失 n - 1数据节点并仍然返回完整的查询结果，其中n是复制因子。

为了在群集内进行最佳数据分发，InfluxData建议使用偶数个数据节点。群集数据节点的硬件建议类似于独立实例建议。数据节点应始终至少有2个CPU内核，因为它们必须处理常规的读写流量以及集群内读写流量。

由于群集通信开销，群集中的数据节点处理的吞吐量低于同一硬件上的独立实例。

注：查询对系统的影响差异很大。

简单查询：

几乎没有函数也没有正则表达式

是时间限制在几分钟，几小时或一天

通常在几毫秒到几十毫秒内执行

中等查询：

有多个函数和一个或两个正则表达式

也可能有复杂的GROUP BY条款或抽样多个星期的时间范围

通常在几百或几千毫秒内执行

复杂查询：

具有多个聚合或转换函数或多个正则表达式

可以抽样几个月或几年的非常大的时间范围

通常需要多秒才能执行

低负荷建议

CPU：2个核心

RAM：2-4 GB

IOPS：1000

适度的负载建议

CPU：4-6

内存：8-32GB

IOPS：1000+

高负荷建议

CPU：8+

RAM：32+ GB

IOPS：1000+

企业Web节点

Enterprise Web服务器主要是具有类似负载要求的HTTP服务器。对于大多数应用程序，它不需要非常强大。群集只能使用一个Web服务器，但为了实现冗余，可以将多个Web服务器连接到单个后端Postgres数据库。

注：生产集群不应使用SQLite数据库，因为它不允许冗余Web服务器，也不能像Postgres一样优雅地处理高负载。

普遍推荐

CPU：1-4核心

RAM：1-2 GB

IOPS：50

八、InfluxDB单机性能测试

官方给出的硬件参考配置是：

两块SSD。一块存储influxdb/wal，一块存储influxdb/data 最少8G内存

虚拟机InfluxDB性能测试，这里记录下结果，方便以后查阅。

操作系统： CentOS Linux release 7.5.1804

InfluxDB版本： V1.7.4

CPU ： Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz，4个4核CPU

内存：16G

硬盘：机械硬盘

批量写入官方指导：

可以使用对写端点的单个HTTP请求将一批点提交到数据库。这通过大幅减少HTTP开销，使HTTP API的写入更加高效。

InfluxData建议批量大小为5,000-10,000点，但不同的用例可以通过明显更小或更大的批次来提供更好的服务。

优化前的结果（写入）：单线程写入数据超过1200W左右写入失败，内存不够用

多次优化后的结果（写入）：

全表扫描性能

条件查询性能

时间维度查询

聚合查询性能

同一个measurement，批量写入大量数据，然后多线程读取，随着数据量的增大，读取速度放慢。

如果是不同的measurement，读写分别不同的measurement，则读和写之间不受相互影响。

服务器应具有内存配置限制，以最大程度地降低内部进程触发OOM的风险。

目前的行为：

系统中有几个地方可以进行大量分配，这可能是发生OOM的风险存在。

一般来说，这些都发生在：

查询 - 通常使用过宽的过滤条件导致一次加载太多系列，比如select * 操作（确认存在）

内存索引 - 高基数（series）系列导致索引增长和OOM进程（确认存在）

写入 - 许多正在进行的大批量和慢速磁盘写入会导致在等待磁盘写入/同步时构建大量内部缓冲区。（确认存在）

压缩 - 在某些情况下，可以加载大型系列，以便更优化地对点进行重复数据删除和分块。（尚未发现）