菜单
文档breadcrumb arrow Grafana 文档breadcrumb arrow 设置breadcrumb arrow 设置 Grafana Live
Enterprise 开源

设置 Grafana Live

Grafana Live 是一个实时消息引擎，可用于在事件发生时立即将事件数据推送到前端。

这可以是关于仪表盘更改的通知、渲染数据的新帧等等。Live 功能可以帮助消除许多地方的页面重新加载或轮询，它还可以将物联网 (IoT) 传感器或任何其他实时数据流式传输到面板。

注意

这里的 实时 指的是软实时。由于网络延迟、垃圾回收周期等原因，消息传递的延迟可能会达到几百毫秒或更高。

概念

Grafana Live 通过持久的 WebSocket 连接向客户端发送数据。Grafana 前端订阅通道以接收发布到该通道的数据——换句话说，使用的是 PUB/SUB 机制。页面上的所有订阅都在单个 WebSocket 连接内多路复用。关于 Live 通道名称有一些规则——请参阅 Grafana Live 通道。

大规模处理像 WebSocket 这样的持久连接可能需要调整操作系统和基础设施。这就是为什么 Grafana Live 默认最多支持 100 个并发连接。有关如何调整此限制的更多详细信息，请参阅 Live 配置部分。

功能

拥有实时向客户端发送数据的方式为新的数据交互和可视化方式打开了道路。下面我们介绍 Grafana Live 当前支持的功能。

仪表盘更改通知

仪表盘布局一旦发生更改，将立即自动反映到连接到 Grafana Live 的其他设备上。

从插件流式传输数据

使用 Grafana Live，后端数据源插件可以将更新流式传输到前端面板。

对于数据源插件通道，Grafana 使用 ds 范围。数据源通道的命名空间是 Grafana 在创建数据源时分配的数据源唯一 ID (UID)。路径是插件作者可以自由选择的自定义字符串（只需确保它由允许的符号组成）。

例如，数据源通道看起来像这样：ds/<DATASOURCE_UID>/<CUSTOM_PATH>。

有关更多详细信息，请参阅 构建流式数据源后端插件 的教程。

Grafana 核心中包含的基本流式示例将带有生成数据的数据帧流式传输到面板。要查看它，请创建一个新面板并将其指向 -- Grafana -- 数据源。接下来，选择 Live Measurements 并选择 plugin/testdata/random-20Hz-stream 通道。

从 Telegraf 流式传输数据

新的 API 端点 /api/live/push/:streamId 允许接受来自 Telegraf 的 Influx 格式的指标数据。这些指标被转换为 Grafana 数据帧并发布到通道。

有关更多信息，请参阅 将指标从 Telegraf 流式传输到 Grafana 的教程。

Grafana Live 通道

Grafana Live 是一个 PUB/SUB 服务器，客户端订阅通道以接收发布到这些通道的实时更新。

通道结构

通道是一个字符串标识符。在 Grafana 中，通道由 / 分隔的 3 部分组成

  • 范围
  • 命名空间
  • 路径

例如，通道 grafana/dashboard/xyz 具有范围 grafana、命名空间 dashboard 和路径 xyz。

目前，范围、命名空间和路径只能包含 ASCII 字母数字符号 (A-Z, a-z, 0-9)、_（下划线）和 -（破折号）。路径部分还可以包含 /、. 和 = 符号。范围、命名空间和路径的含义是上下文相关的。

通道的最大长度为 160 个字符。

范围决定了通道在 Grafana 中的用途。例如，对于数据源插件通道，Grafana 使用 ds 范围。对于内置功能（如仪表盘编辑通知），Grafana 使用 grafana 范围。

命名空间根据范围具有不同的含义。例如，对于 grafana 范围，这可以是内置实时功能的名称，如 dashboard（即仪表盘事件）。

路径是通道的最后一部分，通常包含某个具体资源的标识符，例如用户当前正在查看的仪表盘的 ID。但路径可以是任何内容。

通道是轻量级且短暂的——它们在用户订阅时自动创建，并在最后一个用户离开通道时立即移除。

数据格式

通过 Live 通道传输的所有数据都必须进行 JSON 编码。

配置 Grafana Live

Grafana Live 默认启用。在 Grafana v8.0 中，它对每个 Grafana 服务器实例的最大连接数有一个严格的默认限制。

最大连接数

Grafana Live 使用持久连接（目前是 WebSocket）向客户端发送实时更新。

WebSocket 是一种持久连接，它以 HTTP Upgrade 请求开始（使用与 Grafana 其余部分相同的 HTTP 端口），然后切换到 TCP 模式，在该模式下 WebSocket 帧可以在客户端和服务器之间双向传输。每个登录用户都会打开一个 WebSocket 连接——每个浏览器标签页一个。

用户可以与 Grafana 建立的最大 WebSocket 连接数默认为 100。请参阅 max_connections 选项。

如果您想增加此限制，请确保您的服务器和基础设施允许处理更多连接。以下部分讨论了管理持久连接（尤其是 WebSocket 连接）时可能发生的几个常见问题。

请求源检查

为避免 WebSocket 连接劫持，Grafana Live 会检查客户端在 HTTP Upgrade 请求中发送的 Origin 请求头。没有 Origin 头的请求将直接通过，不进行任何源检查。

默认情况下，Live 接受 Origin 头与配置的 root_url（公共 Grafana URL）匹配的连接。

