说明

没想到如此丝滑

本来是因为想稍微了解一下influxdb，然后发现和telegraf配套能干监控，然后正好之前又起了grafana,然后瞬间就通了。

内容

1 telegraf

Telegraf 是一个开源的服务器代理，用于收集、处理和发送数据。它是 InfluxData 公司推出的 TICK 堆栈（Telegraf、InfluxDB、Chronograf、Kapacitor）中的一部分，专门设计用于与 InfluxDB 一起使用，但它也可以与其他数据库和数据系统集成。

主要特点

1. 插件驱动架构:

   • Telegraf 是完全插件驱动的。它的功能通过输入插件（Input Plugins）、处理器插件（Processor Plugins）、聚合器插件（Aggregator Plugins）和输出插件（Output Plugins）实现。这种架构使得 Telegraf 可以高度灵活地适应各种数据源和目标。

2. 输入插件:

   • Telegraf 支持从多种来源收集数据，包括系统指标（如 CPU、内存、磁盘使用）、服务监控（如 Apache、NGINX、MySQL）、物联网设备、消息队列（如 Kafka、RabbitMQ）、日志文件、API 等。
   • 常见输入插件包括：cpu、mem、disk、net、docker、kafka_consumer 等。

3. 处理器插件:

   • 这些插件允许你在数据发送到目标之前对其进行处理，例如过滤、转换或格式化数据。
   • 例如，可以使用 regex 处理器插件来基于正则表达式修改或过滤数据。

4. 聚合器插件:

   • 这些插件允许你对数据进行聚合，例如对一组数据计算平均值、最大值、最小值等，然后再发送聚合后的结果。
   • 常见聚合器插件包括 basicstats 和 final。

5. 输出插件:

   • Telegraf 可以将收集和处理后的数据发送到各种目标，包括数据库（如 InfluxDB、MySQL、PostgreSQL）、消息队列（如 Kafka）、文件、HTTP 端点、监控系统（如 Prometheus）等。
   • 最常用的输出插件是 influxdb，用于将数据发送到 InfluxDB。

6. 易于配置和部署:

   • Telegraf 通过简单的配置文件进行配置，使用 TOML 格式。你可以轻松定义需要收集的数据、处理方式和数据输出的目标。
   • Telegraf 是轻量级的，可以作为单个二进制文件运行，非常适合在服务器、容器、虚拟机或物联网设备上部署。

7. 高性能和低资源占用:

   • Telegraf 被设计为高效的代理，能够在高吞吐量下运行，同时保持低资源占用。这使得它适合用于监控和数据收集的场景中，特别是在需要处理大量数据的环境下。

使用场景

• 系统监控: Telegraf 可以收集服务器的 CPU、内存、磁盘使用情况等指标，并将这些数据发送到 InfluxDB 或其他监控系统，以进行实时监控和分析。

• 应用性能监控: Telegraf 可以从应用程序收集性能指标和日志数据，用于监控应用的运行状态和健康状况。

• 物联网（IoT）数据收集: Telegraf 可以从 IoT 设备和传感器中收集数据，然后发送到中央数据库或云端进行进一步的处理和分析。

• 日志管理: Telegraf 可以收集系统和应用程序的日志文件，并将其发送到中央存储系统，方便后续的分析和处理。

• 集成数据流: Telegraf 可以作为数据管道的一部分，将来自不同数据源的数据收集、处理并发送到不同的目标系统，如数据湖、数据仓库或实时处理系统。

总结

Telegraf 是一个灵活且功能强大的数据收集代理，通过其丰富的插件系统，可以从各种数据源收集数据并发送到多种目标系统。它的轻量级和高性能使其成为监控、日志管理、物联网数据收集等场景中的理想选择。尤其是与 InfluxDB 结合使用时，它可以组成一个强大的时序数据收集和分析系统。

部署

需要配置文件，先简单配置simple_tg.conf

# Telegraf 配置

# 全局配置
[global_tags]  # 定义全局标签，可选
  # dc = "us-east-1"  # data center
  # host = "localhost"

