1. 为什么是时序库InfluxDB解决的问题和适用边界1.1 在选型前先搞清楚时序数据与普通数据的区别接触InfluxDB之前我最常被问的问题其实是“我可以用MySQL存监控数据吗”。答案是可以但会很别扭。普通数据库在设计时面向的是“当前状态”比如用户表、订单表一条记录就是一个实体。而时序数据面向的是“状态随时间的演变”比如每台服务器每隔5秒采集一次的CPU使用率、物联网设备上报的温度、App埋点的请求耗时。这类数据的特征非常鲜明写入量大、持续产生、按时间排序、几乎不做更新、删除通常是批量过期。InfluxDB就是为了这个场景设计的。它处理的是“按时间序列组织的高吞吐写入与聚合查询”典型的应用包括监控告警、IoT设备数据采集、性能分析、实时报表等。早期版本也就是0.x到1.x系列最实用的地方在于部署非常简单单机解压就能跑不需要单独依赖外部存储或组件。我这篇文章里涉及的命令都是基于1.x版本的实际操作积累2.x开始自带Web界面和bucket概念但底层influx命令行工具的操作思路仍然相通很多命令还能直接使用。1.2 核心数据模型measurement、tag、field、timeInfluxDB的命令和SQL非常像但如果带着MySQL的思维去用第一周大概率在踩坑。它跟传统关系库一个最大的区别就是数据模型由四部分组成measurement类似表名、tag索引字段、field实际存储数值的字段、time时间戳。tag和field的区别是需要底层理解的。tag是“有索引的、字符串为主”的元数据适合放那些取值集合较小的维度比如host、region、device_id。因为tag会被自动建索引作为WHERE条件过滤时查询速度非常快。field是真正存数值的字段比如cpu_usage、temperature、request_countfield是没有索引的在WHERE里直接过滤field会触发布全表扫描数据量大了会明显变慢。time则是必须存在的字段InfluxDB的每条记录都要带时间戳没有带就自动使用服务器当前时间。这个模型用一句话理解InfluxDB存储的是某个时间点、某个标签组合下、一组数值字段的取值快照。这也是为什么写数据时 CSV 导入、批量写入等场景很方便的原因。除了模型还有一个日常操作中绝对绕不开的概念保留策略Retention Policy简称RP。这是InfluxDB相对传统数据库的典型增强——每条数据写入时都会关联一个RPRP决定了数据的保留时长和副本数。默认会有一个叫autogen的RP保留时间无限大shard group的时长是7天。后续我会重点讲这块的常用命令因为大部分人建完库不配置RP等磁盘爆了才回头看往往已经晚了。2. 库、表、写入三板斧最常用的一批管理命令2.1 创建、查看、切换数据库进入influx命令行客户端的方式是直接在终端输入influx。默认连接本机的8086端口如果服务在远程可以带host和port参数比如influx -host 192.168.1.10 -port 8086。进去之后第一件事就是看有哪些数据库SHOW DATABASES这个命令的作用等同于MySQL的SHOW DATABASES。创建数据库CREATE DATABASE mydb在1.x版本里CREATE DATABASE mydb创建完之后不会自动切换过去还需要执行USE mydbUSE之后下面的所有查询和写入都默认针对这个库。这里想额外提醒一个细节1.x版本里CREATE DATABASE支持带策略参数比如CREATE DATABASE mydb WITH DURATION 30d REPLICATION 1 NAME myrp这条命令在创建库的同时创建了一个保留30天、副本数为1、名字叫myrp的保留策略。如果你在建库之前就已经明确了自己要保留多久最好在建库语句里一并写掉省得后面再改。2.x版本则改成了bucket概念但命令行里influx仍然可用核心逻辑类似。查看某个库下的所有measurementSHOW MEASUREMENTS如果只想看匹配某些前缀的measurement可以直接加过滤条件。比如设备监控数据中不同的设备类型建了不同前缀的表SHOW MEASUREMENTS WITH MEASUREMENT ~/cpu.*/这里用到了正则匹配是InfluxDB命令里一个比较实用的小技巧。2.2 建表与数据写入没有建表语句这件事按传统SQL的思路建表应该有个CREATE TABLE。但在InfluxDB 1.x里不需要显式建表。当你第一次往某个measurement写入数据时这个表会被自动创建。这就是InfluxDB所谓的“无模式设计”。写入数据用INSERT语句最基础的格式是INSERT cpu,hostserver01,regioncn usage72.5,idle27.5 1587312345000000000拆解一下这条语句的结构cpu是measurement名称hostserver01,regioncn是tag多个tag用逗号分隔usage72.5,idle27.5是field多个field也用逗号分隔最后那串很长的数字是时间戳。这里的1587312345000000000是纳秒级时间戳InfluxDB默认的精度就是纳秒。如果不想自己算纳秒也可以在插入时不写时间戳让InfluxDB自动取服务器当前时间比如INSERT cpu,hostserver01 usage72.5字段类型方面有个需要特别注意的点同一个field在不同时间点写入的值类型必须一致。比如第一次写的是浮点数72.5后面再写整数90InfluxDB不会自动做类型兼容会直接报错写不进去。这一条在自动化采集脚本里特别容易踩中尤其是用不同语言写采集端的时候类型定义不统一就会导致部分数据丢失。2.3 批量写入与常见报错生产环境的数据不会一条一条insert进去永远是批量写入效率高。在命令行里可以一次多行写入每一行一条数据INSERT cpu,hostserver01 usage72.5 INSERT cpu,hostserver02 usage68.3 INSERT cpu,hostserver03 usage80.1在InfluxDB的HTTP API里批量写入用的是行协议Line Protocol本质就是上面这样的文本行多个行放在请求体里一起POST。这个格式建议命令行操作的人也必须了解因为排查问题的时候很多报错信息都是在解析行协议时暴露出来的。常见的报错信息有这几类unable to parse行协议写错了可能是字段和类型不对也可能是少了等号。field type conflict同一个field存在两种不同的类型这种是数据写入时类型不一致导致的。points beyond retention policy写入的时间戳早于RP过期时间数据被丢弃。遇到最后一条要特别小心它的意思是数据保留周期已经过了这个数据点根本不会被保存下来。这种情况不是单纯报错而是数据悄悄被吞掉了查数据时发现缺一块最容易被忽略。3. 查询命令的实用组合从基础select到高级聚合3.1 基础查询select、where、order by、limit查询是用InfluxDB时最耗精力的部分因为命令表面上像SQL实际执行逻辑完全不同。一个最基础的查询SELECT * FROM cpu这条命令会把cpu表里的所有数据列出来注意输出结构第一列是time然后依次是field字段最后是tag字段。在输出结果里tag会被单独列出来这一点和MySQL直接输出整行记录的观感不同。如果只想取某些字段SELECT usage, idle FROM cpuWHERE条件过滤时最基本的是按时间过滤SELECT * FROM cpu WHERE time now() - 1h这段命令表示取最近1小时的数据。now() - 1h是InfluxDB里非常常用的相对时间表达式类似的还有now() - 30m、now() - 7d。如果要取绝对时间范围可以写time 2020-04-19T00:00:00Z AND time 2020-04-19T23:59:59Z注意字符串格式必须是RFC3339标准时间格式。按tag过滤则是这样的SELECT * FROM cpu WHERE host server01这里有个实用技巧如果同时对tag和field做过滤在1.x版本中最好先按tag过滤再叠加field条件因为tag走索引能大幅减少需要扫描的数据量。例如SELECT * FROM cpu WHERE host server01 AND usage 90要限制返回数量就加LIMITSELECT * FROM cpu LIMIT 10注意这个LIMIT限制的是返回的记录条数不是扫描的行数。3.2 聚合查询GROUP BY time窗口的妙用时序数据库最重要的玩法就是时间窗口聚合用GROUP BY time来按固定时间窗口统计比如每5分钟的平均CPU使用率SELECT mean(usage) FROM cpu WHERE time now() - 1h GROUP BY time(5m)这条命令会把过去1小时的数据切分成以5分钟为粒度的窗口每个窗口算一个平均值输出。输出的每一行代表了5分钟窗口内的聚合结果。如果想在同一个查询里同时拿到均值、最大值、最小值、总和SELECT mean(usage), max(usage), min(usage), sum(usage) FROM cpu GROUP BY time(10m)时间窗口聚合时有个容易被忽略的参数是fill。默认情况下某个窗口内没有数据结果里就不会有这一行这在绘图时会导致曲线断裂。加fill(0)可以把空窗口填成0SELECT mean(usage) FROM cpu WHERE time now() - 1h GROUP BY time(5m) fill(0)如果不想填0想用上一个窗口的值顺延填充用fill(linear)或者fill(previous)。按我的经验做监控图表时fill(previous)最贴近实际需求因为没有数据说明大概率是设备断连用上一个值补上比直接填0更符合设备状态。3.3 按tag分组、正则匹配与子查询GROUP BY除了按时间窗口分组还经常按tag分组。比如想同时看多台机器的CPU使用趋势SELECT mean(usage) FROM cpu WHERE time now() - 1h GROUP BY host如果要按时间窗口tag双重分组SELECT mean(usage) FROM cpu WHERE time now() - 1h GROUP BY time(5m), host正则表达式在查询里很好用。比如只查主机名以web开头的SELECT * FROM cpu WHERE host ~/^web.*/注意是~不是LIKE这个符号才是正则匹配。否定匹配用!~。子查询是解决“聚合结果再做聚合”这个场景的利器。举个例子每台机器每5分钟的CPU平均使用率算出来后想再算所有机器的整体平均那就必须先按机器和时间分组再对结果求平均SELECT mean(mean_usage) FROM (SELECT mean(usage) AS mean_usage FROM cpu WHERE time now() - 1h GROUP BY time(5m), host)这里的内层查询给均值起了个别名mean_usage外层再对别名做聚合。子查询在内层查询嵌套时时间范围和分组的写法都容易乱建议先单独跑内层确认输出再包外层。3.4 时间相关函数和辅助操作日常排查经常会用到几个时间函数。比如把纳秒时间戳转成可读格式用now()配合加减SELECT * FROM cpu WHERE time now() - 15m如果想看时间转换后的可读形态可以在SELECT里用time配合格式化函数比如time列默认显示的就是RFC3339格式。还有几个不常用的函数实际排查时偶尔能救命例如DERIVATIVE()可以算变化率看CPU使用率的趋势变化是不是在持续上升。比如每5分钟采集一次的使用率差值变化SELECT derivative(mean(usage), 1m) FROM cpu WHERE time now() - 1h GROUP BY time(5m)最后提一下INTO子句这个功能可以把查询结果写回另一个measurement被称作“降采样”。在做历史数据归档时非常常用后面讲到连续查询时会再派上用场SELECT mean(usage) AS mean_usage INTO cpu_1h FROM cpu GROUP BY time(1h)这条命令把cpu表中1小时粒度的平均使用率写进了一个新的表cpu_1h。注意连续查询CQ本质上就是定时自动执行这样的INTO查询。4. 保留策略与连续查询让数据自动“瘦身”4.1 保留策略的核心机制和操作命令If you仅把InfluxDB当普通数据库用可能很久都不会碰保留策略但对于监控系统这属于必须配置的项。保留策略的作用是自动删除超过指定时间的数据。例如磁盘空间有限监控数据保留30天就够了这时候写一个30天的RP数据在超过30天后自动被后台清理。查看当前数据库的保留策略SHOW RETENTION POLICIES ON mydb输出一般包含name、duration、shardGroupDuration、replicaN、default这几列。默认那条通常是autogenduration是0表示永久保留。创建一条新的保留策略CREATE RETENTION POLICY rp_30d ON mydb DURATION 30d REPLICATION 1 DEFAULT这个语句创建了一个叫rp_30d的保留策略数据保留30天副本数为1单机部署副本数只能是1并且设为默认策略。需要注意如果省略了DEFAULT关键字新策略不会成为默认策略往这个库里写入数据时用的还是旧策略。修改保留策略的时长ALTER RETENTION POLICY rp_30d ON mydb DURATION 45d有时候线上临时觉得原来配置的30天不够想延长到45天用ALTER直接改就行对已有数据不会产生影响只会影响后续的过期删除判断。删除保留策略DROP RETENTION POLICY rp_30d ON mydb这里有个危险操作需要重点提醒删除一条RP会导致使用该RP的所有measurement数据全部不可访问而且这是一条瞬间完成、不能回滚的操作。在测试环境我试过几次确认只要RP被删除对应数据就好比被清空了一样重新创建同名RP也找不回之前的数据。所以执行DROP前务必确认。4.2 连续查询Continuous Query的创建与使用连续查询是InfluxDB里一个极其实用的自动化机制它的核心作用是“周期性地把原始数据做一次聚合计算然后把结果写入另一张表”。典型场景是原始数据保存30天用CQ每5分钟聚合一次写入cpu_1m表然后再用另一个CQ每1小时聚合cpu_1m的结果写入cpu_1h表最后把cpu_1h表保留一年。这样既能保留长时间的历史数据又不会占用太大的磁盘空间。创建一条连续查询的命令格式是CREATE CONTINUOUS QUERY cq_1h ON mydb BEGIN SELECT mean(usage) AS mean_usage INTO cpu_1h FROM cpu GROUP BY time(1h) END这个CQ的意思是在mydb库上每隔1小时自动执行一次查询把cpu表最近1小时的均值写入cpu_1h表。注意GROUP BY time(1h)里的时间窗口决定了CQ的执行周期和聚合粒度。查看已有的连续查询SHOW CONTINUOUS QUERIES删除连续查询DROP CONTINUOUS QUERY cq_1h ON mydb使用CQ时有几个细节想分享。首先CQ里写的查询必须包含INTO子句而且GROUP BY time(...)的时间窗口会被用作执行周期也就是说你写的窗口是5m系统大约每5分钟跑一次但不会严格准时会有执行偏移。其次CQ自动执行时会覆盖最近的某个时间段即使某次执行失败了下一轮执行也会把缺失时间段的窗口数据重新聚合不需要手动补跑这点在实际运维中省了不少事。CQ对老版本还有一个坑如果原始表数据量很大CQ的执行时间可能超过采集周期导致任务堆积。在1.x版本CQ的执行是由内部调度的没法像任务队列那样去配置并发上限。数据量大的时候可以检查SHOW CONTINUOUS QUERIES的输出看CQ的耗时和上一次执行的偏移情况来判断是否堆积。若发现堆积比较实用的方案是把时间窗口继续调大比如5m改成10m或者对原始数据先做一层更粗粒度的预聚合。4.3 RP和CQ的组合玩法保留策略和连续查询往往是配合使用的。最常见的组合方式CREATE DATABASE monitor WITH DURATION 30d REPLICATION 1 SHARD DURATION 1h NAME rp_raw CREATE CONTINUOUS QUERY cq_1h ON monitor BEGIN SELECT mean(usage) AS mean_usage INTO monitor.rp_30d.cpu_1h FROM monitor.rp_raw.cpu GROUP BY time(1h) END这里演示了跨保留策略写入数据。第一行创建monitor库指定默认策略是rp_raw30天。然后CQ读的还是默认策略里的cpu表但写入时指定写到monitor.rp_30d.cpu_1h表示写入到monitor库里、rp_30d策略下、名为cpu_1h的表中。跨RP写入数据时必须用“数据库名.保留策略名.表名”全限定写法否则容易写错策略导致数据过期时间不对。还有一个独立但常跟CQ混用的机制是capacity和shard。WHERE条件里经常用时间范围底层其实跟shard有直接关联。shard group的时间范围由RP决定默认情况下如果DURATION小于2天shard group时长为1小时如果DURATION在2天到6个月之间shard group时长1天更久则7天。但也可以在创建RP时通过SHARD DURATION手动指定如上面命令里的SHARD DURATION 1h这样能细化分片方便数据过期后的分片删除。不过这个参数在数据量不大时没必要动保持默认就好。5. 查状态、做运维系统监控与数据清理5.1 SHOW系列状态命令运维环境里少了不了一系列查看状态、表结构和统计信息的命令。我挑几个高频使用的说。查看当前InfluxDB用户列表SHOW USERS查看measurement对应的tag key和field key调试数据格式时非常常用SHOW TAG KEYS FROM cpu SHOW FIELD KEYS FROM cpu当你忘了表结构或者别人建的表字段命名不规范时这两条命令能帮你快速摸清数据有哪些字段、哪些字段是tag、类型是什么。这点在接手别人的监控系统时尤其救命我靠SHOW FIELD KEYS梳理过好几套混乱的采集逻辑。查看一个measurement的tag取值分布情况SHOW TAG VALUES FROM cpu WITH KEY host在排查“为什么查不到某台机器的数据”时先跑这个命令确认tag值是否写对。很多时候不是数据丢了而是host的取值和查询条件不一致比如多了个空格、大小写不同。查看全库的统计信息SHOW STATSSHOW STATS会输出一堆关于写入点数、查询耗时、HTTP请求数、内存使用等内部指标是排查性能问题的起点。还有一个SHOW DIAGNOSTICS命令可以看到版本和运行参数。5.2 删除数据的正确姿势InfluxDB没有MySQL里那种DELETE FROM WHERE的通用语法。在1.x版本里删除数据主要走以下方式清理过期数据靠保留策略自动处理这个已经在前面详述。手动删除某段时间范围内的数据用DELETE系列语法DELETE FROM cpu WHERE time 2020-04-19T00:00:00Z需要注意DELETE只能按时间范围删不能直接WHERE某个field值等于多少。想删除某个tag条件下面的数据可以借助tag过滤DELETE FROM cpu WHERE host server01 AND time 2020-04-19T00:00:00Z删除整个measurement的所有数据用DROP MEASUREMENTDROP MEASUREMENT cpu如果只是想清空数据库那就直接DROP DATABASE mydb以上三个操作都是不可逆的执行前最好先确认备份。数据备份可以用influxd backup恢复用influxd restore这两个命令属于运维工具的范畴但做任何可能误删数据的操作之前建议务必知道能回来。5.3 日常运维的几个常见坑第一个坑是时区问题。InfluxDB的时间戳存储的是UTC纳秒时间命令行查询时显示的时间也是UTC。如果你的服务器是东八区查询结果和你本地时间相差8小时是完全正常的。想用本地时间显示可以在influx命令行启动时加-precision rfc3339参数或者在查询时用tz(Asia/Shanghai)子句如SELECT * FROM cpu WHERE time now() - 1h tz(Asia/Shanghai)第二个坑是时间精度问题。通过HTTP API写数据时默认时间精度是纳秒。如果采集端脚本生成的是毫秒或秒级时间戳而没设置precision参数数据会被当作纳秒时间戳解析产生很大偏差。命令行里可以用-precision ms来指定写入精度。这个问题非常隐蔽尤其是数据看起来能写入、查询看起来有值但时间完全错位的时候第一反应就要联想到精度。第三个坑是场景问题InfluxDB的SHOW MEASUREMENTS不区分大小写。表名是区分大小写的但查询时不注意大小写会导致结果为空比如建表用的Cpu查询时写cpu则可能什么都查不到。大部分采集脚本的命名规范统一用小写就是为了避开这个问题。6. 用户权限管理多环境协作的基础最后聊聊用户和权限。单机开发时可以完全不用管这个但一旦多人共用一个InfluxDB实例比如几个项目共用一个开发环境或者在生产环境接入多个采集端用户管理就是必需的。InfluxDB的用户分为普通用户和管理员。管理员可以做一切操作普通用户只能操作被授权的数据库。创建用户CREATE USER dev_user WITH PASSWORD dev_password创建管理员用户CREATE USER admin_user WITH PASSWORD admin_password WITH ALL PRIVILEGES注意InfluxDB的密码存储在系统内部没有明文查看的途径忘记密码只能靠管理员重新设置。给某个用户授权某个库GRANT ALL ON mydb TO dev_user只授予读权限GRANT READ ON mydb TO dev_user撤销权限REVOKE ALL ON mydb FROM dev_user查看用户权限SHOW GRANTS FOR dev_user修改用户密码SET PASSWORD FOR dev_user new_password删除用户DROP USER dev_user如果部署时开启了认证默认是关闭那么连入influx需要账号密码。开启认证的方式是在配置文件里设置auth-enabled true修改后重启服务然后所有客户端命令都要带用户名密码参数否则会直接拒绝连接。用户权限这块有个容易忽略的点在1.x版本中CREATE DATABASE这类管理操作在关闭认证时任何人都能做所以即使是内网环境也建议开启认证否则任何一个拿到网络访问权限的人都能drop掉整个库。这个教训我在一个共享测试环境里遇到过不止一次一台机器上多个项目的采集数据因为某人误操作被清空重建的成本远比配置认证高。还有一个细节是对于HTTP API方式连接认证信息通过HTTP Basic Auth传递。在用Prometheus、Telegraf等采集器写入InfluxDB时配置里填的username和password就是走这个机制。写采集器配置文件时建议把密码放到环境变量或密钥管理里不要直接明文放在配置文件并提交到代码仓库。关于连续查询、保留策略、用户权限的组合管理我的习惯是在部署新项目时先把这些一次性规划好不建议上线后等出问题了再补。建库时把RP的时长、CQ的聚合粒度、用户授权范围都定好这样后续日常使用基本都在查数据和分析数据层面不会频繁去动结构。