InfluxDB-使用 InfluxDB 模板、定时任务、仪表盘、服务进程参数、迁移数据

使用 InfluxDB 模板

什么是InfluxDB 模板

InfluxDB 模板是一份 yaml 风格的配置文件。它包含了一套完整的仪表盘、Telegraf 配置和报警配置。InfluxDB 模板力图保证开箱即用，把 yaml 文件下载下来，往 InfluxDB 里一导，从数据采集一直到数据监控报警就全部为你创建好。

InfluxDB 官方在 github 上收录了一批模板。开发前可以在这里逛一逛，看有没有可以直接拿来用的。

https://github.com/influxdata/community-templates

示例：使用模板快速部署

在这节示例中，我们会使用社区模板快速创建一套 docker 的监控模板。要完成这个示例，你需要提前掌握 docker 的相关知识。

（1）找到 Docker 模板文档

访问上一节的 https://github.com/influxdata/community-templates 找到Docker 模板的目录，点进去。

可以看到，有一节的标题是 Quick install 里面有详细的配置说明。

（2）安装模板

使用 influx-cli 安装模板。

influx apply -f https://raw.githubusercontent.com/influxdata/community-templates/master/docker/docker.yml

命令执行后，会弹出下面的消息，询问你是否使用上面的资源。

这里所指的资源，涉及要在你的 InfluxDB 中创建什么名称的 Bucket，创建什么定时任务和报警任务，创建什么仪表盘等等。如果你是在一个正在生产、且存在相似业务的InfluxDB 上，那这个列表还是要好好看一看的，避免出现存储桶重名之类的现象。

确定没有问题之后，敲y 回车。

如果接下来展示的内容以Stack ID: xxxx 结尾，那说明安装成功！ 这里的 Stack（栈）概念，其实就是模板的实例。

（3）查看安装结果

现在，我们打开InfluxDB 的 Web UI，看一下我们模板的导入效果。下图是模板为我们创建的存储桶，名为 docker。

1）存储桶

有一个名为 docker 的存储桶：

2）telegraf 配置

一个名为 Docker Monitor 的 Telegraf 配置文件，这个配置文件可能需要根据你 Docker的配置进行一些修改

3）仪表盘

模板还帮我们创建了一个名为 Docker 仪表盘，只不过我们现在的 Bucket 里面还没有数据，所以这列的图表都还没有显示出来。

4）报警规则

模板还帮我们设置了 4 个报警规则，根据题目的描述，分别是

• 容器CPU 使用率持续 15 分钟超过 80%

• 容器硬盘使用率超过 80%

• 容器的内存使用率持续 15 分钟超过 80%

• 容器没有以 0 状态（正常结束）退出。

（4）运行 Telegraf 采集数据

现在我们要使用 Teleggraf 跑 docker 模板里的配置文件。但之前我们在~/bin 目录下写过一个 host_tel.sh 的启停脚本，那个文件会保证全局只有一个 telegraf。所以，为了避免混乱，我们现在要先把之前的 telegraf 停掉。

host_tel.sh stop

接下来，我们编写新的脚本。

还是在~/bin 目录下，创建docker_tel.sh 文件。键入以下内容：

#!/bin/bash
export INFLUX_TOKEN=h106QMEj47juNUco-6T-op1Tzz0IeMh5MhBIDT8vUdv1R3BVeAzMvWGq2DtmJIcyuPwvPmHTLbZLTbnKxz3UK
A==
export INFLUX_HOST=http://localhost:8086/
export INFLUX_ORG=atguigu
/opt/module/telegraf-1.23.4/usr/bin/telegraf --config http://localhost:8086/api/v2/telegrafs/09edf888eeeb6000

按照 docker 模板的要求，在运行 telegraf 之前，我们需要声明 INFLUX_TOKEN、INFLUX_HOST 和 INFLUX_ORG 三个变量。

然后，我们修改一下 docker_tel.sh 的执行权限。

 chmod 755 ./docker_tel.sh

最终，启动 docker_tel.sh：

./docker_tel.sh

（5）查看模板效果

首先，可以在DataExplorer 中查看 docker 存储桶中有没有数据。

如图所示，数据已经成功进入 InfluxDB。

接下来，我们可以看一下仪表盘的状态，如下图，仪表盘也是成功展示数据的。

（6）运行一个 docker 容器

使用下面的命令，运行一个 docker 的入门容器。

docker run -dp 80:80 docker/getting-started

