mcpField
N
Netra

Netra

本地服务
github.com云与基础设施51 周前更新

关于 Netra

Netra 面向 Linux 和 Kubernetes 运维人员,提供基于 eBPF 的网络观测与紧急控制。它结合内核级流量诊断和限时拒绝规则,规则到期后自动恢复为观测模式,且无需更换 CNI。

主要功能

  1. 01内核级丢包归因
  2. 02TCP 路径与拥塞诊断
  3. 03筛选式实时抓包
  4. 04每秒指标与异常检测
  5. 05预览式限时拒绝规则
  6. 06190 个受控变更 MCP 工具

适用场景

  1. 01定位流量丢失及其原因
  2. 02排查工作负载网络延迟
  3. 03围绕发现抓取数据包
  4. 04临时阻断流量并自动恢复

MCP 相关

Netra 提供面向 AI Agent 的 MCP 服务,包含 190 个 stdio 工具:130 个只读工具,以及 60 个需通过 NETRA_MCP_ALLOW_MUTATIONS 启用的变更工具。

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置
{
"mcpServers": {
"zyvorai-netra": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"NETRA_URL",
"-e",
"NETRA_API_KEY",
"-e",
"NETRA_MCP_ALLOW_MUTATIONS",
"-e",
"NETRA_MCP_ACTOR",
"ghcr.io/zyvorai/netra-mcp:0.32.0"
],
"env": {
"NETRA_URL": "<NETRA_URL>",
"NETRA_API_KEY": "<NETRA_API_KEY>",
"NETRA_MCP_ALLOW_MUTATIONS": "<NETRA_MCP_ALLOW_MUTATIONS>",
"NETRA_MCP_ACTOR": "<NETRA_MCP_ACTOR>"
}
}
}
}
启动命令docker run -i --rm -e NETRA_URL -e NETRA_API_KEY -e NETRA_MCP_ALLOW_MUTATIONS -e NETRA_MCP_ACTOR ghcr.io/zyvorai/netra-mcp:0.32.0
需要配置的环境变量
NETRA_URLBase URL of the Netra controller API, e.g. https://netra.example:30870.
NETRA_API_KEY密钥Bearer token for the controller API.
NETRA_MCP_ALLOW_MUTATIONSSet to "true" to expose the opt-in mutating tools. Off by default; mutations remain plan-token and lease bounded.
NETRA_MCP_ACTORActor name recorded in the Netra audit trail for calls made through this server.

本地服务需要在你的电脑上安装运行环境(如 Node.js 18+)。各客户端的配置文件位置不同,请参考客户端文档。

安装包
ocighcr.io/zyvorai/netra-mcp:0.32.0

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。

详细介绍

Netra

CI License: Zyvor Production v1.0 Version Go eBPF Docs

预约演示 30 天 PoC 快速入门

Netra — 独立的 eBPF 网络可观测性和紧急网络控制

洞察每个数据包的来龙去脉。遏制异常数据包。自动解除限制。

适用于 Linux/Kubernetes 的独立 eBPF 网络可观测性和紧急网络控制——可选集成 Cilium + Hubble 增强信息。 内核丢弃归因、路径和拥塞诊断、实时数据包捕获,以及会自动恢复为观察模式的限时拒绝规则,适用于任何 CNI。

观察优先 · 限制有期限,故障时开放 · 无需 CNI · 不收集负载 · 190 个 MCP 工具

📖 阅读完整文档 — 快速入门、架构、安全模型和产品导览。


最新动态

摘自 CHANGELOG.md(0.28.2 至 0.30.0):

每秒指标 (0.30.0)每秒提供主机、网络、cgroup、进程组、eBPF 和工作负载 RED 序列,并支持异常检测、指标告警、应用采集器、导出器,以及从任意图表峰值跳转到其背后的流量和丢弃事件。文档 →
节点隔离 (0.30.0)作为独立 TCX 程序,提供逐节点的仅允许出站流量过滤器,可运行于影子模式(统计本应被阻止的流量)或强制执行模式。文档 →
安全审查 (0.30.0)DNS 查询类型、带过期时间的版本化威胁源、回滚和可选 HTTPS 刷新、拒绝谓词重叠审查,以及精确到工作负载的事件关联。文档 →
当前内核上的 L7 元数据 (0.30.0)Linux 6.8+ 上重新支持 TLS SNI、HTTP Host 和 DNS 名称加载(此前会被验证器拒绝);在 Linux 5.17+ 上使用 bpf_loop。文档 →
Netlink 变更记录器记录节点上哪个链路、地址、路由或邻居发生了变化,以及变化时间;覆盖所有路由表。文档 →
Netlink 发现结果和告警根据记录的变更发现默认路由被移除、网关不可达、上行链路关闭、MTU 变更等情况。
变更操作者rtnetlink_rcv_msg 上的 fentry 会将每个修改 Netlink 的请求归因到发送请求的进程。
BPF 挂载清单Netra 会在自身钩子意外消失时发出通知,例如 NIC 或 bond 重建之后。文档 →
统一的 UX 规范仪表板和文档站点遵循统一的设计规范;默认采用 Apple 浅色风格,也可一键切换为深色风格。
稳定的控制器证书tls.existingSecret 会提供 kubernetes.io/tls Secret,供客户端固定控制器证书。

