Newt可观测性配置指南Prometheus指标、OTLP遥测与pprof实战【免费下载链接】newtPangolin tunneled site network connector项目地址: https://gitcode.com/gh_mirrors/ne/newtNewt 是 Pangolin 开源的隧道站点与网络连接器Tunneled site network connector它不仅是打通内网与公网的桥梁更内置了一整套开箱即用的可观测性能力。无论你是刚接触 Newt 的新手还是正在大规模运维 Pangolin 网络的工程师掌握Newt可观测性配置都能让你对隧道健康、站点在线状态、代理连接数了如指掌。本文将从零开始带你实战配置三大支柱Prometheus指标采集、OTLP遥测导出以及pprof性能剖析全程附赠可直接复制的配置方案。什么是Newt可观测性指标、追踪与剖析三件套 Newt 的可观测性并非单一功能而是由三套互补的机制构成能力用途默认状态Prometheus 指标监控站点在线数、隧道会话、流量字节等默认开启OTLP 遥测将指标与追踪导出到 OpenTelemetry Collector默认关闭pprof 剖析抓取 CPU、内存、阻塞等运行时画像默认关闭三者统一由 Newt 内置的 admin HTTP 服务承载核心初始化逻辑集中在internal/telemetry/telemetry.go中环境变量解析、导出器装配都在这里完成。这套设计让 Newt 既能被 Prometheus 直接抓取也能无缝融入企业级 OTLP 采集管道非常灵活。最快配置方法一条环境变量开启Prometheus指标 Newt 的 Prometheus 指标导出默认就是开启的你只需要做两件事确认没有关闭它并让监控系统能访问到/metrics端点。启动时加上参数或设置环境变量均可# 方式一命令行参数 newt --metrics --metrics-admin-addr :2112 # 方式二环境变量效果相同 export NEWT_METRICS_PROMETHEUS_ENABLEDtrue export NEWT_ADMIN_ADDR:2112默认绑定地址就是:2112对应的端口映射在Dockerfile中也有EXPOSE 2112。启动后访问http://newt地址:2112/metrics即可看到newt_前缀的指标输出。上图就是 Newt 运行时的典型日志WebSocket 连接成功、隧道建立、TCP 代理启动整个过程都会产生对应的可观测数据。admin 服务的装配代码在main.go中当metrics或pprof任一开启时它就会挂载/metrics、/healthz和/debug/pprof/路由。核心Prometheus指标速查表这些指标你必须认识 Newt 的指标全部遵循 OpenTelemetry 命名规范计数器以_total结尾时长单位为秒字节数为原始字节。核心指标定义在internal/telemetry/metrics.go中这里挑几个最常用的指标名类型含义newt_site_onlineGauge站点是否在线0/1newt_site_registrations_totalCounter站点注册尝试次数newt_tunnel_sessionsGauge当前活跃隧道会话数newt_tunnel_bytes_totalCounter隧道进出流量字节数按 direction 区分newt_tunnel_latency_secondsHistogram隧道延迟分布newt_websocket_connectedGaugeWebSocket 连接状态1/0newt_websocket_reconnects_totalCounter重连次数按 reason 区分newt_proxy_active_connectionsGauge代理活跃连接数newt_proxy_connection_duration_secondsHistogram代理连接时长newt_build_infoGauge构建版本与 commit 信息指标标签采用低基数设计只保留tunnel_id、transport、direction、protocol、result、error_type等稳定维度避免高基数爆炸。如果你担心tunnel_id标签带来过大基数可以设置NEWT_METRICS_INCLUDE_TUNNEL_IDfalse将其剔除。OTLP遥测配置用OpenTelemetry统一采集指标与追踪 当你的监控体系已经基于 OpenTelemetry 时可以让 Newt 把指标和追踪通过OTLP 遥测协议发送给 Collector实现统一采集。相关环境变量如下export NEWT_METRICS_OTLP_ENABLEDtrue export OTEL_EXPORTER_OTLP_ENDPOINTotel-collector:4317 export OTEL_EXPORTER_OTLP_INSECUREtrue export OTEL_METRIC_EXPORT_INTERVAL15s export OTEL_SERVICE_NAMEnewt export OTEL_SERVICE_VERSION1.3.4其中OTEL_METRIC_EXPORT_INTERVAL控制指标上报周期默认 15sOTEL_SERVICE_NAME作为服务名写入资源属性。官方还提供了一个完整的 Collector 配置参考examples/otel-collector.yaml其中包含了memory_limiter、resourcedetection、batch等生产级处理器以及 Prometheus exporter 的端口设置。⚠️ 架构上分为两种模式Variant A让 Prometheus 直接抓取 Newt 的/metrics最简单Variant B则是 Newt → OTLP → Collector → Prometheus 的链路。两者二选一切勿同时对同一进程双路采集否则指标会翻倍一键搭建Docker Compose部署Prometheus与Grafana监控全家桶 不想手动装配仓库自带了现成的 Compose 编排直接启动即可获得完整的监控栈docker compose -f docker-compose.metrics.yml up -d这个编排对应docker-compose.metrics.yml会拉起三件套Newt启用 Prometheus 指标暴露2112端口Prometheus通过examples/prometheus.yml配置每 15 秒抓取一次/metricsGrafana自动配置数据源和看板访问http://localhost:3005默认账号admin/admin即可查看。如果走 Collector 路线则使用docker-compose.metrics.collector.yml它会额外拉起otel/opentelemetry-collector-contrib此时务必在 Newt 服务上设置NEWT_METRICS_PROMETHEUS_ENABLEDfalse避免重复采集。开箱即用的Grafana看板Newt概览面板 无需从零画图仓库提供了预置的 Grafana 看板文件examples/grafana/dashboards/newt-overview.json配合examples/grafana/provisioning/dashboards/dashboard.yaml自动加载配置启动后 Grafana 会自动导入。看板中你可以直接看到站点在线状态、隧道会话数、WebSocket 连接状态、代理活跃连接数等核心 Prometheus 指标的可视化视图。对于多站点部署配合site_id标签可以按站点过滤快速定位异常节点。pprof实战三个步骤定位Newt性能瓶颈 当隧道吞吐下降、CPU 飙升时pprof就是你最趁手的诊断工具。首先开启它newt --pprof # 或 export NEWT_PPROF_ENABLEDtrue开启后 admin 服务会挂载完整的 pprof 端点见main.go中的注册逻辑支持/debug/pprof/profile、/debug/pprof/trace、/debug/pprof/cmdline等标准路由。接着用 Go 自带的工具抓取画像# 抓取 30 秒 CPU 画像 go tool pprof http://newt地址:2112/debug/pprof/profile?seconds30 # 抓取内存堆画像 go tool pprof http://newt地址:2112/debug/pprof/heap # 抓取 10 秒执行追踪 curl http://newt地址:2112/debug/pprof/trace?seconds10 -o trace.out go tool trace trace.out进入 pprof 交互界面后输入top查看热点函数输入web生成调用火焰图。通过对比不同时段的画像可以快速定位内存泄漏或 CPU 热点。需要注意的是pprof 属于调试接口生产环境建议仅在排查问题时临时开启或通过防火墙限制访问。避坑指南3个常见问题 ⚠️指标翻倍同时开启直接抓取和 Collector 双路采集会导致同一指标被抓两次务必二选一。examples/prometheus.yml中注释也特别提醒了这一点。标签基数过高tunnel_id每个隧道唯一隧道频繁重建会产生大量标签组合影响 Prometheus 性能。可设置NEWT_METRICS_INCLUDE_TUNNEL_IDfalse或用抓取端的labeldrop规则丢弃该标签配置参考examples/prometheus.yml中的relabel_configs。端口冲突使用 Collector 模式时不要在应用服务上映射2112端口否则可能与 Collector 的 Prometheus exporter 端口冲突建议只在采集侧映射。小结 ✨至此你已经掌握了 Newt 可观测性的完整配置路径Prometheus指标负责实时监控、OTLP遥测负责融入统一采集管道、pprof负责深度性能剖析三者协同即可构建一套覆盖监测—告警—诊断的完整闭环。配置细节都可以在仓库源码中找到环境变量解析见internal/telemetry/telemetry.go指标定义见internal/telemetry/metrics.goadmin 服务装配见main.goCompose 编排见docker-compose.metrics.yml与docker-compose.metrics.collector.yml。现在就去开启你的 Newt 监控之旅吧【免费下载链接】newtPangolin tunneled site network connector项目地址: https://gitcode.com/gh_mirrors/ne/newt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Newt可观测性配置指南：Prometheus指标、OTLP遥测与pprof实战
Newt可观测性配置指南Prometheus指标、OTLP遥测与pprof实战【免费下载链接】newtPangolin tunneled site network connector项目地址: https://gitcode.com/gh_mirrors/ne/newtNewt 是 Pangolin 开源的隧道站点与网络连接器Tunneled site network connector它不仅是打通内网与公网的桥梁更内置了一整套开箱即用的可观测性能力。无论你是刚接触 Newt 的新手还是正在大规模运维 Pangolin 网络的工程师掌握Newt可观测性配置都能让你对隧道健康、站点在线状态、代理连接数了如指掌。本文将从零开始带你实战配置三大支柱Prometheus指标采集、OTLP遥测导出以及pprof性能剖析全程附赠可直接复制的配置方案。什么是Newt可观测性指标、追踪与剖析三件套 Newt 的可观测性并非单一功能而是由三套互补的机制构成能力用途默认状态Prometheus 指标监控站点在线数、隧道会话、流量字节等默认开启OTLP 遥测将指标与追踪导出到 OpenTelemetry Collector默认关闭pprof 剖析抓取 CPU、内存、阻塞等运行时画像默认关闭三者统一由 Newt 内置的 admin HTTP 服务承载核心初始化逻辑集中在internal/telemetry/telemetry.go中环境变量解析、导出器装配都在这里完成。这套设计让 Newt 既能被 Prometheus 直接抓取也能无缝融入企业级 OTLP 采集管道非常灵活。最快配置方法一条环境变量开启Prometheus指标 Newt 的 Prometheus 指标导出默认就是开启的你只需要做两件事确认没有关闭它并让监控系统能访问到/metrics端点。启动时加上参数或设置环境变量均可# 方式一命令行参数 newt --metrics --metrics-admin-addr :2112 # 方式二环境变量效果相同 export NEWT_METRICS_PROMETHEUS_ENABLEDtrue export NEWT_ADMIN_ADDR:2112默认绑定地址就是:2112对应的端口映射在Dockerfile中也有EXPOSE 2112。启动后访问http://newt地址:2112/metrics即可看到newt_前缀的指标输出。上图就是 Newt 运行时的典型日志WebSocket 连接成功、隧道建立、TCP 代理启动整个过程都会产生对应的可观测数据。admin 服务的装配代码在main.go中当metrics或pprof任一开启时它就会挂载/metrics、/healthz和/debug/pprof/路由。核心Prometheus指标速查表这些指标你必须认识 Newt 的指标全部遵循 OpenTelemetry 命名规范计数器以_total结尾时长单位为秒字节数为原始字节。核心指标定义在internal/telemetry/metrics.go中这里挑几个最常用的指标名类型含义newt_site_onlineGauge站点是否在线0/1newt_site_registrations_totalCounter站点注册尝试次数newt_tunnel_sessionsGauge当前活跃隧道会话数newt_tunnel_bytes_totalCounter隧道进出流量字节数按 direction 区分newt_tunnel_latency_secondsHistogram隧道延迟分布newt_websocket_connectedGaugeWebSocket 连接状态1/0newt_websocket_reconnects_totalCounter重连次数按 reason 区分newt_proxy_active_connectionsGauge代理活跃连接数newt_proxy_connection_duration_secondsHistogram代理连接时长newt_build_infoGauge构建版本与 commit 信息指标标签采用低基数设计只保留tunnel_id、transport、direction、protocol、result、error_type等稳定维度避免高基数爆炸。如果你担心tunnel_id标签带来过大基数可以设置NEWT_METRICS_INCLUDE_TUNNEL_IDfalse将其剔除。OTLP遥测配置用OpenTelemetry统一采集指标与追踪 当你的监控体系已经基于 OpenTelemetry 时可以让 Newt 把指标和追踪通过OTLP 遥测协议发送给 Collector实现统一采集。相关环境变量如下export NEWT_METRICS_OTLP_ENABLEDtrue export OTEL_EXPORTER_OTLP_ENDPOINTotel-collector:4317 export OTEL_EXPORTER_OTLP_INSECUREtrue export OTEL_METRIC_EXPORT_INTERVAL15s export OTEL_SERVICE_NAMEnewt export OTEL_SERVICE_VERSION1.3.4其中OTEL_METRIC_EXPORT_INTERVAL控制指标上报周期默认 15sOTEL_SERVICE_NAME作为服务名写入资源属性。官方还提供了一个完整的 Collector 配置参考examples/otel-collector.yaml其中包含了memory_limiter、resourcedetection、batch等生产级处理器以及 Prometheus exporter 的端口设置。⚠️ 架构上分为两种模式Variant A让 Prometheus 直接抓取 Newt 的/metrics最简单Variant B则是 Newt → OTLP → Collector → Prometheus 的链路。两者二选一切勿同时对同一进程双路采集否则指标会翻倍一键搭建Docker Compose部署Prometheus与Grafana监控全家桶 不想手动装配仓库自带了现成的 Compose 编排直接启动即可获得完整的监控栈docker compose -f docker-compose.metrics.yml up -d这个编排对应docker-compose.metrics.yml会拉起三件套Newt启用 Prometheus 指标暴露2112端口Prometheus通过examples/prometheus.yml配置每 15 秒抓取一次/metricsGrafana自动配置数据源和看板访问http://localhost:3005默认账号admin/admin即可查看。如果走 Collector 路线则使用docker-compose.metrics.collector.yml它会额外拉起otel/opentelemetry-collector-contrib此时务必在 Newt 服务上设置NEWT_METRICS_PROMETHEUS_ENABLEDfalse避免重复采集。开箱即用的Grafana看板Newt概览面板 无需从零画图仓库提供了预置的 Grafana 看板文件examples/grafana/dashboards/newt-overview.json配合examples/grafana/provisioning/dashboards/dashboard.yaml自动加载配置启动后 Grafana 会自动导入。看板中你可以直接看到站点在线状态、隧道会话数、WebSocket 连接状态、代理活跃连接数等核心 Prometheus 指标的可视化视图。对于多站点部署配合site_id标签可以按站点过滤快速定位异常节点。pprof实战三个步骤定位Newt性能瓶颈 当隧道吞吐下降、CPU 飙升时pprof就是你最趁手的诊断工具。首先开启它newt --pprof # 或 export NEWT_PPROF_ENABLEDtrue开启后 admin 服务会挂载完整的 pprof 端点见main.go中的注册逻辑支持/debug/pprof/profile、/debug/pprof/trace、/debug/pprof/cmdline等标准路由。接着用 Go 自带的工具抓取画像# 抓取 30 秒 CPU 画像 go tool pprof http://newt地址:2112/debug/pprof/profile?seconds30 # 抓取内存堆画像 go tool pprof http://newt地址:2112/debug/pprof/heap # 抓取 10 秒执行追踪 curl http://newt地址:2112/debug/pprof/trace?seconds10 -o trace.out go tool trace trace.out进入 pprof 交互界面后输入top查看热点函数输入web生成调用火焰图。通过对比不同时段的画像可以快速定位内存泄漏或 CPU 热点。需要注意的是pprof 属于调试接口生产环境建议仅在排查问题时临时开启或通过防火墙限制访问。避坑指南3个常见问题 ⚠️指标翻倍同时开启直接抓取和 Collector 双路采集会导致同一指标被抓两次务必二选一。examples/prometheus.yml中注释也特别提醒了这一点。标签基数过高tunnel_id每个隧道唯一隧道频繁重建会产生大量标签组合影响 Prometheus 性能。可设置NEWT_METRICS_INCLUDE_TUNNEL_IDfalse或用抓取端的labeldrop规则丢弃该标签配置参考examples/prometheus.yml中的relabel_configs。端口冲突使用 Collector 模式时不要在应用服务上映射2112端口否则可能与 Collector 的 Prometheus exporter 端口冲突建议只在采集侧映射。小结 ✨至此你已经掌握了 Newt 可观测性的完整配置路径Prometheus指标负责实时监控、OTLP遥测负责融入统一采集管道、pprof负责深度性能剖析三者协同即可构建一套覆盖监测—告警—诊断的完整闭环。配置细节都可以在仓库源码中找到环境变量解析见internal/telemetry/telemetry.go指标定义见internal/telemetry/metrics.goadmin 服务装配见main.goCompose 编排见docker-compose.metrics.yml与docker-compose.metrics.collector.yml。现在就去开启你的 Newt 监控之旅吧【免费下载链接】newtPangolin tunneled site network connector项目地址: https://gitcode.com/gh_mirrors/ne/newt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考