rsdatakit

rsdatakit 是面向 Linux 主机和 Kubernetes 节点的轻量采集器，使用 Rust 编写，并以 DataKit/Guance Point v2 格式将数据发送至 Dataway。

功能概览¶

当前支持 Linux amd64 和 arm64。不支持 Windows、macOS、OTLP Metrics、OTLP Logs、 eBPF、拨测、远程配置及 DataKit 插件系统。

运行要求¶

• Linux 主机需要可访问 /proc 和 /sys；journald 采集还需要 systemd journal 运行库。
• 使用安装脚本管理 rsdatakit 服务需要 systemd 和 systemctl。
• Kubernetes 采集需要以 DaemonSet 运行在待采集节点，并允许读取 Pod 元数据、Kubelet Summary 和宿主机容器日志目录。
• 需要可用的 Dataway 地址和 token。配置文件及状态目录应仅允许运行用户访问。

安装¶

RSDATAKIT_DATAWAY_URL="https://openway.guance.com" \
RSDATAKIT_DATAWAY_TOKEN="<DATAWAY_TOKEN>" \
  sh -c "$(curl -fsSL https://static.guance.com/rsdatakit/install.sh)"

RSDATAKIT_DATAWAY_URL="https://openway.guance.com" \
RSDATAKIT_DATAWAY_TOKEN="<DATAWAY_TOKEN>" \
  sh -c "$(curl -fsSL https://static.guance.com/rsdatakit/install-<VERSION>.sh)"

RSDATAKIT_UPGRADE=1 \
  sh -c "$(curl -fsSL https://static.guance.com/rsdatakit/install.sh)"

systemctl is-active rsdatakit
systemctl status rsdatakit --no-pager
journalctl -u rsdatakit -n 30 --no-pager

wget https://static.guance.com/rsdatakit/rsdatakit.yaml

wget -O rsdatakit.yaml https://static.guance.com/rsdatakit/rsdatakit-<VERSION>.yaml

kubectl create namespace rsdatakit-system --dry-run=client -o yaml | kubectl apply -f -
kubectl -n rsdatakit-system create secret generic rsdatakit-secrets \
  --from-literal=dataway-url='https://openway.guance.com' \
  --from-literal=dataway-token='<DATAWAY_TOKEN>' \
  --from-literal=otlp-token='<OTLP_TOKEN>' \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl apply -f rsdatakit.yaml

kubectl -n rsdatakit-system rollout status daemonset/rsdatakit
kubectl -n rsdatakit-system get pods -l app.kubernetes.io/name=rsdatakit

kubectl -n rsdatakit-system logs daemonset/rsdatakit --tail=100

配置¶

默认配置路径为 /etc/rsdatakit/rsdatakit.toml。也可以通过 --config <path> 或 RSDATAKIT_CONFIG 指定其他配置文件。配置只在进程启动时读取，修改后需要重启服务。

最小可用配置如下：

[agent]
# 本地状态目录，保存 WAL 和文件日志读取位置；必须使用绝对路径。
state_dir = "/var/lib/rsdatakit"
# 可选的独立健康检查监听地址；留空时不单独监听。
health_addr = ""

[dataway]
# 工作区 Dataway 写入地址。
url = "https://openway.example.com"
# 工作区 token。
token = "<DATAWAY_TOKEN>"
# 单次 Dataway 请求超时（秒），范围为 1–60。
timeout_secs = 15
# 追加到所有上报数据的 tag。
global_tags = { env = "prod" }
# 写入索引；留空使用工作区默认索引。
storage_index = ""

[metrics]
# 主机指标采集周期（秒），范围为 5–300。
interval_secs = 15
# 采集容量的挂载点；最多 32 个，且必须使用绝对路径。
mounts = ["/"]
# 是否额外采集 veth、docker0、cni 等虚拟网卡。
enable_virtual_interfaces = false

[hostobject]
# HOST 主机对象上报周期（秒），范围为 60–3600。
interval_secs = 300

[wal]
# 本地写前日志目录；必须使用绝对路径。
dir = "/var/lib/rsdatakit/wal"
# WAL 总容量上限（字节），范围为 4 MiB–256 MiB；写满时淘汰最旧的未发送数据。
max_bytes = 268435456

