Telegraf+InfluxDB+Grafana：十分钟搭建轻量服务器监控体系

现在服务器越来越成为个人开发和团队协作里的刚需，不管是部署应用、跑定时任务，还是折腾数据处理，一台常年开机的机器都是基础。但机器跑起来之后，最让人心里没底的就是它到底什么状态：CPU是不是快满了、内存还剩多少、磁盘会不会半夜被日志塞爆、流量有没有异常。这类问题光靠人肉盯是盯不过来的，我自己的做法是直接上一套完整的监控体系，主力就是TICK技术栈里的三个核心组件——Telegraf负责采集、InfluxDB负责存储、Grafana负责展示。这套组合俗称TIG，轻量、开源、部署快，十分钟就能跑起来看到数据，基本是一劳永逸的解决方案。

这套东西解决的核心痛点，就是把自己从“服务器挂了才后知后觉”变成“指标刚有异常趋势就能提前发现”。凡是手里有几台服务器、又不想折腾太重型的监控平台（比如完整TICK里的四个组件全上、或者用商业方案）的人，都可以直接用TIG这套组合。哪怕你之前没用过时序数据库，看完这篇文章照着敲也能把监控面板搭出来。下面我把这套方案的完整落地过程、选型逻辑和实操经验一次讲清楚。

1. 监控方案选型思路：为什么是Telegraf+InfluxDB+Grafana

先说清楚点，TICK严格说是四个组件：Telegraf采集、InfluxDB存储、Chronograf可视化、Kapacitor告警。但我个人在实际落地里，会跳过Chronograf，只用Telegraf+InfluxDB+Grafana，因为Grafana在仪表盘展示、多数据源整合、告警规则配置这三方面比Chronograf成熟太多。后者在TICK体系里更像个全家桶配好的一体化界面，但真要精细化做图表和告警，Grafana的生态和社区资源明显更占优。

这套组合各自的角色很明确：

• Telegraf：Go写的数据采集代理，轻量、插件化，系统CPU、内存、磁盘、网络、进程这些基础指标用内置插件就能采，还能通过自定义插件横向扩到业务层数据。
• InfluxDB：专门为时序数据设计的高性能数据库，秒级写入能力很强，数据按时间索引存储，非常适合监控指标这种追加写、按时间范围查的场景。
• Grafana：数据可视化看板，从InfluxDB里查询数据，渲染成折线图、仪表盘、柱状图，这一个字面意思就能解决的环节，实际折腾起来最花时间，因为图表布局和告警阈值都要调。

跟Prometheus+Node Exporter+Grafana这套对比的话，两者思路不太一样。Prometheus是拉模式，由服务端定期抓取目标暴露的指标接口；而TIG是推模式，Telegraf定期采集然后主动写入InfluxDB。推模式的好处是采集端只要配置一次目标就能往多个后端发数据，横向扩容也不依赖服务端来调度。对个人和小团队来说，这两种都能用，选TIG纯粹是我更习惯InfluxDB的查询语法，而且历史数据存储和保留策略配置上更顺手。

1.1 为什么选择时序数据库而不是传统关系库

监控数据的最大特征是“持续产生时间戳+数值”，而且写入频率高、单条数据小、基本不做随机更新。这跟我们平时用的MySQL、PostgreSQL的业务数据模型完全不一样。要是把几千台机器的CPU、内存这些指标每秒都往MySQL里写，连接数、索引膨胀、写入锁竞争都会很快把库拖垮。

InfluxDB这类时序库就是针对这种场景设计的。它用TSM存储引擎压缩数据、按时间分片、自动清理过期数据，同时提供了连续查询来实时做降采样。写入路径也做了优化，批量写入的吞吐非常可观，单机每秒可以扛几十万条写入。所以只要监控规模不是十几万台级别的量，单机InfluxDB稳稳够用。

1.2 部署形态和硬件要求

TIG这套东西最大的优点就是省资源。Telegraf只占几十MB内存，InfluxDB满配也就两三百MB级别，Grafana弹性的地方在于看板渲染的时候才吃CPU。我自己常用的部署方式就是：

• 监控对象机器上用docker跑一个Telegraf容器，或者直接二进制安装。
• InfluxDB和Grafana单独部署在一台管理机上，还是docker方式。
• 要求高可用就上InfluxDB的集群方案，但对个人和小团队来说单节点已经很稳。