如果你的主机上没有 docker/getting-started 镜像，那么 docker 回去 dockerhub 上拉取镜像，因为这个镜像在国外，速度可能会很慢，如果拉取失败，请自行百度替换源的方法。

另外，容器运行后，还需要一段时间让 telegraf 采集数据。

（7）再次查看仪表盘

如下图所示，我们的镜像和容器数都从 0 变成了 1。而且系统的内存使用率变高了。

（8）删除 stack（模板实例）

在 Web UI 上，点击左侧工具栏的按钮，再点击上方的 TEMPLATES。可以看到已安装的模板列表，每个末班列表的右边都有一个删除按钮，通过这种方式可以快捷删除。

删除后，stack 所涉的所有资源会全部消失。

你也可以通过 influx-cli 来删除：

influx stacks remove -o atguigu --stack-id=09ee20c80d692000

influx-cli 的功能很全，你也可以用它来给 stack 重命名，或者查看一个组织下的所有stack 等。

InfluxDB 模板的不足

（1）FLUX 兼容性

我们之前看到，很多 InfluxDB 模板里面都会内嵌 FLUX 语言脚本。但是不同的InfluxDB 里面编译进去的 FLUX 语言版本是不一样的。最重要的是，FLUX 语言目前还处在较快的变动期，标准库还未确定。尤其是后面版本的 FLUX 可能会废弃之前版本里的函数和API。这就导致 FLUX 语言向前兼容性不佳。

比如，InfluxDB 2.4 的 FLUX 版本是 0.179，Influx2.0 就是 0.131.0。4 次迭代就能让FLUX 相差 40 多个版本。最典型的比如 smaple-data 这个模板。在 InfluxDB 2.3 之后就不能用了。如果你加载这份模板，会提示配置文件的第 11 行有问题。

这其实就是因为这份模板中的，csv.from(url:xxx)已被废弃。

再加上官方维护的这套模板仓库、出于“年久失修”的状态，缺乏维护。所以、你可能还需要自己手动修改一下模板。

（2）生态不如 Grafana

Grafana 是一个专门做监控仪表盘的框架、支持设置监控任务而且支持以多种数据库作为数据源。社区活跃度高于 InfluxDB，所以 Grafana 框架下有更加丰富且好用的模板。Grafana 还支持将 InfluxDB 作为数据源，这样在框架选型上可以使用 InfluxDB+Grafana 的方案。这样，InfluxDB 就只负责读写，Grafana 负责数据展示和报警。

下图是 Grafana 社区提供的模板。可以看到过滤后，支持以 InfluxDB 作为数据源的仪表盘就有 1117 个。

反观 InfluxDB 收录的模板、活跃度和模板更新上都赶不上 granfana。

定时任务

什么是定时任务

InfluxDB 任务是一个定时执行的 FLUX 脚本，它先查询数据，然后以某种方式进行修改或聚合，然后将数据写回 InfluxDB 或执行其他操作。

示例：将数据转成 json 发给别的应用

（1）创建任务的途径

有很多方式可以帮你创建任务，比如 DataExplorer、Notebook、HTTP API 和 influx-cli。不过，此处我们为了还愿定时任务的本来面貌，我们会使用 influx-cli 去创建定时任务。

（2）本任务的需求

我们的定时任务要实现下面的需求。

1. 每 30s 调度一次

2. 查询最近 30s 的第一条数据

3. 将数据转为 json

4. 将 json 通过HTTP 发送 SimpleHttpPostServer。

SimpleHttpPostServer 是自己用 go 语言写的一个最简单的 HTTP POST 服务，它的功能就是接收一个 POST 请求，然后把请求体重的内容转为字符串打印出来。可以访问 github 地址 https://github.com/realdengziqi/simpleHttpPostServer ，

下载源码自行编译，或者在发行记录中下载我已编译好的 linux-x64 可执行程序。

（3）启动 simpleHttpPostServer

下载 simpleHttpPostServer 后，cd 到其所在目录，执行 simpleHttpPostServer 程序。运行后，终端会被阻塞。

（4）测试 simpleHttpPostServer 是否正常工作

我们可以使用 curl 来验证 simpleHttpPostServer 是否正常工作。使用下面的命令，向simpleHttpPostServer 发送一个 POST 请求。

 curl -POST http://localhost:8080/ -d '{"hello":"world"}'

之后，查看 simpleHttpPostServer 所占的终端，如果终端出现了一条新的数据，那么说明 simpleHttpPostServer 工作正常。