为什么选择 Netra

当出现这种情况时……Netra 可以为你提供……
流量消失了,却没人说得清它去了哪里内核丢包归因:连接、原因,以及丢弃流量的内核函数
你需要立即采取行动,但担心强制执行带来风险带租约的拒绝规则,可自动恢复;并且会先根据实时流量进行预览
你的 CNI 不是 Cilium,或者你无法更改它适用于任何 CNI 的 cgroup v2 挂钩,无需内核模块,也无需更改应用
只有“网络很慢”这一说法,却没有证据TCP 路径诊断和拥塞图,按 Linux 网络栈各层最严重的问题为其着色
图表出现峰值,你需要知道原因每秒指标与异常检测;每个峰值都链接到该时间窗口内的流、丢包原因和捕获数据
你现在就需要某个节点的网络包带过滤条件且有时间限制的实时捕获,提供 Wireshark 风格的分层解码,可从发现项一键打开
你希望 AI Agent 在不造成破坏的前提下进行调查配备 190 个工具的 MCP 服务;变更操作受 NETRA_MCP_ALLOW_MUTATIONS 控制

Netra 不要求使用 Cilium。节点 Agent 在 /sys/fs/bpf/netra 下管理自己的程序和映射。如果存在 Cilium/Hubble,Netra 可以管理 CiliumNetworkPolicy 并显示 Hubble 流,但这两项集成都需选择启用。

功能一览——观察、诊断、遏制、集成


Netra 与 Cilium + Hubble 对比

Netra 与 Cilium + Hubble:eBPF 可视性和紧急开关,同时保留你的 CNI

NetraCilium + Hubble
产品定位与你的 CNI 并行运行的可观测性和紧急控制工具内置于自身数据路径的 Hubble 可观测性 CNI
部署方式通过 Helm 安装控制器和节点 Agent DaemonSet;无需更改 CNICilium 将成为集群的 CNI
内核挂钩cgroup skb、connect/sendmsg、sockops;可选 kfree_skb、TCX 和 XDPCilium 自有的 eBPF 数据路径
强制执行模式带租约的拒绝规则;租约到期或控制器丢失状态时恢复为观察模式网络策略会持续生效,直到被移除
丢包诊断按连接提供内核丢包原因和丢弃流量的函数,另有 Drop Explain来自 Cilium 数据路径的 Hubble 流判定结果和丢包原因
纯 Linux 主机使用相同的 Agent 和挂钩围绕由 Cilium 管理的网络构建
协同运行可选的 CiliumNetworkPolicy 编写和 Hubble Relay 流—
选择 Cilium + Hubble 的情况你需要一套内置策略强制执行和 Hubble 可观测性的完整 CNI,并且可以将其用作 CNI

Netra 绝不会修改或固定覆盖 Cilium 所有的 BPF 映射,因此两者可以共用一个集群。


实时体验

概览页面、Firewall 页面的统一规则表和 NetPol v2 允许列表,以及连接到运行中 KubeVirt VM 的真实浏览器内 VNC 控制台——这些内容均取自实时实验环境部署,而非模型图:

Netra 实时演示——概览、Firewall/NetPol v2、浏览器内 VNC 控制台

Netra 仪表板——概览

概览页面。 更多界面见观察、诊断和遏制。


工作原理

Netra 工作原理——内核挂钩、固定映射、节点 Agent、控制器和你

                        Browser / netractl
                               |
                               v
                    +---------------------+
                    |      netrad        |
                    | API + UI + state    |
                    +----------+----------+
                               |
                 desired config| node reports
                               v
       +------------------------------------------------+
       |          netra-agent on every Linux node      |
       |                                                |
       | cgroup skb + socket hooks       optional TCX   |
       |          |                         optional XDP |
       |          +------ Netra maps/ring buffer ------+
       |                 /sys/fs/bpf/netra             |
       +------------------------------------------------+

netrad 默认在 :30870 上提供 HTTPS 服务。挂钩模型、可见性边界以及可选的 Cilium/Hubble 集成:docs/architecture.md · 独立 eBPF。


快速入门

make install                              # netractl → /usr/local/bin (or PREFIX=$HOME/.local)
netractl install --namespace netra-system # Helm install: controller + node agent DaemonSet
netractl status

然后打开 https://<node-ip>:30870 并登录。仪表板位于登录界面之后——请参阅登录(导航栏和登录界面均带有 Zyvor 标识)。