如果你的机器内存只有1GB左右，也能很流畅地跑这套组合，只要别把历史数据保留时间太长，或者磁盘够大就行。上面这点经验，在实际部署规划的时候价值非常大，能直接决定你的机器要不要临时扩容。

2. 环境准备与基础组件部署

我习惯先在管理机上把InfluxDB和Grafana部署好，再去各台目标机器上看Telegraf，因为InfluxDB的地址和端口是Telegraf写入配置里必须用到的。用Docker来部署的话，整个过程非常顺，配置管理也干净。

2.1 部署InfluxDB 1.8版本

InfluxDB目前有两个大版本，1.x和2.x，二者在配置、鉴权、查询语法上有明显区别。TICK里的传统链路是围绕1.x设计的，而且Grafana对InfluxDB 1.x的InfluxQL查询支持非常成熟。所以我这里还是用1.8来演示，如果你们是新项目，建议直接1.8，稳定且顺手。

docker run -d \ --name influxdb \ --restart=always \ -p 8086:8086 \ -v influxdb-data:/var/lib/influxdb \ influxdb:1.8

数据卷挂载是必须做的，不然容器一删数据就全没了。进来之后进容器建库和用户：

docker exec -it influxdb influx CREATE DATABASE server_monitor; CREATE USER "telegraf" WITH PASSWORD 'your_strong_password'; GRANT ALL ON server_monitor TO telegraf;

这里的库名和用户后面连接数据库和Telegraf写入都会用到，建议在初始化的时候就想好统一的命名规则，免得后面机器多了配置混乱。

2.2 部署Grafana

Grafana部署更简单，一条命令就起来：

docker run -d \ --name grafana \ --restart=always \ -p 3000:3000 \ -v grafana-data:/var/lib/grafana \ grafana/grafana:latest

起来之后打开http://管理机IP:3000，默认账号密码是admin/admin，登录后第一步就改密码，这个千万别偷懒。Grafana的面板默认是英文的，如果不习惯可以在配置里切中文语言包，但对绝大多数技术场景英文界面也完全够用。

2.3 部署Telegraf

Telegraf我基本都是二进制直接装到被监控机器上，因为这样最省资源，采集进程不会番茄跟docker守护进程抢系统资源。下载地址在官方Downloads页面，把对应平台的压缩包解压到/opt/telegraf下，然后创建systemd服务：

tar xzf telegraf-1.*.tar.gz -C /opt/ ln -s /opt/telegraf-1.* /opt/telegraf /opt/telegraf/usr/bin/telegraf --version

然后写一个systemd unit文件，路径放/etc/systemd/system/telegraf.service：

[Unit] Description=Telegraf Collector After=network-online.target [Service] ExecStart=/opt/telegraf/usr/bin/telegraf --config /etc/telegraf/telegraf.conf Restart=always User=root [Install] WantedBy=multi-user.target

这里我用root用户跑Telegraf，原因是它要读一些系统类别的metrics比如进程CPU、磁盘IO等，用普通用户权限不够会导致部分指标采集失败。如果你对安全要求高，可以单独给Telegraf配置sudo权限，按需开放，但最简单可靠的还是root。

3. Telegraf采集配置深度解析

Telegraf功能是否正常，80%的功夫都花在配置项上。默认的telegraf.conf是全量示例，几百行，直接拿去用会采集很多用不上的数据，也容易造成库表字段混乱。正确做法是：用telegraf config生成一份基础配置，再手工裁剪成自己需要的。

生成配置命令：

telegraf config > telegraf.conf

3.1 核心配置架构

Telegraf的配置结构主要由全局设置、输入插件、输出插件三部分组成。全局设置里最重要的就是采集间隔：

[agent] interval = "10s" flush_interval = "10s" round_interval = true omit_hostname = false

• interval是每个输入插件轮询采集的间隔，10秒一次比较中庸，既不会因为太频繁增加系统开销，也不会因为间隔太长导致指标曲线难看。
• flush_interval是数据刷到输出端的间隔，默认与interval一致，意味着每个采集周期都会往InfluxDB写一批数据。
• 如果机器数量多，可以把interval调成15秒或30秒，降低库的写入压力，前提是告警场景能接受延迟。

3.2 输入插件逐个解读

系统基础监控最少要配CPU、内存、磁盘、网络、IO这几个插件：