（5）在 DataExplorer 中编写 FLUX 脚本

我们首先在 DataExplorer 中把查询到转为json 的这段逻辑写好。

我们要查询的是 test_init 存储桶下的 go_goroutines 测量。这个测量反应的是我们当前InfluxDB 程序中的 goroutines（轻量级线程）数量。打开DataExplrer，编写如下代码：

import "json"
import "http"
from(bucket: "test_init")
     |> range(start:-30s)
     |> filter(fn: (r) => r["_measurement"] == "go_goroutines")
     |> first(column: "_value")
     |> map(
         fn: (r) => {
             status_code = http.post(url:"http://localhost:8080/", data:json.encode(v:r))
             return {r with status_code:status_code}
     }
 )

代码解释：

• from -> range -> filter，指定了数据源并取出了我们想要的序列，其中 range 的 start参数我们写死-30s。

• first 函数，Flux 查询 InfluxDB 返回的数据默认是按照时间从先到后排序的，first 函数配合前面的查询相当于只取了最近 30s 的第一条数据。

• map 函数，我们在 map 函数里完成数据的发送。这里需要注意，因为 map 函数要求必须返回 record，而且输出的 record 不能和输入的 record 一模一样。所以，结尾 return 的时候，我们使用了 with 语法，给 map 输出的 record 增加了一个字段。也就是我们发出 http 请求响应的状态码。在 map 中的匿名函数，我们使用了 http.post 向 http://localhost:8080/发送了一条 json 格式的数据。

（6）运行代码并观察效果

现在，我们点击 SUBMIT 按钮，执行这个 FLUX 查询脚本，观察 DataExplorer 返回的数据和 simpleHttpPostServer 的输出。

1）观察 DataExplorer

点击 SUBMIT 后，点一下 view Raw Data 按钮，我们关注 table 格式的数据。可以看到， 现在数据中多了 status_code 一列，而且它的值是 200。而且，因为 first( )函数的作用，这次查询，我们只产生了一行数据。

2）观察 SimpleHttpPostServer

可以看到，我们的httpServer 顺利收到了 JSON。

截至目前，说明我们的 FLUX 脚本可以实现需求，现在的问题就是如何将这份脚本设为定时任务。

（7）配置定时调度

现在，在我们的查询逻辑前面插入一行。

option task = { name: "example_task", every: 30s, offset:0m }

表示，我们做了一个设定，指定了一个名为 example_task 的任务。这个任务每隔 30 秒执行一次。offset 这里暂时设为 0m，后面我们会专门讲这里的 offset 有什么意义。

import "json"
import "http"

option task = { name: "example_task", every: 30s, offset:0m }

from(bucket: "test_init")
     |> range(start:-30s)
     |> filter(fn: (r) => r["_measurement"] == "go_goroutines")
     |> first(column: "_value")
     |> map(
         fn: (r) => {
             status_code = http.post(url:"http://localhost:8080/", data:json.encode(v:r))
             return {r with status_code:status_code}
     }
 )

（8）使用 influx-cli 创建任务

虽然我们在 DataExplorer 里写了一个 option，但是具体到 option 会不会生效，必须要看 FLUX 脚本再跟 InfluxDB 的那个 HTTP API 进行交互。所以这里点击 SUBMIT 按钮只会再执行一次查询，option task 并不会生效。这里，我们会先用 influx-cli 创建一遍任务。

先把 Flux 脚本复制出来， 在/opt/modules/examples 里创建一个文件， 就叫example_task.flux 吧。将之前写的脚本粘贴进去。

import "json"
import "http"
option task = { name: "example_task", every: 30s, offset:0m }
from(bucket: "test_init")
     |> range(start:-30s)
     |> filter(fn: (r) => r["_measurement"] == "go_goroutines")
     |> first(column: "_value")
     |> map(
         fn: (r) => {
             status_code = http.post(url:"http://localhost:8080/", data:json.encode(v:r))
             return {r with status_code:status_code}
     }
 )

使用下面的命令，创建 FLUX 任务。

./influx task create --org atguigu -f /opt/module/examples/example_task.flux

可以看到，我们的任务已经成功创建了。

（9）在 Web UI 上查看定时任务

点击左侧工具栏的按钮，查看任务列表。可以看到，任务已经成功创建。

点一下任务的名称，可以进去看任务执行详情。