agent.state_dir、logs.state_dir 和 wal.dir 必须使用绝对路径。默认 WAL 容量为 256 MiB，应按可接受的 Dataway 中断时长和日志/Trace 写入量调整 wal.max_bytes。 进程启动时可通过 RSDATAKIT_DATAWAY_URL 和 RSDATAKIT_DATAWAY_TOKEN 分别覆盖配置文件中的地址和 token；RSDATAKIT_HEALTH_ADDR 可覆盖独立健康检查地址。

主机采集¶

主机指标和 HOST 对象默认启动，无需额外 enabled 开关。

主机指标周期范围为 5–300 秒；HOST 对象周期范围为 60–3600 秒。CPU、网络和磁盘 I/O 速率依赖前后两次样本，刚启动时第一轮可能没有速率字段。

指标¶

以下表格只列出 rsdatakit 当前实际上报的字段。字段名与 DataKit 同名指标集保持兼容，但 rsdatakit 没有实现 DataKit 对应采集器的所有扩展字段。

cpu¶

mem¶

disk¶

每个 [metrics].mounts 中配置的挂载点产生一个 Point。

diskio¶

每个具有 I/O 计数的 Linux 块设备产生一个 Point。

net¶

每个符合过滤规则且具有前一轮样本的网络接口产生一个 Point。

system¶

对象¶

HOST¶

日志采集¶

日志默认关闭。空 paths 不采集任何文件；请仅配置明确需要的路径，不要使用过宽的全局 glob。

[logs]
# 是否启用文件日志采集。
enabled = true
# 要采集的日志文件绝对路径 glob。
paths = ["/var/log/my-service/*.log"]
# 日志数据来源名称。
source = "my-service"
# 追加到日志的 service tag。
service = "my-service"
# 将顶层 JSON 对象的第一层成员作为日志字段上报。
json_as_fields = false
# 同时读取的活跃文件上限。
max_files = 32
# 重新发现匹配文件的周期（秒）。
discovery_secs = 5
# copytruncate 日志轮转识别策略。
copytruncate_mode = "auto"
# 保存文件读取位置的本地目录；必须使用绝对路径。
state_dir = "/var/lib/rsdatakit"

# 仅在使用 journald feature 构建，并且主机具备 libsystemd 运行库时生效。
journald_enabled = false
# 仅采集指定 systemd unit；留空采集所有可访问的 journal。
journald_unit = "my-service.service"

[logs.multiline]
# 续行模式；留空则每一行独立上报。
continuation_regex = "^\\s+"
# 等待续行的最长时间（毫秒）。
flush_timeout_ms = 1000
# 单条合并日志允许的最大字节数。
max_bytes = 262144

日志位置、journald cursor 和 WAL 存储在状态目录。文件日志在重启后从已确认位置继续读取； 数据已经写入 WAL 或已被 Dataway 接收后才推进位置。多行续行匹配时会合并为一条日志。

json_as_fields 默认关闭。开启后，顶层为对象的 JSON 日志会把第一层成员作为字段上报： 字符串、布尔值、int64 和有限 float64 保留类型，对象和数组编码为紧凑 JSON 字符串， null 及超出支持范围的数值忽略。解析失败、顶层不是对象或没有可用字段时保留原始 message。JSON 字段覆盖同名采集器字段；字段名按 Point 规则规范化并限制为 256 字节， 单个 Point 最多保留 1024 个 field。time、source、date 和 storage_index 分别改名为 json_* 字段，不修改 Point 时间、日志 source 或存储索引。也可通过 RSDATAKIT_LOG_JSON_AS_FIELDS=true 开启；原 json_extract 和 RSDATAKIT_LOG_JSON_EXTRACT 继续作为兼容别名。

journald_enabled = true 表示额外从 systemd journal 读取日志，不影响文件日志是否采集。 发布包会启用 journald；源码手动构建时使用：

cargo build --release --locked --features journald

日志数据¶

日志 measurement 为 [logs].source。Kubernetes 容器日志的初始 source 通常配置为 kubernetes；元数据匹配成功后，measurement 会改为容器名。

Kubernetes 容器日志在元数据可用时还会增加以下 tag：

OpenTelemetry Trace¶

OTLP 默认关闭。开启后接收 OTLP Trace，并转发到 tracing 数据类别：

