数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载RiseDev 为 RisingWave 的开发调试内置了一整套可观测性组件覆盖集群内部状态访问risectl、指标监控Prometheus Grafana、流式链路追踪Tempo、Actor 运行时可视化Dashboard以及基于tokio-tracing的日志体系。本文以仓库中的 observability.md 为主线结合 risedev.yml 与相关源码实现逐步说明如何在本地开发集群上打开这些能力并深入解读底层原理帮助你在排查流式任务、分析执行计划、定位性能瓶颈时具备完整的可观测手段。risectlRisingWave 集群内部状态访问工具risectl是 RisingWave 提供内部访问能力的命令行工具用于查看和操作集群内部的运行状态例如查询 Actor 分布、SST 文件、barrier 状态、表统计信息等是开发调试期间最重要的入口之一。查看其完整用法有两条等价途径# 直接通过 cargo 运行 risectl 二进制查看全部子命令与参数 cargo run --bin risectl -- --help# 或通过 RiseDev 封装入口其内部同样调用 risectl ./risedev ctl --help从源码结构看risectl由src/ctl/目录下的risingwave_ctlcrate 提供而 RiseDev 开发集群的组件入口位于 src/cmd_all/src/bin/risingwave.rs其中Component::Ctl对应的二进制名称正是risectl。因此无论是cargo run --bin risectl还是./risedev ctl最终都会走到同一套命令实现。提示risectl需要连接运行中的集群才能工作。在risedev.yml中提供了名为for-ctl的最小配置 profileminio meta-node compute-node frontend compactor可视为“专门配合 risectl 使用的最小集群”适合只想快速试验内部命令的场景。Monitoring用 Prometheus Grafana 观测集群指标RisingWave 的各个节点meta、compute、frontend、compactor都会通过 exporter 端口暴露 Prometheus 格式的指标。要在本地开发环境启用指标采集与可视化只需编辑risedev.yml取消prometheus与grafana两行的注释steps: - use: meta-node - use: compute-node - use: frontend # 取消以下注释以启用指标采集与可视化 - use: prometheus # metrics - use: grafana # visualizationrisedev.yml中defaultprofile 的步骤区已经预留了这行注释直接取消注释并./risedev d即可拉起一个带监控的开发集群。仓库中fullprofilerisedev.yml也展示了同时启用 Prometheus、Grafana 的完整编排示例。从配置生成源码看这三个组件的配置结构位于 src/risedevtool/src/service_config.rsPrometheusConfig支持scrape_interval、remote_write、remote_write_region、remote_write_url等字段service_config.rsGrafanaConfig通过provide_prometheus、provide_tempo字段建立与数据源的关联service_config.rs。也就是说Grafana 会自动把同 profile 中启用的 Prometheus指标和 Tempo追踪配置为数据源无需手工接线。对应的实现分别位于 prometheus_gen.rs、grafana_gen.rs服务启动任务在 prometheus_service.rs 与 grafana_service.rs。进阶full-benchmarkprofilerisedev.yml演示了remote-write: true的用法将指标通过 remote write 推送到远端工作区适用于压测等需要集中收集指标的场景。Tracing启用 Tempo 查看流式计算链路RisingWave 的 Compute 节点支持基于 OpenTelemetry 的流式链路追踪可以直观看到一条消息流过各个 streaming executor 的完整路径。该功能默认不开启启用步骤如下先执行./risedev configure下载并安装追踪组件Tempo编辑risedev.yml取消tempo服务行的注释重新启动一个新的开发集群使组件生效建议同时取消grafana行的注释因为最终是在 Grafana 中可视化 trace。steps: - use: meta-node - use: compute-node - use: frontend # 取消以下注释以启用链路追踪与可视化 - use: tempo # tracing - use: grafana # visualizationTempoConfig的字段定义在 service_config.rs包含otlp_port接收 OTLP 上报的端口与max_bytes_per_trace等参数配置生成实现在 tempo_gen.rs。追踪在源码中的落地方式Compute 节点中的每个 executor 在执行消息流时会被trace包装器包裹为每条消息创建tracingspan并上报给 OpenTelemetry。核心实现在 src/stream/src/executor/wrapper/trace.rs每个 executor 使用tracing::info_span!(executor, otel.name info.identity, ...)创建一个以 executor 身份命名的 spantrace.rs对Chunk消息记录cardinality与capacity对Watermark记录value与col_idx对Barrier记录prev_epoch、curr_epoch、kind、mutationtrace.rs注释明确说明“被trace包装的流会以tracingspans 记录并上报到opentelemetry”trace.rs。因此在 Grafana 的 Tempo 数据源中看到的一条 trace本质上就是一条 Chunk/Watermark/Barrier 消息在“Source → 各算子 executor → Sink”之间的完整传递记录非常适合定位消息卡在哪个算子。Dashboard查看系统中的 Actor 与执行计划RisingWave Dashboard 是内置于 meta node 的 Web 界面用于可视化系统中的 Actor、Fragment 和执行计划explain 图。它随 meta node 一起启动默认访问地址为http://127.0.0.1:5691/从 risedev.yml 中的 meta-node 配置可以看到meta 节点默认监听port: 5690、dashboard 监听dashboard-port: 5691例如meta-1cn-1fe-sqliteprofilerisedev.yml与文档所述的5691端口一致。Dashboard 的开发与调试方式记录在 dashboard/README.md它是一个基于 Next.js 的独立前端工程支持两种形态——独立部署的 UI或作为静态 HTML 内嵌在 meta service 中。开发模式下可以这样启动# 启动完整集群确保 prometheus 可用并准备好 dashboard 测试数据 ./risedev down ./risedev d dashboard ./risedev slt e2e_test/dashboard/create_graph.slt.part --label dashboard # 安装前端依赖并启动开发服务器默认端口 3000 pnpm install pnpm run dev开发服务器启动后访问http://localhost:3000/settings/将 API endpoint 设置为http://localhost:5691/api即可连接到运行中集群的 meta node。若要测试“静态文件内嵌于 meta node”的形态则执行./risedev configure enable dashboard此时由 meta node 在 5691 端口直接提供基于最新源码构建的 Dashboard。Dashboard 的关键页面包括fragment_graphFragment 执行图、relation_graph表/物化视图依赖图、await_tree、internal_tables、sinks等见 dashboard/pages。其中e2e_test/dashboard/create_graph.slt.parte2e_test/dashboard/create_graph.slt.part维护了包含多层 MV-on-MV 结构与 backpressure、lag 场景的专用测试数据用于验证渲染效果。Logging基于 tokio-tracing 的日志体系RisingWave 的 Rust 组件统一使用tokio-tracing同时承担日志与追踪二者共享同一套 instrumentation。日志初始化逻辑集中在 src/utils/runtime/src/logger.rs 的init_risingwave_logger中。默认日志级别默认情况下第三方库warn其他库RisingWave 自身 cratedebug这一默认策略在 logger.rs 的default_filter中体现外部依赖如hyper、tonic、reqwest、sqlx、aws等被显式设为WARN而 RisingWave 自己的 crate 依据部署环境取默认级别——CI 部署为INFOdebug 构建为DEBUG、release 构建为INFO。注意文档中的 “debug” 对应本地开发构建debug_assertions的默认值。用 RUST_LOG 动态调整日志级别要按模块调整日志级别启动时设置环境变量RUST_LOG即可语法遵循tracing-subscriber的EnvFilter格式支持targetlevel的逗号分隔列表。例如# 全局 info并单独把 streaming 模块与 events 目标提到 debug RUST_LOGinfo,risingwave_streamdebug,eventsdebug ./risingwave meta-nodelogger.rs 的实现会解析RUST_LOG并用其覆盖默认 filterRUST_LOG中的全局默认级别会替换默认级别而targetlevel规则会被叠加到默认规则之上。文档还提示在 release 构建中只有DEBUG及以下级别可能不会生效的部分需要注意——严格来说源码注释说明 “只有低于或等于DEBUG的级别在 release 构建中有效”logger.rs开发调试时建议使用 debug 构建。events:: 目标为调试而生的结构化日志有一类日志专门用于调试其 target 以events::开头。这类日志默认是关闭的default_filter中events被显式设为OFF见 logger.rs需要显式通过RUST_LOG打开。文档给出的经典示例# 打印流式引擎中所有经过 executor 的 chunk 消息 RUST_LOGevents::stream::message::chunktrace这条规则的底层实现在 src/stream/src/executor/wrapper/trace.rs每当一个Chunk消息流经被trace包裹的 executor 时会以target: events::stream::message::chunk发出 debug 事件并携带cardinality、capacity以及格式化的 chunk 内容chunk.to_pretty_with_schema。把级别设为trace即可让每条 chunk 消息在流经每个算子时都被完整记录。类似的调试目标还包括events::stream::message::watermark记录 watermark 的值与列索引和events::stream::message::barrier记录 barrier 的prev_epoch、curr_epoch、kind、mutation均定义在同一文件中trace.rs。仓库中还有大量其他events::目标例如src/common/src/hash/table_distribution.rs、src/storage/src/hummock/sstable/forward_sstable_iterator.rs、src/batch/src/task/task_manager.rs等可以在src/目录下搜索target: events::来发现更多可开启的调试日志点。更多日志相关环境变量源码 logger.rs 还记录了以下日志环境变量对日常排障同样有用ENABLE_PRETTY_LOG设为true时启用带行号、跨行展示 span 的 pretty 输出适合本地开发调试。官方建议配合关闭无关日志使用例如RUST_LOGrisingwave_storage::hummock::event_handleroff,batch_executeoff,risingwave_batch::taskoff ENABLE_PRETTY_LOGtrue risedev dRW_QUERY_LOG_PATH设置为一个目录后会把所有 SQL 写入query.log、把慢查询写入slow_query.log便于分析查询行为RW_QUERY_LOG_TRUNCATE_LEN可限制记录 SQL 的最大长度生产环境默认 1024。在risedev.yml的 profile 中也可以为整个集群统一注入环境变量例如env: RUST_LOG: info,risingwave_storage::hummockoff ENABLE_PRETTY_LOG: true这对应 risedevtool/src/config.rs 中ENABLE_PRETTY_LOG的注释说明。组合使用建议一套完整的本地排障工作流综合以上能力一个典型的“定位流式任务问题”工作流可以是编辑risedev.yml的defaultprofile依次取消prometheus、tempo、grafana三行注释必要时先./risedev configure下载 tempo 组件./risedev d启动开发集群访问http://127.0.0.1:5691/查看 Dashboard 中的 Fragment/Actor 拓扑用./risedev ctl --help探索risectl内部命令直接查看集群内部对象打开 Grafana在 Prometheus 数据源查看各节点指标在 Tempo 数据源查看流式 trace若需要更细粒度的消息级日志以 debug 构建配合RUST_LOGevents::stream::message::chunktrace或eventsdebug重启集群观察 chunk/watermark/barrier 在每个 executor 的流转细节。小结RisingWave 的开发可观测性由四层组成risectl集群内部控制面、Prometheus Grafana指标面、Tempotrace 面与 Dashboard运行时可视化面而tokio-tracing统一承载了日志与追踪两条链路。通过risedev.yml中的use:步骤即可按需组合启用通过RUST_LOG、ENABLE_PRETTY_LOG、RW_QUERY_LOG_PATH等环境变量可精细控制日志输出events::目标则提供了流式引擎消息级的调试窗口。掌握这套工具链即可在本地开发环境中对 RisingWave 集群实现从“宏观指标”到“单条消息”的全链路可观测。赞分享数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载相关推荐Windmill 可观测性实战基于 Tempo、Grafana、Prometheus 与 Loki 的 OpenTelemetry 链路追踪与日志监控Windmill 可观测性实战基于 Tempo、Grafana、Prometheus 与 Loki 的 OpenTelemetry 链路追踪与日志监控 导读后端工作流自动化任务调度低代码前端Hindsight 可观测性完全指南Prometheus 指标、OpenTelemetry 链路追踪与 Grafana 监控面板实战Hindsight 可观测性完全指南Prometheus 指标、OpenTelemetry 链路追踪与 Grafana 监控面板实战 Hindsight 是一人工智能AI AgentAgent 记忆MCP 服务Istio可观测性监控、追踪与日志集成Istio可观测性监控、追踪与日志集成 本文全面介绍了Istio服务网格的可观测性能力重点阐述了分布式追踪与OpenTelemetry的集成、指标收集与Pr服务网格云原生微服务网络负载均衡可观测性上一篇Kinesalite性能优化内存存储与持久化存储的对比分析下一篇Virtual Router终极指南Windows免费WiFi热点一键搞定创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考