登录

需要运行 cgroup v2 和 bpffs 的 Linux 系统;建议的基线版本为 Linux 5.8+(TCX 6.6+)。请先运行 netra-doctor。完整步骤、Helm 配置值、Cilium/Hubble 和 CLI 示例:安装指南。


观测

流量信息包含 Pod 和所有者归属、TCP 健康状况、DNS、TLS SNI 和 HTTP Host 元数据、行为基线及漂移。存在 Cilium 时可查看实时 Hubble 流量。功能 →

Hubble 实时流量

流量流详细信息

诊断

TCP 路径诊断按工作负载测量连接延迟和传输压力,并提供边缘观测到的握手和 RTT 直方图,可查看经过 NAT 的流量。路径 → · 边缘情报 →

TCP 路径诊断——压力、连接延迟和边缘 TCP 情报

拥塞地图根据最严重的问题为 Linux 网络栈的每一层着色,覆盖整个集群。单击即可跳转到问题节点上的数据包捕获。内核诊断 →

拥塞地图——按严重程度着色,覆盖整个集群

数据包捕获可实时流式传输经过筛选且有时间范围限制的捕获内容,按协议着色,并提供类似 Wireshark 的分层解码和十六进制转储。启用自动捕获后,关键问题会触发 PCAP 持久化。捕获 →

实时捕获视图——按颜色区分的终端信息流,标注 Pod/VM 归属

类似 Wireshark 的数据包详细信息,由实时视图中的一行展开

从拥塞地图中的问题跳转到问题节点上的实时解码彩色捕获:

Netra 实时演示——从拥塞地图问题跳转到实时数据包捕获

丢包解释结合内核原因和策略上下文,回答“为什么会丢弃此数据包?”。丢包诊断 → · 丢包信息 →

丢包解释

更多内容:DNS、ICMP、行为和速率洞察。

监控

每秒指标,零配置。 每个节点都会将主机、网络栈、conntrack、cgroup、进程组、eBPF 数据路径和各工作负载的 RED 序列流式传输到控制器;数据按 1 秒粒度保留 1 小时、按 1 分钟粒度保留 2 周、按 1 小时粒度保留 1 年。指标页面可实时绘制所有上下文的图表,并在每张图表上显示异常标记带。指标 →

  • 异常检测覆盖所有维度(无监督 k-means、Go 标准库),还可对你拖选的任意时间范围进行“这里发生了什么变化”排序。异常 →
  • 指标告警采用 Netdata 风格的规则和迟滞机制,内置 40 多种规则(CPU、内存、磁盘、接口、TCP、conntrack、工作负载 RED、eBPF 丢包),并通过你现有的 Slack、webhook 或 PagerDuty 渠道发送。告警 →
  • 每张图表都有证据支撑:发生峰值时,可直接跳转到同一时间窗口内的流量、丢包原因、TCP/DNS/HTTP 面板和数据包捕获。指标和数据包一处查看。
  • 应用采集器支持 nginx、Apache、HAProxy、Redis、memcached、Envoy、CoreDNS、etcd 和任何 Prometheus 端点,并可选择启用自动发现。应用 →
  • 导出到 Prometheus remote write、OTLP 或 Graphite,并提供跨集群的只读集群汇总。

采集器为只读,进程组仅使用内核 comm(绝不读取 argv 或环境变量),告警也绝不会影响强制执行。

隔离

按 IP、CIDR、端口、DNS 名称、TLS SNI、UID 或进程拒绝访问,并限定在命名空间、Pod、所有者或标签范围内。先预览影响范围。应用策略仍需计划令牌 + 风险确认。防火墙页面 →

防火墙仪表板 — 统一规则、NetPol v2 允许列表/默认拒绝

策略编写

策略试运行 / 预检

启用 Cilium 后,Pod 和 VM 可通过相同的计划 → 回执 → 应用流程,一键锁定 / 解锁:

Pod 清单,可一键锁定 / 解锁

安全设计

租约限定的强制执行 — 观察、租约期内强制执行、自动恢复观察

承诺含义
优先观察可在观察期间暂存规则。只有在启用强制执行后才会丢弃流量
租约式强制执行租约到期、Agent 无法刷新控制器状态、控制器重启或 HA 领导权变更时,均会恢复为观察状态
不收集负载不收集应用负载、argv/cmdline 或 Secret 内容。选择启用的采样传感器仅保留计数
自动化设限MCP 变更操作受 NETRA_MCP_ALLOW_MUTATIONS 控制;AI 端点为只读
兼容 Cilium绝不修改或固定覆盖由 Cilium 管理的 BPF 映射

详情:架构与可见性边界 · 安全与持久化。