[[inputs.cpu]] percpu = true totalcpu = true collect_flags = true fielddrop = ["usage_guest", "usage_guest_nice"]

percpu和totalcpu都开，能分别看到每个核的利用率和全局平均。fielddrop可以过滤掉一些基本用不上的细分字段，比如虚拟客户机的CPU占用，这样库里的字段更精简。

[[inputs.disk]] ignore_fs = ["tmpfs", "devtmpfs", "overlay", "aufs", "squashfs"]

这个设置很关键，不把tmpfs和overlay排除的话，容器环境里会看到一堆重复的挂载点，明明都是同一块盘，却统计出好几个分区，数据直接乱掉。

内存和网络没啥特别要说的，就是默认全量采集：

[[inputs.mem]] [[inputs.net]] [[inputs.netstat]] [[inputs.swap]]

磁盘IO插件diskio可以单独配置，指定设备名：

[[inputs.diskio]] devices = ["sda", "nvme0n1"]

明确设备名可以避免采到loop设备或虚拟设备，尤其是KVM虚拟化环境，不指定的话会采出一堆只有零值的虚拟块设备。

进程插件procstat是单独按进程名采集CPU和内存用的：

[[inputs.procstat]] pattern = "nginx"

• 这种按匹配模式采集的方式，适合守护进程是固定名字的场景。

还有一类插件在监控中也很常用，system和kernel：

[[inputs.system]] [[inputs.kernel]]

system插件会采集系统的load1、load5、load15、运行中的进程数、已经创建进程数等，这些对判断机器负载非常直观。kernel插件则提供上下文切换、进程创建等内核级指标，排查性能问题时非常有用。

3.3 输出插件与数据格式

输出到InfluxDB的配置是Telegraf的核心：

[[outputs.influxdb]] urls = ["http://管理机IP:8086"] database = "server_monitor" username = "telegraf" password = "your_strong_password" retention_policy = "" write_consistency = "any" timeout = "5s"

注意：retention_policy留空，InfluxDB默认的autogen策略就会接管处理。

如果机器有多个网络接口，给管理机的IP推荐用内网固定IP，尽量不要走公网，少一层延迟和数据暴露风险。

Telegraf的采集数据默认会带上时间的RFC3339格式、host标签、metric名等。InfluxDB的行协议格式为measurement,tagKey=tagValue fieldKey=fieldValue timestamp。Telegraf会把每个输入插件对应的数据组装成这种行格式，批量POST到InfluxDB的/write接口。我们通过这种方式写入的数据，在InfluxDB里会自动按时间排序存储，查询的时候按tag和field过滤。

3.4 配置验证与启动

写完配置后用配置校验命令，检查语法没有问题：

/opt/telegraf/usr/bin/telegraf --config /etc/telegraf/telegraf.conf --test

--test模式会把采集到的一次数据直接打印在控制台，不会写到数据库，非常适合调试阶段使用。看到类似cpu cpu=cpu-total,host=xxx usage_system=xx的时序数据输出后，说明采集链路已通。

然后启动服务：

systemctl daemon-reload systemctl enable telegraf systemctl start telegraf

启动后等一两个采集周期，看输出端是否正常写入。Telegraf自带自监控指标，如果你不想额外引入系统监控，这个自己也会被采集，可以用来确认agent的状态保持在线。

4. 打通InfluxDB数据链路与查询实践

Telegraf配置好、服务也跑起来之后，真正的核心工作来了：验证监控数据有没有正确进入InfluxDB、表结构长什么样、怎么查询出有用的指标。这一步做完，数据链路才算彻底打通，后面Grafana配起来才有数据可画。

4.1 数据写入验证

先看InfluxDB库里的measurement列表：

SHOW MEASUREMENTS ON server_monitor;

不出意外的话，你看到的列表大概包括：

• cpu
• disk
• diskio
• mem
• net
• netstat
• swap
• system
• kernel
• procstat

这些都是Telegraf每个输入插件对应创建的measurement，名称与插件名一一对应。每个measurement内字段可以再确认一下：

SHOW FIELD KEYS ON server_monitor FROM cpu;

如果能看到usage_user、usage_system、usage_idle这些字段，说明CPU数据已经在正确写入了。

4.2 元数据顶层设计