[otlp]
# 是否启动 OTLP HTTP 和 gRPC 接收器。
enabled = true
# OTLP/HTTP 监听地址。
http_addr = "127.0.0.1:4318"
# OTLP/gRPC 监听地址，必须与 http_addr 不同。
grpc_addr = "127.0.0.1:4317"
# 非本地监听地址所需的 Bearer Token；本地监听可留空。
bearer_token = ""
# 单个 OTLP 请求允许的最大字节数。
max_request_bytes = 4194304
# 最大并发 OTLP 请求数。
max_concurrent_requests = 8
# 已受理 OTLP 请求的总内存预算（字节）。
max_inflight_bytes = 16777216

当 HTTP 或 gRPC 地址绑定到非 loopback 地址时，必须设置 bearer_token，客户端使用 Authorization: Bearer <token>。当前仅接收 Trace；OTLP Metrics 和 OTLP Logs 请求不受支持。 /health 可由 agent.health_addr 独立提供；OTLP 关闭时不会绑定 4317/4318。 连接空闲期限为 30 秒；HTTP header/body、gRPC 连接启动及请求体接收/解码分别受 65 秒绝对期限约束。gRPC 完整解码消息和 trailers 后即停止请求体期限；后续映射、入队和等待 Dataway/WAL receipt 没有总 handler 超时，活跃请求也不会被连接空闲期限中断。gRPC 请求体超过接收期限时返回 DeadlineExceeded 并释放全局准入预算。

Trace 数据¶

OTLP Span 输出到 tracing 类别，measurement 固定为 opentelemetry。时间字段 start 和 duration 使用微秒；Point 自身时间戳使用 Span 的纳秒开始时间。

常用 OTel Resource/Span 属性会转换为扁平字段，例如 db.system → db_system、 db.operation.name → db_operation、http.request.method → http_method、 http.response.status_code → http_status_code、rpc.system → rpc_system、 messaging.system → messaging_system。字符串、布尔、整数和浮点值保留原类型；数组和对象编码为 JSON。 单个属性来源最多处理 256 个属性。不在当前语义映射白名单内的属性不会成为顶层字段，但会保留在 message JSON 中。

语义属性字段¶

下面列出当前白名单内的 OTel 属性映射。除 http_status_code 外，字段类型保持输入属性的 string、bool、int 或 float 类型；数组和 key/value 对象会编码成 JSON 字符串。

在 Kubernetes 模式下，Trace 还可增加与容器日志相同的集群、Node、Pod、Container、workload 和白名单 label tag。OTel Resource 中已经提供的身份信息优先，缺失项才从本节点 Pod 缓存补全。

Kubernetes 采集¶

Kubernetes 模式由 [kubernetes].enabled = true 开启。DaemonSet 通过本节点的 Pod 元数据、 Kubelet /stats/summary 和宿主机 /var/log/pods 采集数据：

[kubernetes]
# 是否启用 Kubernetes 采集。
enabled = true
# 是否上报 Pod 和容器指标。
metrics_enabled = true
# 是否上报 Pod 和容器对象。
objects_enabled = true
# Kubernetes 集群名称。
cluster_name = "default"
# 本节点 Pod 元数据刷新周期（秒）。
refresh_secs = 60
# Pod 和容器对象上报周期（秒）。
object_interval_secs = 300
# 允许附加到数据的 Pod label 白名单。
label_tags = ["app.kubernetes.io/name"]

metrics_enabled 和 objects_enabled 可独立控制。指标默认每 60 秒采集，对象启动时立即上报、 之后默认每 5 分钟上报。label_tags 是允许附加的 Pod label 白名单，用于控制标签基数。

rsdatakit 访问 Kubelet 时使用 HTTPS 和自动挂载的 ServiceAccount bearer token，并由 nodes/stats RBAC 权限完成授权；为兼容节点本地自签名证书和缺少 Node IP SAN 的集群， Kubelet 连接不校验服务端证书。Kubernetes API 使用独立客户端，仍通过 ServiceAccount CA 严格校验证书。

项目 DaemonSet 示例还会挂载 /var/log/pods、/var/lib/docker/containers 和 /var/lib/rsdatakit。容器日志来自节点本地文件，不会为每条日志调用 Kubernetes API；Pod 元数据 通过共享的本节点缓存补全。

指标¶

Kubelet Summary 中没有提供的可选字段不会产生。CPU、内存、文件系统和网络累计值均来自本节点 Kubelet /stats/summary；request、limit、ready、restart 和 workload tag 来自 Pod API 元数据。

kube_pod¶

每个本节点 Pod 产生一个 Point。