详情页面上，可以看到任务的调度时间、开始时间、任务耗时等信息。在最上方点击EDIT TASK 按钮，可以看到当时的任务定义。在这里，你也可以直接修改任务的定义。

（10）在接收端查看定时任务效果

数据的接收端就是 simpleHttpPostServer。可以看到，我们的接收端目前就是每隔 30s收到一条 json 数据。

（11）使用 DataExplorer 创建任务

这一次，我们用DataExplorer 来创建任务。现在，我们先将已经存在的任务删除。

打开 DataExplorer，编辑 FLUX 脚本，将我们之前写的查询脚本粘进去。注意，要删除 option 一行。如下图所示：

完成上面的操作后，点击 DataExplorer 页面右上方的 SAVE AS 按钮，在弹出的对话框中选择 TASK 选项卡。

• Name，填写为 example_task

• Every，填写 30s

• Offset 可以空着，这样默认就是 0。此处显示的 20m 是前端渲染效果，和具体的任务执行无关。

• 此处的 OutputBucket 的填写需要注意，本来我们自己编写的脚本并没有指定要把数据回写到 InfluxDB，但是如果从 Web UI 创建定时任务的话，Output Bucket 不能不设，这样会造成回写操作。这也是为什么我们之前不用 Web UI 创建任务的原因。

配置好后，点击SAVE AS TASK。

（12）再次查看任务详情（注意 Web UI 的小动作）

现在，我们再次回到任务列表。可以看到，任务已经成功创建，并且已经正常运行。

点击 EDIT TASK 按钮，查看我们的 FLUX 脚本。你会惊奇的发现，我们的 FLUX 代码居然被修改了，原本不回写数据库的操作被强制加上了一个 to 函数。另外，可以看到我们代码的前面也被加上了一个 option task 代码，这说明 Web UI 的页面点按操作只不过是帮我们完成了手敲代码的几个步骤。

总的来说，看开发者能否接收代码被隐式修改。如果这种行为无法接受，那么强烈建议用 influx-cli 的方式去创建任务。

数据迟到问题

option 中的 offset 是专门用来帮我们处理迟到问题的。

首先，我们来关注一个迟到的场景，如下图所示。我们的定时任务每次查询最近 30 秒的数据。同时，调度的间隔设为每 30 秒执行一次。

这个时候，由于网络的延迟，本该 1 分 20 秒入库的数据，1 分 32 秒的时候才来。但在1 分 30 秒的时候，我们的查询已经执行完了。这个时候我们错过了 1 分 20 秒的数据。这个时候，如果我们将 offset 设为 5 秒。如下图所示：

定时任务的执行时间向后延迟了 5 秒，但是查询的还是原来范围的数据。这个时候定时任务执行的时间是 1 分 35 秒。原先的迟到数据就能被我们查询到了。

cron 表达式

其实 InfluxDB 的定时任务还支持 cron 表达式。option 的写法如下：

option task = {
     // ...
     cron: "0 * * * *",
}

crontab 是 linux 上一个可以设置定时执行命令的工具。cron 表达式就是最早在就是在crontab 中使用的一种表示时间间隔的表达式。相关资料可以参考菜鸟教程开源的 cron 教程。

https://www.runoob.com/linux/linux-comm-crontab.html

如果是对 cron 非常熟练，一口气能直接写对那当然是很好的。如果开发时一次写不准可以百度一些在线的 cron 生成工具作为辅助。

不过 ，这里我更推荐gitee上的开源cron生成器项目。比如：https://gitee.com/toktok/easy-cron 这一个基于 node.js 的 corn 生成工具。你可以把代码拉下来自己部署，也可以使用它的在线 demo。http://www.easysb.cn/open/easy-cron/index.html

这个工具可以同时支持 5、6、7 字段的 cron 表达式。

补充：InfluxDB 抓取任务的本质

之前我们在 Web UI 里设置的抓取任务，其背后其实就是定时执行的 FLUX 脚本。只不过 InfluxDB 在API 上将他们分开了。

import "experimental/prometheus"
prometheus.scrape(url: "http://localhost:8086/metrics")

在当前的 FLUX 版本中，experimental/prometheus 库为我们提供了采集 prometheus 格式数据的能力 。 详细可以参考 https://docs.influxdata.com/flux/v0.x/prometheus/scrape-prometheus/

InfluxDB仪表盘

什么是InfluxDB 仪表盘

点击左侧的按钮，可以进入 InfluxDB 的仪表盘管理页面。可以看到仪表盘的管理页面，如下图所示：