InfluxDB有两个核心概念：tag和field。tag会被索引，适合做过滤条件；field不会被索引，适合做数值运算和聚合。Telegraf默认给每条数据带上host标签，把不同机器的数据天然隔离了。

这套设计带来的好处你想一下：Grafana写查询的时候，只要把host变量传递进去，就可以一个看板看所有机器的CPU曲线，选择器下拉一下就能切机器。还有，不要再用机器IP或者内网IP给host命名，最好用有业务含义的名字，比如web-server-01、db-master-02，这样你在看板上一眼就看出是哪台机器。

4.3 InfluxQL常用查询样例

写监控面板查询，最常用的就是聚合函数加时间分组：

SELECT mean(usage_user) AS avg_user FROM cpu WHERE $timeFilter GROUP BY time(1m), host

这个查询的意思是：在Grafana选择的时间范围内，按1分钟聚合每个主机的用户态CPU平均使用率。GROUP BY里可以同时按时间维度聚合和host标签维度分组，这一下就能看到所有机器的对比趋势。

如果要查磁盘分区使用率：

SELECT last(used_percent) FROM disk WHERE $timeFilter GROUP BY time(1m), host, path

注意磁盘使用率一般用last而不是mean，因为磁盘使用率本身是缓慢变化的，mean会把时间窗内的波动磨平，让你看不清实际边界，last直接拿到窗口内最后采样值，更贴近实时状态。

4.4 保留策略与降采样

时序数据最大的烦恼就是随着时间越积越多，磁盘早晚爆掉。InfluxDB的保留策略(RP)就是干这个的，它能让数据自动过期删除。

我们的server_monitor库默认用autogen策略，保留时间永久、副本数1。如果你不想永久存，可以把它改短，比如保留30天：

CREATE RETENTION POLICY "rp_30d" ON server_monitor DURATION 30d REPLICATION 1 DEFAULT;

之后写入的观察数据默认都会存到rp_30d，超过30天的自动删除，磁盘压力大大降低。你甚至还可以做更细的层次，比如原始数据保留7天，然后用连续查询做1小时降采样后的数据保留1年，专门用于历史趋势分析。这属于进阶玩法，我们下面在优化章节单独展开。

5. Grafana仪表盘构建与告警配置

数据链路通了之后，整个系统最关键也最出效果的部分就是Grafana看板。这里贴一下我在实际使用中被反复打磨的经验，从新建数据源开始。

5.1 添加InfluxDB数据源

Grafana界面里依次打开Configuration → Data Sources → Add data source，选择InfluxDB：

• URL填http://管理机IP:8086
• Database填server_monitor
• User和Password填之前创建的用户和密码
• HTTP Method选POST，查询某些场景下GET会限制body长度
• Min time interval填1s，因为我们的采集间隔是10s，这个参数控制查询的最小时间步长

点Save & Test会提示数据源连通正常，这就说明Grafana成功连接上InfluxDB了。

5.2 制作第一个仪表盘：CPU监控

新建Dashboard，添加一个Panel，Query里选择刚配的InfluxDB数据源：

SELECT mean(usage_user) AS user, mean(usage_system) AS system, mean(usage_iowait) AS iowait, mean(usage_irq) AS irq FROM cpu WHERE $timeFilter GROUP BY time($__interval), host

这是最经典的CPU监控面展示方式，一张图上同时展示用户态、系统态、IOWait和硬中断，配合Legend上按host分组，每个机器一条不同颜色的线。切换机器用模板变量，比每次改查询方便得多：

• 在Dashboard Settings → Variables里新建一个变量host，Query填SHOW TAG VALUES ON server_monitor FROM cpu WITH KEY = host
• Panel查询里直接用WHERE host =~ /^$host$/，下拉框选机器，图表就跟着变了。

5.3 制作磁盘监控面板

磁盘面板比CPU复杂一点，因为每个机器上都有多个挂载点。查询里除了host还要带上path维度：

SELECT last(used_percent) FROM disk WHERE $timeFilter GROUP BY time($__interval), host, path

注意这里我用了last而不是mean，前面说过原因，磁盘使用率看最后值才准。展示方式上，可以用表格面板展示每台机器每个分区当前的使用率、总量和剩余量，也可以做成时间序列图，看分区空间随时间变化，对“半夜日志把磁盘塞满”这类问题的排查很有用。

5.4 内存与网络面板