[agent]
  interval = "10s"  # 数据收集间隔
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  collection_jitter = "0s"
  flush_interval = "10s"
  flush_jitter = "0s"
  precision = ""
  debug = false
  quiet = false
  logfile = ""  # 可定义日志文件路径
  hostname = ""

# 输入插件 - CPU 插件，收集 CPU 使用情况
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false
  report_active = false

# 输入插件 - 内存插件，收集内存使用情况
[[inputs.mem]]

# 输出插件 - 将数据发送到 InfluxDB
[[outputs.influxdb]]
  urls = ["http://172.17.0.1:8086"]  # InfluxDB 地址
  database = "telegraf"  # 数据库名
  precision = "s"
  timeout = "5s"
  username = "admin"  # InfluxDB 用户名
  password = "password"  # InfluxDB 密码

启动资源状态收集

docker run --name telegraf -d -v /root/simple_tg.conf:/etc/telegraf/telegraf.conf:ro registry.cn-hangzhou.aliyuncs.com/andy08008/telegraf:v100 

2 influxdb

Prometheus 和 InfluxDB 是两种常用于监控和时序数据存储的数据库系统。它们各有优势，适用于不同的场景。以下是它们的主要区别：

1. 设计目标

• Prometheus：专注于监控和报警系统，主要设计用于收集、存储和查询指标数据（metrics）。Prometheus 广泛用于云原生和微服务架构下的监控，尤其是在 Kubernetes 环境中。
• InfluxDB：是一个通用的时序数据库系统，适用于广泛的数据应用场景，不仅可以存储监控数据，还可以处理 IoT 数据、事件日志等。InfluxDB 更加注重灵活性和性能。

2. 数据模型

• Prometheus：数据模型是围绕指标（metrics）和标签（labels）设计的，结构简单。每个指标都是一个时间序列，并通过标签进行标识，标签有助于对数据进行多维查询和筛选。
• InfluxDB：使用更灵活的标签-字段模型。字段存储实际的值（数据点），而标签用于分组和查询数据。InfluxDB 提供了更复杂的 schema 设计，可以更好地支持事件驱动的时序数据。

3. 查询语言

• Prometheus：使用 PromQL（Prometheus Query Language）作为查询语言，专注于查询时序数据并执行聚合操作。PromQL 更适合监控场景，支持基于时间范围的查询、计算速率、百分位等。
• InfluxDB：使用 InfluxQL 和 Flux 两种查询语言。InfluxQL 类似 SQL，适合熟悉传统数据库查询的人；Flux 是 InfluxDB 提供的更强大的脚本语言，支持复杂的数据分析和处理。

4. 存储方式

• Prometheus：使用本地时间序列数据库，数据存储在 Prometheus 实例上。也可以配置远程存储系统，将历史数据存储到远程数据库。默认 Prometheus 会定期删除旧数据，存储周期较短。
• InfluxDB：支持长期存储和分区存储，数据可以通过不同的 retention policies 控制保留时间。InfluxDB 支持水平扩展，并且有企业版的高可用和分布式存储支持。

5. 集群和扩展性

• Prometheus：单节点运行，默认不提供内建的分布式存储或高可用性功能。可以通过配置多个 Prometheus 实例或者使用远程存储解决扩展和高可用问题。
• InfluxDB：企业版支持水平扩展和分布式架构，可以在多节点环境中实现高可用性和容错能力。InfluxDB 提供内置的集群管理和自动化的扩展功能。

6. 数据收集方式

• Prometheus：拉（pull）模型。Prometheus 定期从配置的 endpoints 中拉取数据。通过定义 scrape 配置，它能够自动发现目标（如 Kubernetes 中的服务）。
• InfluxDB：推（push）模型。InfluxDB 通常依赖于数据源或代理（如 Telegraf）推送数据到数据库。它也支持客户端库手动将数据推送到 InfluxDB。

7. 报警功能