我这里打开一个 System 仪表盘，注意，这个仪表盘中的内容依赖我们之前做的示例 2。

这是一个监控主机硬件与网络资源的仪表盘。仪表盘中的每个 Cell 其实都是一个FLUX 查询语句，通过执行 FLUX 获取数据结果，再使用 UI 将它展示为各类图表。在你打开仪表盘的一瞬间，InfluxDB 就会执行这些查询。

仪表盘控件

（1）手动刷新

右上方的刷新按钮，点击一次可以重新执行一轮仪表盘中的查询。因为通常的 FLUX脚本都是查询距当前一段时间的数据，所以刷新的功能还是比较必要的。

（2）开启自动刷新

右上方的ENABLE AUTO REFRESH按钮，可以开启仪表盘的自动刷新：

（3）切换显示时区

Local 按钮，可以选择将当前的日期时间显示为当前时区还是UTC。

（4）设定查询范围

指定查询过去多长一段时间的数据。

（5）添加一个 Cell

Cell 就是仪表盘中多个的图形的一个图形。添加图形对应的是左上角 ADD CELL 按钮。

（6）添加一个 Note

一个 Note 也是仪表盘中的一个模块，支持 Markdown 语法。对应左上角 ADD NOTE按钮。

（7）显示变量

如果仪表盘中包含涉及到变量的查询，那么在仪表盘的顶部会出现一个下拉菜单，通过下拉菜单这一指定变量的值，从而操作仪表盘展示响应数据。对应左上角的 Show Variables。

（8）开启注解

你可以按住 shift 和鼠标左键，在仪表盘的图示上添加参考线。打开个关闭注解会影响参考线的可见性。

（9）全屏和黑夜模式

此功能在左上角的… 按钮，如图所示：

示例：制作可交互的动态仪表盘

本示例要对 CPU 使用情况的相关指标制作仪表盘，这依赖于示例 2。请在完成示例 2的基础上完成改示例。

（1）需求

用户希望我们的仪表盘上能加入一个下拉菜单以选择查看哪个 CPU 的使用情况。要监控的指标是 useage_user，仪表盘上要显示每 1 分钟，CPU 使用率的最大值、最小值和中位数。

（2）创建变量

这里先不解释为什么创建变量。

鼠标悬停在左侧的按钮，在弹出栏上选择 Variables。如图所示：

点击右上角 CREATE VARIABLES 按钮，选择 New Variable，会弹出一个创建变量的对话框。在右上角的Type 为 Query 的前提下，在脚本编辑区键入以下内容:

import "influxdata/influxdb/schema"
schema.tagValues(bucket: "example02",tag:"cpu")

这个脚本可以查询出 example02 存储桶中的 cpu 标签有哪些标签值。左上角需要给变量指定一个名称，这里输入的是 CPU。

（3）创建新的仪表盘

回到仪表盘管理页面，点击 CREATE DASHBOARD 按钮，创建一个新的仪表盘。点击左上角的ADD CELL 按钮。

（4）创建新的 cell

可以看到，又出现了我们熟悉的 DataExplorer。进入后直接切换到 SCRIPT EDITOR。键入以下内容。

basedata = from(bucket: "example02")
 |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
 |> filter(fn: (r) => r["_measurement"] == "cpu")
 |> filter(fn: (r) => r["_field"] == "usage_user")
 |> filter(fn: (r) => r["cpu"] == v.CPU)
basedata
 |> aggregateWindow(every: 1m, fn: median, createEmpty: false)
 |> yield(name: "median")
basedata
 |> aggregateWindow(every: 1m, fn: max, createEmpty: false)
 |> yield(name: "max")
basedata
 |> aggregateWindow(every: 1m, fn: min, createEmpty: false)
 |> yield(name: "min")

点击 SUBMIT 查看效果。

（5）优化展示效果

默认的可视化类型为 Graph，我们现在将它切换为Band，表示带有边界的折线图。

切换图形后，点击CUSTOMIZE，进行自定义设置。

有一栏是 Aggregate Functions，在这里分别指定 Upper Column Name 为 max。Main Column Name 为 median，Lower Column Name 为 min。

这就是有边界的折线图的效果。最后，点击右上角的对号保存。

（6）查看效果

可以看到，在仪表盘的顶部出现了一个名为 CPU 的下拉菜单，通过这个下拉菜单，我们可以控制整个仪表盘，但前提是 cell 对应的 FLUX 查询语句引用了我们设置的变量v.CPU。

