安装与设计
版本选择、软件包/Docker 安装、存储(本地/对象)设计、结构与基数设计。
InfluxDB
InfluxDB 专为随时间累积的数据而设计,如服务器、设备、IoT 与应用指标。我们从版本选择(2.x / 3 Core / 3 Enterprise)到 Telegraf 采集、保留与降采样、备份及 Grafana 可视化进行整体设计。
Pipeline
典型的 TIG(Telegraf · InfluxDB · Grafana)管道。
Telegraf 代理采集服务器、数据库、网络与设备指标并写入 InfluxDB,Grafana 提供仪表盘与告警。需要长期保存的数据经降采样后存入单独的 bucket 或数据库,以降低存储成本与查询时间。
Versions
名字相同,但 2.x 与 3.x 在存储引擎、查询语言与运维方式上差异很大。
| 项目 | InfluxDB 2.x OSS | InfluxDB 3 Core | InfluxDB 3 Enterprise |
|---|---|---|---|
| 许可 | 开源 | 开源 | 商业 |
| 查询 | Flux、InfluxQL | SQL、InfluxQL | SQL、InfluxQL |
| 默认端口 · CLI | 8086 · influx | 8181 · influxdb3 | 8181 · influxdb3 |
| 数据单元 | Organization / Bucket | Database / Table | Database / Table |
| 保留期 | 按 bucket,可修改 | 创建数据库时指定,之后不可修改 | 可修改,支持按表保留 |
| 备份 | influx backup / restore | 无内置命令 —— 按规定顺序复制对象存储文件 | 基于对象存储 |
| 高可用 | 单节点 | 单节点 | 高可用、只读副本等集群功能 |
influxdb:latest 标签已改为指向 3 Core,使用 2.x 的环境请明确指定版本标签。版本与功能变化频繁,导入时会重新核对官方文档。Scope
版本选择、软件包/Docker 安装、存储(本地/对象)设计、结构与基数设计。
输入插件配置,outputs.influxdb_v2 / outputs.influxdb_v3 输出,缓冲与批量调优。
原始与聚合保留策略,基于 2.x Task(Flux)或 3.x 处理引擎插件的聚合。
2.x CLI 备份,3.x 对象存储复制流程(停止服务后逆序恢复)的制定与测试。
3 Enterprise 集群配置,或为 OSS 环境设计双写/复制替代方案。
写入批量与压缩、查询时间范围与 tag 过滤、内存/缓存设置、解决高基数。
数据源配置(3.x 推荐 SQL)、仪表盘与告警规则、运维指标面板。
1.x/2.x → 3.x 迁移规划、查询(Flux → SQL/InfluxQL)转换、并行运行。
Examples
# 保留期只能在创建时指定(Core)
influxdb3 create database --retention-period 30d \
--token "$INFLUXDB3_AUTH_TOKEN" sensors
# 不设保留(永久)
influxdb3 create database --token "$INFLUXDB3_AUTH_TOKEN" sensors_raw# Telegraf 1.38+:InfluxDB 3 专用输出插件
[[outputs.influxdb_v3]]
urls = ["https://influx.example.internal:8181"]
token = "${INFLUX_TOKEN}"
database = "sensors"
[[inputs.cpu]]
percpu = false
totalcpu = trueFAQ
希望用 SQL 分析与对象存储时选 3.x;希望保留现有 Flux 资产与成熟的 2.x 运维方式时 2.x 更现实。我们会结合是否需要修改保留期、高可用需求(是否用 Enterprise)与现有仪表盘一起决定。
截至 2026 年 10 月,3 Core 没有内置备份命令,需按官方文档的顺序复制对象存储(或本地存储路径)中的文件进行备份;恢复时在停止服务的状态下逆序进行。
在 Grafana 的 InfluxDB 数据源中选择 SQL(或 InfluxQL)查询语言即可。3.x 不使用 Flux。
指 tag 值组合(序列)数量过多。把用户 ID、请求 ID 等无限增长的值作为 tag,会造成性能与内存问题,因此需要调整结构,例如改为 field。
告诉我们您使用的云、数据库版本、架构与困扰,我们将提出评估范围与实施方式。