可以提供一个额外的源模式列表，以允许来自这些模式的 WebSocket 连接。这可以使用 Grafana Live 配置的 allowed_origins 选项实现。

资源使用

每个持久连接都会占用服务器的一些内存。通常，目前每个连接大约需要 50 KB。因此，一个拥有 1 GB RAM 的服务器预计最多可以处理大约 2 万个连接。每个活动连接都会消耗额外的 CPU 资源，因为客户端和服务器会互相发送 PING/PONG 帧来维护连接。

使用流式传输功能会导致额外的 CPU 使用。准确的 CPU 资源利用率很难估计，因为它严重取决于 Grafana Live 的使用模式。

文件打开限制

每个 WebSocket 连接都会占用运行 Grafana 的服务器机器上的一个文件描述符。大多数操作系统的默认限制都相当低，限制了进程可以打开的最大描述符数量。

要在 Unix 上查看当前限制，请运行

ulimit -n

在 Linux 系统上，您还可以通过以下命令查看正在运行进程的当前限制

cat /proc/<PROCESS_PID>/limits

打开文件限制大致显示了您的服务器当前可以处理多少用户连接。

要增加此限制，请参阅 这些说明（针对流行的操作系统）。

临时端口耗尽

临时端口耗尽问题可能发生在负载均衡器（或反向代理）软件和 Grafana 服务器之间。例如，当您在不同的 Grafana 实例之间进行请求/连接的负载均衡时。如果您直接连接到单个 Grafana 服务器实例，则不会遇到此问题。

问题在于每个 TCP 连接在操作系统中由以下四元组唯一标识

source ip | source port | destination ip | destination port

默认情况下，在负载均衡器/服务器边界，您最多只能有 65535 种组合。但实际上，由于一些操作系统限制（例如 Unix 中 ip_local_port_range sysctl 参数定义的可用端口）以及处于 TIME_WAIT 状态的套接字，数量会更少。

为了解决此问题，您可以

  • 通过调整 ip_local_port_range 内核选项来增加临时端口范围。
  • 部署更多 Grafana 服务器实例进行负载均衡。
  • 部署更多负载均衡器实例。
  • 使用虚拟网络接口。

WebSocket 和代理

并非所有代理默认都能透明地代理 WebSocket 连接。例如，如果您在 Grafana 之前使用 Nginx，您需要像这样配置 WebSocket 代理

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream grafana {
        server 127.0.0.1:3000;
    }

    server {
        listen 8000;

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $http_host;
            proxy_pass http://grafana;
        }
    }
}

有关更多信息，请参阅 Nginx 网站上的博客文章。此外，请查阅您的负载均衡器/反向代理文档，以获取有关处理 WebSocket 连接的更多信息。

一些公司代理可能会移除正确建立 WebSocket 连接所需的头部。在这种情况下，您应该调整中间代理，使其不移除必需的头部。然而，更好的选择是使用带有 TLS 的 Grafana。这样 WebSocket 连接将继承 TLS，因此必须由代理透明地处理。

像 Nginx 和 Envoy 这样的代理对于最大可建立连接数有默认限制。请确保您的代理配置中传入和传出连接的最大数量有合理的限制。

配置 Grafana Live 高可用 (HA) 设置

默认情况下，Grafana Live 使用内存数据结构和内存 PUB/SUB 中心来处理订阅。

在包含负载均衡器后面的多个 Grafana 服务器实例的高可用 Grafana 设置中，您可能会遇到以下限制

  • 内置功能（如仪表盘更改通知）只会广播给连接到同一 Grafana 服务器进程实例的用户。
  • 从 Telegraf 流式传输的数据只会被发送到连接到接收 Telegraf 数据的同一实例的客户端，活动流缓存不会在不同的 Grafana 实例之间共享。
  • 对于同一通道，可以在不同的 Grafana 服务器上打开 Grafana 和后端数据源之间的单独单向流。

为了绕过这些限制，Grafana v8.1 有一个实验性的 Live HA 引擎，需要 Redis 才能工作。

配置 Redis Live 引擎

配置 Redis 引擎后，Grafana Live 将其状态保存在 Redis 中，并使用 Redis PUB/SUB 功能向所有 Grafana 服务器节点上的所有订阅者传递消息。

这是一个配置示例

[live]
ha_engine = redis
ha_engine_address = 127.0.0.1:6379

有关更多信息，请参阅 ha_engine 和 ha_engine_address 选项。

运行后

  • 所有内置的实时通知（如仪表盘更改）都将传递到所有 Grafana 服务器实例并广播给所有订阅者。
  • 从 Telegraf 流式传输的消息将传递给所有订阅者。
  • 对于同一通道，在不同的 Grafana 服务器上会打开 Grafana 和后端数据源之间的单独单向流。将数据发布到通道会传递消息给实例订阅者，因此，来自不同机器上不同实例的发布不会在面板上产生重复数据。

注意

Live 目前不支持 Redis Sentinel。我们建议使用 Redis Cluster 实现高可用性，例如通过 Bitnami Redis chart 等 k8s helm chart，该 chart 具有用于配置 Redis Cluster 的值。然后可以将 Grafana Live 指向 redis-headless 服务。

 live:
   ha_engine: redis
   ha_engine_address: redis-headless.grafana.svc.cluster.local:6379
   ha_engine_password: $__file{/your/redis/password/secret/mount}