面向 AI Agent 和运维人员

  • netractl — 运维 CLI。文档 →
  • 安全审查 — DNS QTYPE、带 TTL/回滚功能且可选通过 HTTPS 刷新的版本化威胁情报源、扁平拒绝谓词建议,以及针对确切工作负载的安全关联分析。文档 →
  • MCP 服务 — 为 AI Agent 提供 190 个 stdio 工具(130 个只读,60 个选择启用的变更工具)。文档 →
  • 内置 AI 简报 — 默认采用启发式方法,可选使用兼容 OpenAI 的方式改写,且为只读。文档 →
  • 导出 — SIEM(CEF、syslog、JSONL、OTLP)、Prometheus(抓取和远程写入)、Grafana、Loki、Graphite、Slack 和 Teams ChatOps。

Netra 还是 PacketWolf?

Netra 和 PacketWolf 从相反方向覆盖相同的 eBPF 领域。它们是互补产品,而非串联的流水线。

选择 Netra 的情况…选择 PacketWolf 的情况…
与 CNI 无关的观察 + 租约式紧急断路开关Cilium 已经是指定的 CNI
无需完整平台即可诊断路径/丢弃/拥塞完整的 AutoPolicy / healer / operator 堆栈

规则:docs/packetwolf.md · 套件定位。

文档导航

我想……阅读
查看 Netra 观测和控制的所有内容功能 · 功能目录
了解诊断诊断概览
按秒监控节点和工作负载指标 · 指标告警 · 异常检测 · 应用采集器
了解钩子和架构架构 · 独立 eBPF
安装和配置安装指南 · Helm/清单 · 主机就绪状态
运维netractl · 高可用
浏览代码仓库布局 · CI
以采购方身份评估采购指南 · 宣传册和 PDF · 资源

成熟度

Netra 的最新版本为 0.32.0(CHANGELOG.md)。已发布的观测和租约控制功能均为 GA。下表说明了默认运行的功能,以及出于隐私或安全考虑仍需选择启用的功能(架构):

区域状态
cgroup skb ingress/egress、connect/sendmsg、sockops 钩子GA(默认)
kfree_skb 丢弃原因、TCX、XDPGA(可选挂载),仅适用于选定接口
强制执行GA — 默认观测;租约式强制执行结束后恢复为观测
TLS SNI、HTTP Host、DNS 名称和查询类型GA(默认,NETRA_L7=auto),Linux 5.17+;在较旧内核上丢弃
TLS 指纹(JA3/JA4)GA(默认,agent.tlsfp: auto)
DNS 异常检测 / 扫描检测GA(默认);仅观测
每秒指标、异常、指标告警GA(默认,NETRA_METRICS_ENABLED);告警仅发送通知
严重丢弃时自动捕获GA(默认);时长/冷却时间/PPS 均有限制;使用 alerting.autoCapture.enabled=false 禁用
自动缓解(流量洪泛)GA(默认);仅在存在有效强制执行租约时生效;故障时保持开放
节点隔离GA — 已加载(agent.nodeIsolation: auto),直到设置每节点策略前均不生效;支持影子模式或强制执行(租约式)
安全审查、威胁源历史记录和回滚GA(只读);仅在设置 NETRA_INTEL_SOURCE_URL 时通过 HTTPS 刷新威胁源
历史拒绝预览(流历史)GA — 实时计数器,以及可选的 --since / flowlog 时间窗口
采样式 L7 和 TLS 明文传感器选择启用(隐私),默认关闭
Cilium CiliumNetworkPolicy 和 Hubble 集成选择启用(cilium.enabled、hubble.enabled)
MCP 变更型工具选择启用(安全性,NETRA_MCP_ALLOW_MUTATIONS)

Zyvor 技术栈的一部分

产品与 Netra 搭配时的作用
Netra独立的 eBPF 网络可观测性和租约式紧急控制,适用于任何 CNI
Paqtra在 Cilium 集群中与 Netra 搭配:Hubble 流追踪、丢弃原因说明和策略预览
Rivora与 Netra 搭配:独立于 CNI 的 eBPF L4 负载均衡器,支持 XDP、Maglev 和 BGP
Zorvia与 Netra 搭配:KubeVirt VM 平台;启用 Cilium 后,Netra 的 VMs 页面会显示带实时流量并可锁定的 KubeVirt VM
netevd在主机上与 Netra 搭配:将 netlink 和 eBPF 网络事件传递到钩子脚本和策略路由

→ zyvor.dev


许可证

Netra 以源代码可用的形式提供,遵循 Zyvor Production License v1.0(SPDX LicenseRef-Zyvor-Production-1.0,也见 LICENSES/)。

贡献:CONTRIBUTING.md。请按照 SECURITY.md 的说明私下报告漏洞。


看见它、控制它,并让它自动释放

预约演示 30 天概念验证 定价 联系销售 在 GitHub 上点星

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。