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.自带管理界面，方便使用
官网文档：docs.influxdata.com/influxdb/v1…
二、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
下载地址 ：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的功能非常丰富，在这里不能详细叙述，请您参考官档了解更多：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进程（确认存在）
写入 - 许多正在进行的大批量和慢速磁盘写入会导致在等待磁盘写入/同步时构建大量内部缓冲区。（确认存在）
压缩 - 在某些情况下，可以加载大型系列，以便更优化地对点进行重复数据删除和分块。（尚未发现）