内存面板推荐展示内存总量、可用量、使用量和缓存量：

SELECT mean(used) AS used, mean(available) AS available, mean(cached) AS cached FROM mem WHERE $timeFilter GROUP BY time($__interval), host

网络面板用netmeasurement，按网卡维度展示流量：

SELECT non_negative_derivative(first(bytes_recv),1s) AS recv, non_negative_derivative(first(bytes_sent),1s) AS sent FROM net WHERE $timeFilter GROUP BY time($__interval), host, interface

network数据保存的是累计字节数，必须用导数函数算速率才有意义。non_negative_derivative这个函数会做一次差分后取正的速率，负值跳变（网卡重启清零）会被过滤掉，比derivative更稳。

5.5 告警规则配置

Grafana的告警功能是使用这套看板最终目的。基于面板查询做告警，整体配置思路：

1. 在Alert标签页里点Create Alert Rule。
2. Condition里配置查询条件和阈值，例如CPU使用率大于90%持续5分钟。
3. Notifications里配置通知渠道，邮件、webhook或者钉钉告警群。

Grafana告警能识别查询结果里的多个序列，按序列分别判断。CPU多核主机你只需要看聚合均值95分位，可以在查询里先按聚合函数处理后再触发告警。否则每个核超过阈值都会单独告警，白天被CPU告警轰炸基本不用做别的事了。

我实际用下来，下面这几条告警规则属于“刚需级别”的：

监控指标	告警条件	建议通知方式
CPU使用率	连续5分钟均值 > 90%	邮件+群机器人
内存使用率	连续5分钟 > 95%	电话告警，因为你可能连SSH都进不去
磁盘使用率	连续10分钟 > 85%	群机器人，还得配合自动清理脚本
网络流量	连续5分钟入向>带宽上限	群机器人，需要先排查是不是被攻击了

主机离线这种问题，Grafana的时序数据本身不好判断。建议加一个prometheus风格的简单探针，或者用Blackbox Exporter定期探测ICMP/TCP端口，结合起来判断主机是否失联。这是很现实的痛点，因为有时候就是服务挂了你不知道，延迟感知就是灾难。

6. 真实环境踩坑记录与调优实践

这部分我想专门把实际部署运维里踩过的最有代表性的几个坑，一条条写下来，这些经验在别的文章或者文档里不一定会明确写出来，但对你落地成功率影响巨大。

6.1 时区问题与时间偏移

第一次用上这套Grafana组合时，我发现图表里所有数据都有8小时的偏差。原因很简单：InfluxDB默认存储的是UTC时间，而Grafana在展示的时候默认按浏览器本地时区渲染。按理说这正好可以抵消，但Telegraf在采集的时候使用了本地时间而不带时区信息，结果存进库的时间就比真实时间早/晚8小时。

解决方法是统一约定：Telegraf不需要特殊配置（它默认就是UTC写入），InfluxDB也不管时区，Grafana在首选项里设置时区为utc或者直接按25小时填充来校验。正确做法是让Grafana以UTC显示，因为Grafana内部处理时会根据所选时区正确转换，误导性最小。如果一定要用本地时间显示，就在Telegraf配置里明确加上utc_offset，但强烈不建议，排查问题会很痛苦。

6.2 磁盘爆掉与永久数据问题

很多人第一次跑通这套监控后发现数据量涨得飞快，特别是磁盘和网络面板做了高频率采集之后。实测下来，一台常规机器，10秒采集间隔，每天产生约500MB到1GB的原始数据。如果一个月的磁盘才40GB，又不设置保留策略，那很快全被监控数据填满。

所以保留策略必须提前设好。我对个人管理机的建议是：基础监控数据保留7~15天足够用了，更久远的周期数据用连续查询降采样后再存：

CREATE CONTINUOUS QUERY "cq_1h_cpu" ON server_monitor BEGIN SELECT mean(usage_user) AS usage_user, mean(usage_system) AS usage_system INTO "rp_30d"."cpu_1h" FROM "autogen"."cpu" GROUP BY time(1h), host END

连续查询会在每小时自动聚合并写入新表cpu_1h，历史数据过期时，这个降采样表还能保留很久。你只需要在Grafana里给长期趋势面板指定数据源的表名和保留策略即可。注意连续查询的源和目标是不同RP，目标RP上要设置了对应的保留时间。

6.3 高基数问题