• Prometheus：内置强大的报警系统，结合 PromQL 进行实时告警，通过 Alertmanager 发送通知。Prometheus 的报警机制高度集成，适用于监控场景。
• InfluxDB：自身不提供报警系统，但可以结合 Kapacitor 或第三方工具实现告警功能。InfluxDB 更适合存储和处理数据，而不是专注于报警。

8. 性能与适用场景

• Prometheus：轻量级，适合短期、高频监控。非常适合微服务、容器化应用的指标数据监控。
• InfluxDB：更适合大规模时序数据的持久化存储和复杂分析。适用于 IoT、金融数据分析、基础设施监控等场景。

总结

• Prometheus 更适合实时监控和报警，尤其在云原生和微服务架构下的监控非常流行。
• InfluxDB 则是一个通用的时序数据库，适合需要持久化、复杂分析、事件和日志处理的场景。

选择哪一个取决于你的使用场景：如果你的重点是监控和报警，Prometheus 是很好的选择；如果你需要长期存储和更复杂的数据处理，InfluxDB 可能更合适。

所以未来还有可能把prome也搭起来，有分工不同的。

部署

docker run -d -p 8086:8086 \
    --name influxdb \
    -v /etc/localtime:/etc/localtime -v /etc/timezone:/etc/timezone -v /etc/hostname:/etc/hostname -e "LANG=C.UTF-8" \
    -v /data/fluxdb:/var/lib/influxdb \
    registry.cn-hangzhou.aliyuncs.com/andy08008/influxdb:v1.8

InfluxDB 通常与以下工具或平台配合使用，以实现全面的数据采集、处理、存储和可视化：

1. Telegraf（数据采集）

• 用途：Telegraf 是 InfluxDB 生态系统中的代理工具，用于从不同的源（如服务器、网络设备、应用程序等）收集指标数据并将其发送到 InfluxDB。
• 示例应用场景：监控服务器的 CPU、内存、磁盘使用情况，或从 IoT 设备中采集传感器数据。

2. Grafana（数据可视化）

• 用途：Grafana 是一个开源的、广泛使用的可视化和监控工具。它可以与 InfluxDB 集成，从数据库中提取数据并展示成图表、仪表盘。
• 示例应用场景：用 Grafana 可视化 InfluxDB 中的监控数据，生成实时仪表盘，用于系统监控、业务指标跟踪等。

3. Kapacitor（实时数据处理和告警）

• 用途：Kapacitor 是 InfluxData 提供的实时流处理和告警工具。它可以处理从 InfluxDB 收集的时间序列数据，实时触发告警或执行自定义操作。
• 示例应用场景：根据 CPU 使用率超过某个阈值，Kapacitor 可以发送通知或执行自动化修复任务。

4. Chronograf（用户界面和仪表盘）

• 用途：Chronograf 是 InfluxDB 的官方 UI，允许用户浏览、分析和可视化数据。它集成了 Kapacitor，可以配置告警和监控任务。
• 示例应用场景：通过图形界面管理和监控 InfluxDB 数据，同时创建告警规则。

5. Prometheus（与 InfluxDB 作为时间序列数据库的替代或配合）

• 用途：Prometheus 是另一个常用的时间序列数据库，专注于监控和告警。某些场景下，Prometheus 可以与 InfluxDB 配合或替代，用于不同类型的时间序列数据监控。
• 示例应用场景：Prometheus 更适合用于短期监控，而 InfluxDB 适合用于长期存储时间序列数据。

6. Ansible 或 Terraform（自动化部署和配置管理）

• 用途：通过这些工具可以自动化部署 InfluxDB、Telegraf、Grafana 等组件，并管理其配置。
• 示例应用场景：大规模集成监控环境时，通过 Ansible 自动化部署多个监控节点。

这些工具共同构成了一个完整的数据采集、存储、分析和可视化的生态系统，特别适合于时间序列数据的处理和分析。

Kapacitor、Chronograf、Ansible这些值得之后再看一看。

3 grafana

部署有点忘了，也是采用docker方式。可以看到prome和influxdb都是core

也支持sql类

在dashboard的配置上，是这样的

有些还不熟悉，后续再看看。