docker_containers（Kubernetes 指标）¶

每个本节点容器产生一个 Point。容器网络由 Pod 级别的 kube_pod 上报，因此这里没有网络字段。

对象¶

对象使用与 DataKit 页面兼容的对象分类。对象 message 是当前对象字段的 JSON 快照。 如果 Kubelet Summary 当轮可用，对象还会带上同一 Pod/容器的资源字段；这些字段在下表中逐一列出。

kubelet_pod 对象¶

docker_containers 对象¶

Prometheus 采集¶

Prometheus 抓取是 Kubernetes 模式的一部分。独立二进制默认关闭，项目 DaemonSet 示例默认开启：

[kubernetes.prometheus]
# 是否启用本节点 Prometheus 目标发现和抓取。
enabled = true
# 每个目标的抓取周期（秒）。
scrape_interval_secs = 30
# 单次抓取超时（秒）。
scrape_timeout_secs = 10
# 是否保留 exporter 的完整指标名作为 field 名。
keep_exist_metric_name = true
# 是否发现带 prometheus.io/scrape 注解的 Pod。
discover_pod_annotations = true
# 是否发现带 prometheus.io/scrape 注解的 Service。
discover_service_annotations = true
# 是否发现 Prometheus Operator 的 PodMonitor。
discover_pod_monitors = true
# 是否发现 Prometheus Operator 的 ServiceMonitor。
discover_service_monitors = true

除自动发现外，也可以配置可信的显式目标：

[[kubernetes.prometheus.instances]]
# 目标来源类型。
role = "pod" # node | pod | service | endpoints
# 目标所在命名空间。
namespaces = ["default"]
# Kubernetes label selector。
selector = "app=nginx"
# 抓取协议。
scheme = "http"
# 端口号或命名端口。
port = "metrics"
# 指标 HTTP 路径。
path = "/metrics"
# measurement 名称；留空时自动推导。
measurement = ""
# 追加到此目标所有指标的 tag。
tags = { team = "platform" }

支持以下目标来源：

• Pod/Service 的 prometheus.io/scrape、port、scheme、path 等 annotations；
• Prometheus Operator 的 PodMonitor 和 ServiceMonitor；
• 可信静态配置中的 node、pod、service、endpoints 实例。

只抓取可确认属于当前节点的目标，避免 DaemonSet 的每个副本重复抓取整个集群。采集的 measurement 由 exporter 指标名或静态 measurement 配置决定；collector.up 用于表示每个目标的抓取结果。

如不需要相应发现能力，请关闭对应 discover_* 开关。关闭 Service annotation、ServiceMonitor 且未配置 service/endpoints 显式实例时，不会订阅全局 Service 和 EndpointSlice 资源。

指标转换规则¶

Prometheus exporter 的 measurement 和 field 由指标名动态生成，无法像固定主机指标一样穷举：

每次抓取还会产生采集器状态指标：

collector¶

运行与验证¶

sudo RUST_LOG=rsdatakit=info rsdatakit --config /etc/rsdatakit/rsdatakit.toml

sudo systemctl restart rsdatakit
sudo systemctl status rsdatakit
sudo journalctl -u rsdatakit -f

kubectl -n rsdatakit-system rollout status daemonset/rsdatakit
kubectl -n rsdatakit-system get pods -l app=rsdatakit
kubectl -n rsdatakit-system logs daemonset/rsdatakit --tail=100

启动日志出现 rsdatakit started 后，可在中心检查以下数据：

配置独立健康地址或开启 OTLP HTTP 后可查看健康状态，例如：

curl http://127.0.0.1:4319/health

返回 degraded 表示 Dataway、WAL 或某个采集模块存在当前故障；返回 HTTP 503 表示队列、 WAL 或后台任务已进入不健康状态。

注意事项¶

• 日志和 Trace 在网络错误、HTTP 5xx 或 429 时写入 WAL 并重试；其他 4xx 不重试。 指标和对象是周期快照，不写入 WAL。
• 根据日志和 Trace 写入量以及允许的 Dataway 中断时间调整 wal.max_bytes。
• Dataway token 和 OTLP bearer token 应通过 Secret 或受限配置文件注入，不要提交到仓库。
• 仅将必要的 Pod label 加入 kubernetes.label_tags，避免产生高基数 tag。
• RUST_LOG=rsdatakit=debug 会产生大量运行日志，只应在短时间排障时使用。