InfluxDB有个很知名的坑：高序列基数（high series cardinality）会吃光内存。当你的tag组合特别多，比如数据库里塞了很多不稳定tag值（如session_id、随机端口），每个tag组合都算独立序列，InfluxDB需要在内存里索引每个序列，数量一多直接内存爆掉。

用Telegraf也要注意，尽量保持tag的取值集合可控。对于服务器监控来说，固定host标签很有周期性，不会造成大问题。但如果把Telegraf的输出扩展了业务数据，把用户ID、订单ID打进tag里，那序列基数很快就会爆炸。处理方式是：凡是高频变化的值必须放field，不放tag，这个原则是时序数据建模里铁律一样的存在。

6.4 监控自身占用过高

Telegraf采集所有插件全开的话，自身CPU占用一般不超过1%，内存几十MB。但有一种情况会异常升高：采集间隔设太短并且插件里还用了expensive=true的系统调用，比如exec插件每条采集都去执行一个shell脚本。频繁的subprocess调用会消耗大量系统资源，如果脚本内部还做了复杂处理，监控进程本身的CPU可能到5%甚至更高。

尽量别让Telegraf间接执行频繁的shell脚本，非用不可就把脚本的结果缓存起来，降低执行频率。procstat插件匹配大范围模式也会导致扫描开销高，在容器多或者进程多的机器上要慎用模糊匹配。

6.5 图表持续断线问题

dashboard图纸出现断断续续的空窗，多半是采集端到InfluxDB端有网络逆断或者InfluxDB写入超时。排查方向顺序：

1. 确认Telegraf日志有没有批量写入超时错误。
2. 查InfluxDB的write请求是否正常响应，有没有出现慢查询。
3. 如果写入突刺大，Grafana默认按1分钟分桶，中间10秒的间隙从时间轴上看起来像断线，实际数据是均匀的。可以把Min time interval调小，或者把图表的时间窗粒度调细，而不是判断为系统故障。

这类问题主要还是要靠数据分布是否均匀来判断，千万别因为看板断了个线就以为服务挂了，先看数据粒度设定。

7. 监控体系的进一步扩展

基础监控跑稳之后，TIG这套骨架完全可以继续长肉。下面聊几个我实际添加过、扩展性比较好的方向，你可根据手里设备的职责来选择。

• 进程与服务级监控：procstat插件继续增强，给redis、nginx、mysql这类主进程单独做CPU/内存/线程采集，配合告警能早早发现异常增长。
• 日志监控：Telegraf的tail插件可以读取指定日志文件，按正则pattern抛到InfluxDB，用关键字频率做面板，相当于一个极简版的日志分析工具。
• 自定义脚本采集：exec插件搭配任意可执行文件和JSON输出，获得非常强的自定义能力，比如自己写个脚本从第三方API拿天气数据、备案状态、域名到期时间，让监控里带上外部业务信息。
• 局域网内网络设备：用SNMP插件统一采集交换机和路由器接口流量状态。家里有硬件路由器的很适合做这套，不用进web后台一次一次看吞吐量。
• Docker容器状态：用docker插件直接对接Docker Daemon，拿到每个容器的CPU、内存、网络IO。这个不管是个人开发机还是服务器上都很实用。
• 温度与传感器：服务器如果有IPMI接口，可以用ipmi_sensor直接采集CPU与主板温度。个人NAS主板不带IPMI的，甚至可以接个USB温湿度计，也走Telegraf的modbus/自定义脚本方式采。

这些扩展每上一个，都是逐步往这套体系里叠加配置的过程。接口格式统一，而且不跑新的代理进程，成本很低，这也是我这几年一直舍不得换掉TIG的重要原因。

从第一天部署跑起来到现在，TIG这套组合在我手里一直非常稳定。Telegraf的采集、InfluxDB的存储、Grafana的展示和告警，各管一段，中间用标准协议连接。想想看，我们其实就是在用几个开源工具，把系统监控这件原本需要专职运维甚至商业方案才能做好的事，变成了一个人半小时就能搭完、日常几乎不用伺候的基础设施。这种掌控感，就是你部署完之后，能实在感受到的底气。如果你手头也有一台常年开机的服务器，别折腾研究了，直接把Telegraf的采集配起来、InfluxDB的数据存起来、Grafana的看板画起来，这套组合值得你拥有。