使用下拉菜单选择不同的CPU，可以显示对应的数据。

示例：更加灵活的变量与仪表盘

（1）需求

在上一个示例中，我们可以通名为 CPU 的变量对仪表盘中展示的序列进行动态的调整。

但是上一个示例中的仪表盘还有一个缺陷。如图所示，我们每次只能展示一个序列，但是如果我们想对比两个 CPU 的性能差别呢？这个时候上一个示例做出的仪表盘就不够用了。

现在，我们希望仪表盘中能够同时显示两个 CPU 到的工作状况，方便我们在视觉上进行对比。

（2）创建变量

在左侧的工具栏点击 Settings-\Variables 按钮。进入到变量的配置页面：

点击页面右上角的 CREATE VARIABLE 按钮。Web UI 上会弹出一个创建变量的对话窗。

在右上角的 Type 下拉菜单中选择 CSV。（上一个示例中我们创建的是 Query 类型，Query 类型的变量可以根据数据的状况进行动态的变化。但是另外的 Map 类型和 CSV 类型不行，它们是静态的，如果想让其中的值发生改变，除非再次通过 API 或者 Web UI 对其值进行手动的调整）

在左上角给变量起好名字，在演示中，我们将变量名设为 cpuxxx。

中间的主要区域是用来设置变量的值的，这里可以使用 CSV 格式，但却没有必要非要按照行列的方式来组织这些值。这里的 CSV 格式其实只是要求你用,（英文逗号） 来分隔值。其实这个地方也能用换行的方式来分隔值，如图所示，我们用的是换行分隔的方式。

此处，我们将值设为 cpu0、cpu1、cpu2、cpu3 和 cpu1|cpu2。注意！此处的 cpu1|cpu2是正则表达式写法，表示 cpu1 或者 cpu2。

在右下角有一个 Select A Default 下拉菜单，它可以给我们的变量设置一个默认值。此处可以将默认值设为cpu0。至此，我们的 cpuxxx 就创建好了。

（3）修改 FLUX 脚本（添加正则过滤）

首先，如图所示，先点击齿轮按钮，再在弹出的菜单中点击 Configure 按钮，就可以修改当前的Cell 了。

现在，我们需要对上一个示例中的查询脚本作一些修改。在 filter 中去添加一个蒸锅cpuxxx 的取值进行正则过滤的方法。

下面是我们的最终脚本，此处我们就不展示数据的最大值和最小值了。

basedata = from(bucket: "example02")
 |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
 |> filter(fn: (r) => r["_measurement"] == "cpu")
 |> filter(fn: (r) => r["_field"] == "usage_user")
 |> filter(fn: (r) => regexp.matchRegexping(r:regexp.compile(v:v.cpuxxx),v:r["cpu"])

代码解释：

• regexp.compile(v:v.cpuxxx)：需要注意，我们在 InfluxDB 中设置的变量的类型始终都是字符串类型，所以要进行正则匹配的话必须先把字符串转成正则表达式。regexp 包下的 compile 函数就是专门用来将字符串转为正则表达式的。

• regexp.matchRegexpString：用来判断字符串能否与正则表达式匹配。如果可以匹配上，那么该函数就会返回 true，如果匹配不上，那么就会返回 false。

• 这样的话，当我们将变量 cpuxxx 的值置为 cpu1|cpu2 时，就可以同时展示出我们想要的两个序列了。

最终，点击右上角的√按钮保存修改后的 cell。

（4）查看最终效果

回到仪表盘后，可以看到，最上方的变量下拉菜单已经从 cpu 变成了 cpuxxx，这说明仪表盘会自动判断内部的 cell 用到了哪些变量并做出相应的调整。如下图所示，这就是修改后的效果。

此时，选择 cpu1|cpu2，就可以看到之前的cell 里面会出现两条序列了。

InfluxDB 服务进程参数（influxd 命令的用法）

influxd 命令罗列

我们的 InfluxDB 下载好后，解压目录下的 influxd 就是我们 InfluxDB 服务进程的启动命令。

详情可以参考：https://docs.influxdata.com/influxdb/v2.4/reference/cli/influx/

命令	直译	解释
downgrade	降级	将元数据格式降级以匹配旧的发行版
help	帮助	打印 influxd 命令的帮助信息
inspect	检查	检查磁盘上数据库的数据
print-config	打印配置	（此命令 2.4 已被废弃）打印完整的 influxd 在当前环境的配置信息
recovery	恢复	恢复对 InfluxDB 的操作权限，管理 token、组织和用户
run	运行	运行 influxd 服务（默认）
upgrade	升级	将 InfluxDB 从 1.x 升级到 InfluxDB2.4
version	版本	打印 InfluxDB 的当前版本

不一定必须通过 influxd 命令来查看 InfluxDB 的当前配置。你还可以使用 influx-cli 的命令：

influx server-config

inspect 命令

你可以使用下面的命令来查看 inspect 这个子命令的帮助信息。

./influxd inspect -h

你会发现 inspect 这个子命令下还有很多子命令。

这里出现的 tsi、tsm、wal 都跟 InfluxDB 底层的存储引擎相关。这里可以稍微点一下，你可以使用下面的命令查看 InfluxDB 中数据存储的大概情况。

./influd inspect report-tsm

执行结果如下图所示。

展示出来的信息中包含了 InfluxDB 的数据存储情况，比如当前整个 InfluxDB 有多少序列，每个存储桶中又有多少序列等等。

另外，还有一个比较重要的 export-tsm 命令，它可以将某个存储桶中的数据全部导出为 InfluxDB 行协议。后面我们会在一个示例中详细演示它的使用。

recovery 命令

可以先用下面的命令查看 recovery 这一子命令的帮助信息。

./influd recovery -h

如图所示，influxd recovery 命令的作用主要是用来修复或者重新生成对 InfluxDB 进行操作所需的operator（操作者） 权限的。

recovery 下面还有 3 个子命令，分别是 auth、org 和 user。它们分别与 token、组织和用户有关。

下面主要是讲解 auth 子命令的用法，使用下面的命令可以进一步查看 auth 子命令的帮助信息。

./influxd recovery auth -h

返回的结果如下图所示：

可以看到它有两个子命令。

• create-operator：为一个用户创建一个新的操作者 token。

• list：列出当前数据库中的全部 token。

使用下面的命令就可以为 tony 用户再次创建一个operator-token 了。

./influxd recovery auth create-operator --username tony --org atguigu

命令执行后，终端会显示如下图所示的内容，可以看到这里创建了一个名为 tony’s Recovery Token 的操作者 token。

influxd 常用配置项

influxd 的可用配置项超多，详细可以参考：https://docs.influxdata.com/influxdb/v2.4/reference/config-options/#assets-path

以下是一些常用的参数

• bolt-path：BoltDB 文件的路径。

• engine-path：InfluxDB 文件的路径

• sqlit-path：sqlite 的路径，InfluxDB 里面还用到了 sqllite，它里面会存放一些关于任务执行的元数据，

• flux-log-enabled：是否开启日志，默认是 false。

• log-level：日志级别，支持 debug、info、error 等。默认是 info。

如何对influxd 进行配置

有 3 种方式可以对 influxd 的配置。这里以 http-bind-address 进行操作，为大家演示。

（1）命令行参数

进行如下操作前，记得关闭当前正在运行的 influxd。你可以使用下面的命令来杀死当然的 influxd 进程。否则，原先的 influxd 进程会锁住 BoltDB 数据库，别的进程不能访问。当然你也可以修改BlotDB 路径，但是那样太过麻烦。

ps -ef | grep influxd | grep -v grep | awk '{print $2}' | xargs kill

用户 influxd 命令启动 InfluxDB 时，通过命令行参数来传递一个配置项。比如：

./influxd --http-bind-address=:8088

可以尝试访问 8088 端口，看服务有没有挂到端口上

（2）环境变量

同样，还是先杀死之前的 influxd 进程。运行下面的命令：

ps -ef | grep influxd | grep -v grep | awk '{print $2}' | xargs kill

用户可以声明一个环境变量，对 influxd 进行配置比如：

export INFLUXD_HTTP_BIND_ADDRESS=:8089

现在，我们启动一下 influxd 看下效果。

最后，因为我们用的是 export 命令，临时搞了一个环境变量，如果你觉得当前 shell 会话不重要，可以关闭当前 shell 会话。否则，你可以使用 unset 命令来销毁这个环境变量。

unset INFLUXD_HTTP_BIND_ADDRESS

（3）配置文件

你还 influxd 所在的目录下放一个 config 文件，它可以是 config.json，config.toml， config.yaml。这 3 种格式 influxd 都能识别，不过文件中的内容一定要合法。influxd 启动时会自动检测这个文件。

在 InfluxDB 的安装目录下创建一个config.json 文件。

vim /opt/module/influxdb2_linux_amd64/config.json

编辑如下内容：

{
    "http-bind-address": ":9090"
}

启动之前记得停掉之前的 InfluxDB 进程。

ps -ef | grep influxd | grep -v grep | awk '{print $2}' | xargs kill

现在再启动一下，看看效果。

./influxd

可以看到端口已经变成 9090。配置同样是生效的。

时序数据库是怎么存储用户名和密码的

InfluxDB 内部自带了一个用 Go 语言写的 BlotDB，BlotDB 是一个键值数据库，它的功能比较有限，基本上就是专注于存值、读值。同时，因为功能有限，它也可以做的很小很轻量。

InfluxDB 就是把用户名、密码、token 什么的信息存在这样的键值数据库里的。默认情况下，BlotDB 的数据会存储在一个单独的文件中，这个文件会在~/.influxdbv2/ 路径下，名称为 influxd.bolt。

这个文件的路径可以在 influxd 通过bolt-path 配置项来进行修改。

从 InfluxDB OSS 迁移数据

将 InfluxDB 中的数据导出

导出 InfluxDB 数据必须使用 influxd 命令（注意，不是 influx 命令）。在 InfluxDB2.x 中，数据导出是以存储桶为单位的。

下面是示例命令：

influxd inspect export-lp \
 --bucket-id 12ab34cd56ef \
 --engine-path ~/.influxdbv2/engine \
 --output-path path/to/export.lp
 --start 2022-01-01T00:00:00Z \
 --end 2022-01-31T23:59:59Z \
 --compress

参数讲解：

• influxd inspect，influxd 是可以操作 InfluxDB 服务进程的命令行工具，inspect 是influxd 命令的子命令，使用 inspect 可以

• export-lp，是 export xxx to line protocol 的缩写，表示将数据导出为行协议。它是inspect 的子命令。

• bucket-id，inspect 的必须参数。存储桶的 id

• engine-path，inspect 的必须参数，不过有默认值~/.influxdbv2/engine。所以如果你的数据目录是~/.influxdbv2/engine 那么不指定这个参数也行。

• output-path，inspect 的必须参数，指定输出文件的位置。

• start，非必须，导出数据的开始时间

• end，非必须，导出数据的结束时间。

• compress，建议启用，如果启用了，那么 influxd 会使用 gzip 的方式压缩输出的数据。

示例：将InfluxDB 中的数据导出

这次，我们尝试导出 test_init 的数据导出，截至目前，这个 bucket 里面的数据应该是当前最多的。

（1）首先，你可以使用 influx-cli 也可以使用 Web UI 来查看我们想要导出的 bucket 对应的 ID 。 这里， 可以选择使用 Web UI ， 可以看到 test_init 存储桶的 ID 为0a2e821ccd12854a。

（2）于是，我们运行下面的命令，尝试把数据导出。

./influxd inspect export-lp \ 
--bucket-id 0a2e821ccd12854a \ 
--output-path ./oh.lp

这条命令会把 test_init 存储桶里的数据以 InfluxDB 行协议的格式导出到当前目录下的oh.lp 文件中。

正常情况下，程序会输出一系列读写信息。

（3）使用下面的命令查看当前路径下的文件及其大小。

ls -lh

ls 的 h 参数，可以将文件的字节数打印为更容易阅读的 MB、GB 单位。

可以看到，我们导出的数据文件 oh.lp 有 1.5G 大小。

（4）现在，我们使用 tail 命令来查看一下文件的内容。

tail -15 ./oh.lp

命令输出的是文件的最后 15 行内容，可以看到里面全是 InfluxDB 行协议的数据。

不过，我们要注意到 InfluxDB 行协议的一个特点，其实对于整个文件来说，多条数据的 measurement 其实是重复的，tagset 的重复率也不低，filed 的变化也不会很大。这种高度重复的数据其实是非常适合压缩算法的。

示例：导出数据时压缩

（1）现在，我们重新运行数据导出的命令，这次在命令的最后加上–compress 参数。不必担心目录下已经存在oh.lp 文件，程序会直接将其覆盖的。

./influxd inspect export-lp \ 
--bucket-id 0a2e821ccd12854a \ 
--output-path ./oh.lp
--compress

（2）使用 ls 命令再次查看文件大小。

可以看到文件从之前的 1.5G 变成了现在的 91M，压缩率非常高。