• [技术干货] 直播分享|TinyRobot助你一站式搞定AI界面开发
    OpenTiny NEXT 前端智能化系列直播 ——第五期带你了解TinRobot,讲师将带来《TinyRobot助你一站式搞定AI界面开发》的主题分享。AI应用落地日趋广泛,智能交互产品形态愈发多元,市面通用开发组件难以契合AI交互特质,开发效率与适配效果存在短板,专属开发方案成为刚需。本次分享将介绍TinyRobot组件库定位,展示完整AI界面效果,实操搭建页面并讲解场景扩展能力,带你一站式完成AI界面开发。全程干货、可落地、可实战,更有一手课程资料、贡献者证书、AtomGit & OpenTiny 周边好礼等你来拿!主题:TinyRobot助你一站式搞定AI界面开发时间:05/26(周二) 19:00-20:00 (UTC+08:00)Beijing更多精彩活动1.评论区提问赢好礼,专家现场解答每期直播开始前,前往AtomGit 活动帖评论区提问,围绕本期直播主题与 AI 前端技术发布你的问题,即可参与!活动评论区:cid:link_02.实战出真知,OpenTiny 前端智能化实践营本次 OpenTiny NEXT 系列直播每期配套专属实战任务,让你边学边练、学完即用,真正把 AI 前端技术落地掌握。你只需在 AtomGit 平台关注并 Star OpenTiny 组织,Fork 对应仓库,根据直播内容完成实践任务,提交你的代码 PR,即可参与活动。所有提交的作品将由专业团队评审,优质实践作品将获得 AtomGit & OpenTiny 定制周边奖励,优秀 PR 还会被合并进 OpenTiny 官方仓库,成为开源贡献者,获得贡献者证书,为你的技术履历加分。AtomGit 地址:cid:link_23.参与征文有奖活动期间参与 OpenTiny NEXT 前端智能化系列征文活动,无论你是直播学习者、技术爱好者,还是开源实践者,均可围绕 AI 前端、WebMCP、WebAgent、TinyVue、TinyEngine、GenUI 、TinyRobot、AI Extension等相关技术与实战体验进行创作。征文活动:cid:link_1参与&领奖进群提前锁定福利+免费领取课程资料(见海报下方)仅有效提问、issue、PR、投稿可参与活动,灌水等无意义内容将取消活动资格本次活动解释权归 OpenTiny 团队和 AtomGit 平台所有  
  • [技术干货] ClkLog埋点分析系统信创版:面向国产化环境的用户行为分析方案(基于Apache Doris)
    【ClkLog 信创版本】正式发布!在越来越多企业推进信创改造的过程中,一个现实问题正在逐渐显现:业务系统可以完成国产化替代,但“数据分析能力”却往往难以同步落地。尤其是用户行为分析系统这类对实时性、分析能力、数据安全要求较高的平台,在信创环境中的适配难度远高于普通业务系统。 基于这一背景,ClkLog 正式推出信创版本。ClkLog 信创版面向国产化基础设施环境设计,支持私有化部署与源码交付,可运行于国产操作系统环境,并基于Apache Doris构建行为分析能力,为企业提供一套可落地的用户行为分析方案。  一、为什么“埋点用户分析系统”在信创场景中更难落地?相比普通业务系统,用户行为分析系统通常具有数据量大、 写入频繁 、 查询维度复杂 、 分析模型较多、 对实时分析要求较高的特点。在实际项目中,常见问题主要集中在以下几个方面。1.  SaaS模式难以适配实际需求很多团队早期使用的是 SaaS 类分析产品,但在信创推进过程中,逐渐会面临数据无法本地化、难以适配国产化环境以及无法满足内网部署等问题。对于政企及高安全要求行业而言,用户行为数据通常需要在本地完成采集、存储与分析,因此私有化部署正逐渐成为刚性需求。 2.  原有分析系统无法继续使用部分企业此前已经建设过埋点分析体系,但随着国产化环境建设推,原有系统可能会面临: 基础技术栈不兼容、部分组件缺少国产化适配 、运维体系难以迁移 、 数据链路无法满足当前要求,最终导致企业只能重新选型,甚至重建整套分析体系。 3.  行为分析系统本身对底层能力要求更高用户行为分析并不仅仅是“数据存储”。实际场景中,通常会涉及多维事件分析、漏斗分析、用户标签与画像、用户分群、实时或近实时查询等。这意味着底层分析引擎不仅需要具备大规模数据处理能力,还需要兼顾复杂查询性能与扩展能力。 基于这些场景,让我们意识到:在信创场景下,用户行为分析系统必须从一开始就按“可私有化、可适配”的方式来设计。这也是ClkLog推出信创版本的出发点。 二、ClkLog信创方案优势在设计信创版本时,我们围绕可适配、可落地、可持续使用三个方向进行优化: 1.  架构层:支持国产化环境部署ClkLog 采用分层解耦架构设计,采集、处理、存储与分析模块可独立部署。在信创场景下,系统可部署于国产操作系统环境(麒麟等),并支持私有化部署模式,满足企业对本地化运行与数据可控性的要求。 2.  分析引擎:基于 Apache Doris 构建在分析引擎选型过程中,我们重点评估了行为分析场景数据的特征:一方面数据量大、写入频繁、查询维度多、分析路径复杂,另一方面,在实际使用中,分需需求往往是:○ 多条件/多维度组合查询○ 实时或近实时查询○ 路径分析、漏斗分析等复杂计算由于Apache Doris在实时分析、列式存储、多维聚合查询等方面具备较好的性能特点,同时也具备良好的国产化环境适配能力,能够满足用户行为分析场景中的复杂分析需求,最终,ClkLog 信创版选择基于 Apache Doris 构建核心分析能力。 3.  分析能力:延续成熟模型,而不是“从零开始”在功能层面,ClkLog信创版本延续CDP企业版的完整能力体系,包括:○ 基础访问分析○ 多维事件分析/漏斗○ 用户标签/画像/细查○ 用户分群/群画像对比企业在推进信创建设的同时,依然能够保留完整的数据分析能力体系。  三、信创场景下,不同方案的差异在信创场景下,不同类型的方案,在部署方式、适配能力与实施成本上可适配性、数据安全与分析能力上的差异非常明显。以下对比基于实际项目中的典型方案整理:  四、ClkLog信创方案适用场景ClkLog 信创版本适用于以下类型的需求场景:✓ 正在推进信创方案选型的企业✓ 对数据安全、私有化部署有要求的企业✓ 希望构建自有用户行为分析体系的团队✓ 需要兼顾分析能力与国产化适配的项目场景  在信创趋势下,数据平台的国产化不仅仅是“替换组件”,更重要的是——分析能力本身不能缺失。用户行为分析作为连接产品、运营与用户的重要能力,也需要有一套真正能够落地的国产化实现方案。ClkLog信创版本,正是我们在这一方向上的一次实践。如果您正在关注用户行为分析系统的国产化建设,或对用户行为分析系统的国产化方案感兴趣,欢迎与小秘书进行交流。
  • [热门活动] 2026 OpenTiny NEXT 产品调研启动!
    各位开发者朋友们!OpenTiny NEXT 系列产品(NEXT SDK / TinyRobot / GenUI SDK / AI Extension / WebAgent 等)已陪伴大家走过一段时间。为了更精准地解决实际开发中的痛点,我们正式启动 2026 年度用户体验调研。⏰ 调研时间: 即日起至 2026年6月15日🎯 面向对象: 正在使用或曾使用过 OpenTiny NEXT 的开发者🎁 参与福利: 完成问卷的用户将有机会获得 OpenTiny 定制周边🔗 立即参与: cid:link_0💬 反馈直达: 填写后如有补充,欢迎 @OpenTiny小助手或在本帖留言每一条反馈都会进入产品需求池,直接影响后续版本规划。期待听到你的真实声音!
  • [技术干货] 在信创环境下,如何判断一套用户行为分析系统是否“真正可用”?
    某国企在选型用户行为分析系统时,遇到了一个很现实的问题:几家厂商都表示“支持信创”,系统也确实可以运行在国产操作系统之上。但当进一步深入询问时:● 是否支持内网环境的独立部署? ● 是否可以适配国产数据库方案? ● 数据从采集到分析,是否具备可追踪与审计能力? 很多方案开始变得不那么清晰。这其实是信创选型中一个非常典型的现象:在信创环境下,系统“能运行”,只是起点,而不是判断标准。  一、什么是信创?从实践角度看,信创的核心在于:在关键基础设施中,实现软硬件体系的自主可控与国产化适配,确保系统在安全、供应链和运维层面具备长期可持续性。因此,信创关注的并不仅是“能否运行”,而是:● 是否具备自主可控能力● 是否适配国产软硬件生态● 是否满足安全与合规要求  二、如何理解“适配信创”的系统?在实际选型中,一个常见误区是:能在国产环境运行 ≠ 适配信创结合项目经验,一套更具可落地性的判断思路,可以从以下几个方面来看: 1. 是否具备独立运行能力不仅是“可以部署”,更重要的是:✧ 支持在内网环境中独立运行✧ 不依赖外部云服务✧ 出现问题时,具备本地可排查、可定位能力 这决定了系统在封闭环境中的可用性与稳定性。 2. 是否适配国产技术生态信创环境下,技术选型往往受到约束,例如数据库、中间件等。更现实的要求是:✧ 能够适配主流国产数据库与中间件✧ 架构上具备一定灵活性,避免强绑定单一技术栈 ✧ 在替换底层组件时,不需要大规模重构业务能力✧ 支持随着国产生态变化进行持续适配,而不是一次性适配 以分析型数据库为例,像 Apache Doris 这类引擎可以作为分析层的一种选择,但在信创环境中,往往还需要结合具体国产数据库生态进行整体设计。 3. 数据链路是否可观测、可审计用户行为分析系统,本质是一条完整的数据链路:采集 → 传输 → 存储 → 分析 在信创场景下,更关注的是:✧ 数据来源是否清晰 ✧ 数据流转是否可追踪 ✧ 数据使用是否可审计 ✧ 在业务规则变化时,链路结构是否可以调整(如新增采集点/调整分析维度) 也就是说,不仅要“能看结果”,还需要对关键数据链路具备可控性与透明度。  三、为什么在用户行为分析场景中更容易出现问题?相比单点工具,用户行为分析系统涉及多个环节协同:数据采集(SDK / 埋点)、数据传输、数据存储、数据分析 在一些以云为中心设计的系统中,常见情况包括:● 采集在本地,但分析依赖云端能力 ● 数据可以使用,但链路不够透明 ● 在特定环境中可用,但迁移后成本较高  在信创环境下,这些问题会被进一步放大。  四、一个更可落地的判断方式从选型角度,可以用更务实的标准来评估系统:1)  数据是否运行在自身可控的体系内2)  系统架构是否具备一定的可调整与适配能力3)  在环境变化(如国产化替换)时,核心分析能力是否仍然可用 4)  系统是否具备开放性与可持续演进能力。 开放性 + 可定制能力 + 可持续演进能力,往往比功能本身更重要。能够满足这些条件的系统,通常更容易在信创环境中长期稳定运行  五、为什么部分系统难以满足这些要求?这与系统的设计起点密切相关。不少用户行为分析产品最初是围绕云化场景构建的:● 强依赖云端计算与服务能力 ● 技术栈相对固定 ● 数据链路相对封闭  而信创环境,更强调:本地化部署能力 + 架构可控性 + 技术生态适配能力 这两种设计思路之间,天然存在一定差异。 六、换个角度看选型问题在信创环境中选择用户行为分析系统,本质上是在判断:这套系统,是否能够在既定技术约束下,长期稳定运行,并始终支持业务变化下的持续调整能力。这不仅是产品能力问题,也是架构设计问题。  七、一种实践思路(以 ClkLog 为例)以 ClkLog 的设计思路为例,其关注点不局限于单一分析功能,而是围绕用户行为数据的完整链路进行设计:✓ 数据从采集到分析全链路本地化部署,可在信创环境中独立运行 ✓ 在架构上支持适配多种数据库方案,可根据国产化要求灵活替换适配✓ 分析模型与底层环境解耦,在系统迁移或升级时可降低调整成本✓ 产品采用开放架构设计,支持基于业务需求进行扩展与二次开发,实现长期业务演进能力 在强调“自主可控与国产化适配”的信创环境中,这类设计思路通常更容易落地。  结语在信创背景下,用户行为分析系统的选型标准,正在从“功能是否完善”,转向:系统是否真正可控、可适配、可持续运行,并具备随业务变化的持续演进能力。这也是判断一套系统能否长期支撑业务的关键。
  • [热门活动] OpenTiny NEXT前端智能化系列课分享即将火热来袭!敬请期待~
    OpenTiny NEXT前端智能化系列课分享即将火热来袭!敬请期待~ 
  • [获奖公告] OpenTiny 2025年度贡献者榜单正式公布~
     2025 年 OpenTiny 在开源领域不断扎根,共计发布 16 个大版本,累计修复 800+缺陷问题,新增代码 916000+行,共提交 2700+个 commits,感谢各位贡献者们!   
  • 2025年OpenTiny年度人气贡献者评选正式开始
    前言携手共创,致敬不凡!2025年,OpenTiny持续在前端开源领域扎根,每一位开发者都是推动项目共同前行的宝贵力量。从bug修复,到技术探讨;从参与开源活动,到输出技术文章;从使用项目,到参与共建,每一步跨越,都凝聚了开发者的智慧与汗水。致敬所有在OpenTiny社区里默默付出、积极贡献、引领创新的杰出个人,我们正式启动“OpenTiny年度贡献者评选”活动!快为你喜爱的人气贡献者投票吧~人气贡献者评选名单公布:年度贡献者投票评选时间:2025年12月25日-2025年12月31日投票规则:每人每天可回答3次,每次最多可投2票,最终投票结果选取前5名投票入口:cid:link_0关于OpenTiny欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~OpenTiny 官网:https://opentiny.designOpenTiny 代码仓库:https://github.com/opentinyTinyVue 源码:https://github.com/opentiny/tiny-vueTinyEngine 源码:https://github.com/opentiny/tiny-engine欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI~ 如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献~
  • [活动公告] 2025OpenTiny星光ShowTime!年度贡献者征集启动!
    前言携手共创,致敬不凡!2025年,OpenTiny持续在前端开源领域扎根,每一位开发者都是推动项目共同前行的宝贵力量。从bug修复,到技术探讨;从参与开源活动,到输出技术文章;从使用项目,到参与共建,每一步跨越,都凝聚了开发者的智慧与汗水。致敬所有在OpenTiny社区里默默付出、积极贡献、引领创新的杰出个人,我们正式启动“OpenTiny年度贡献者评选”活动!欢迎各位开发者踊跃报名~活动详情活动简介:本次活动主要是通过开发者申报+社区评选+开发者投票形式开展,入选开发者后续可获得相应活动礼品。本次活动一共设置 4 类奖项。“技术炼金师”(参与共建)、“布道魔法师”(参与分享)、“社区宝藏玩家”(参与社区讨论) 三个类目奖项通过投票评选获奖选手,本次投票共选出5名获奖选手,按照名次顺利依次给予相应奖励。“技术硬核奖”则由社区自主根据实际共建情况评选 2 位,获得机械键盘/蓝牙音响(2选1)及荣誉证书活动奖品:荣誉奖项礼品第一名技术炼金师布道魔法师社区宝藏玩家机械键盘 / 蓝牙音响(2选1) +荣誉证书第二名华为 66W 快充充电宝+荣誉证书第三名BKT 护腰坐垫椅+荣誉证书第四/五名屏幕挂灯+荣誉证书社区优秀共建者技术硬核奖机械键盘 / 蓝牙音响(2选1) +荣誉证书活动时间:年度贡献者征集时间:2025年12月17日-2025年12月24日年度贡献者投票评选时间:2025年12月25日-2025年12月31日报名入口:https://v.wjx.cn/vm/tdGJdjR.aspx#关于OpenTiny欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~OpenTiny 官网:https://opentiny.designOpenTiny 代码仓库:https://github.com/opentinyTinyVue 源码:https://github.com/opentiny/tiny-vueTinyEngine 源码: https://github.com/opentiny/tiny-engine欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~如果你也想要共建,可以进入代码仓库,找到 good first issue 标签,一起参与开源贡献~
  • 12月25日杭州,邀您莅临昇思人工智能框架峰会 | 现场实践大模型微调+轻量级部署,与大咖零距离交流!
    尊敬的开发者朋友:昇思人工智能框架峰会即将于12月25日在杭州国际博览中心盛大开启!我们特别为你准备了两大专属互动环节,助你深入技术核心,解决实战难题。扫码即刻报名,期待与你线下相见,共话AI框架未来!  
  • [分享交流] C++20协程框架分享
    引入协程背景有大量的异步业务逻辑, 传统的回调代码割裂, 可读性差, 不可避免的回调地狱简化编码复杂度,希望底层能够支持协程, 简化跨线程或者实现rpc的能力项目Github: CrystalNetCrystalNet支持C++20, 包括requires, 协程等特性协程框架是CrystalNet的一个底层支持协程源码路径:kernel/include/kernel/comp/Coroutines测试case: TestCoroutine.h/TestCoroutine.cpp TestPoller.h/TestPoller.cpp细节介绍封装一个通用的协程类template<typename T> class CoTask<T>封装一个阻塞等待类CoWaiter,并提供阻塞等待接口:CoTask<> Waiting(), 用于等待条件满足时唤醒协程设计封装了一个Poller,主要用于处理事件循环, 协程的suspend时候会向Poller抛异步任务调度协程, 直到在CoWaiting时永久阻塞CoTask提供GetParam让用户在协程阻塞时获取到协程句柄,方便用户在条件满足时通过协程句柄唤醒协程Poller提供SendAsync接口实现跨线程的通信(协程方式提供)// 跨线程协程消息(otherPoller也可以是自己) // req暂时只能传指针,而且会在otherChannel(可能不同线程)释放 // req/res 必须实现Release, ToString接口 template<typename ResType, typename ReqType> requires requires(ReqType req, ResType res) { // req/res必须有Release接口 req.Release(); res.Release(); // req/res必须有ToString接口 req.ToString(); res.ToString(); } CoTask<KERNEL_NS::SmartPtr<ResType, AutoDelMethods::Release>> SendToAsync(Poller &otherPoller, ReqType *req) { // 1.ptr用来回传ResType KERNEL_NS::SmartPtr<ResType *, KERNEL_NS::AutoDelMethods::CustomDelete> ptr(KERNEL_NS::KernelCastTo<ResType *>( kernel::KernelAllocMemory<KERNEL_NS::_Build::TL>(sizeof(ResType **)))); ptr.SetClosureDelegate([](void *p) { // 释放packet auto castP = KERNEL_NS::KernelCastTo<ResType*>(p); if(*castP) (*castP)->Release(); KERNEL_NS::KernelFreeMemory<KERNEL_NS::_Build::TL>(castP); }); *ptr = NULL; // 设置stub => ResType的事件回调 UInt64 stub = ++_maxStub; KERNEL_NS::SmartPtr<KERNEL_NS::TaskParamRefWrapper, KERNEL_NS::AutoDelMethods::Release> params = KERNEL_NS::TaskParamRefWrapper::NewThreadLocal_TaskParamRefWrapper(); SubscribeStubEvent(stub, [ptr, params](KERNEL_NS::StubPollerEvent *ev) mutable { KERNEL_NS::ObjectPollerEvent<ResType> *finalEv = KernelCastTo<KERNEL_NS::ObjectPollerEvent<ResType>>(ev); // 将结果带出去 *ptr = finalEv->_obj; finalEv->_obj = NULL; // 唤醒Waiter auto &coParam = params->_params; if(coParam && coParam->_handle) coParam->_handle->ForceAwake(); }); // 发送对象事件 ObjectPollerEvent到 other auto iterChannel = _targetPollerRefChannel.find(&otherPoller); if(LIKELY(iterChannel != _targetPollerRefChannel.end())) { auto objEvent = ObjectPollerEvent<ReqType>::New_ObjectPollerEvent(stub, false, this, iterChannel->second); objEvent->_obj = req; iterChannel->second->Send(objEvent); } else { auto objEvent = ObjectPollerEvent<ReqType>::New_ObjectPollerEvent(stub, false, this, nullptr); objEvent->_obj = req; otherPoller.Push(objEvent); } // 等待 ObjectPollerEvent 的返回消息唤醒 auto poller = this; // 外部如果协程销毁兜底销毁资源 auto releaseFun = [stub, poller]() { poller->UnSubscribeStubEvent(stub); }; auto delg = KERNEL_CREATE_CLOSURE_DELEGATE(releaseFun, void); co_await KERNEL_NS::Waiting().SetDisableSuspend().GetParam(params).SetRelease(delg); if(LIKELY(params->_params)) { auto &pa = params->_params; if(pa->_errCode != Status::Success) { g_Log->Warn(LOGFMT_OBJ_TAG("waiting err:%d, stub:%llu, req:%p") , pa->_errCode, stub, req); UnSubscribeStubEvent(stub); } // 销毁waiting协程 if(pa->_handle) pa->_handle->DestroyHandle(pa->_errCode); } // 3.将消息回调中的ResType引用设置成空 auto res = *ptr; *ptr = NULL; co_return KERNEL_NS::SmartPtr<ResType, KERNEL_NS::AutoDelMethods::Release>(res); } 提供异步化工具函数: PostCaller异步编码举例代码在测试用例:TestPoller, 示例中实现了co_await 请求一个req,并返回一个resclass TestTimeoutStartup : public KERNEL_NS::IThreadStartUp { POOL_CREATE_OBJ_DEFAULT_P1(IThreadStartUp, TestTimeoutStartup); public: TestTimeoutStartup(KERNEL_NS::LibEventLoopThread * target) : _target(target) { } virtual void Run() override { KERNEL_NS::PostCaller([this]() mutable -> KERNEL_NS::CoTask<> { auto targetPoller = co_await _target->GetPoller(); auto req = HelloWorldReq::New_HelloWorldReq(); auto res = co_await targetPoller->template SendAsync<HelloWorldRes, HelloWorldReq>(req).SetTimeout(KERNEL_NS::TimeSlice::FromSeconds(5)); g_Log->Info(LOGFMT_NON_OBJ_TAG(TestTimeoutStartup, "res return")); }); } virtual void Release() override { TestTimeoutStartup::Delete_TestTimeoutStartup(this); } KERNEL_NS::LibEventLoopThread * _target; };
  • [活动公告] 2025开放原子开发者大会——CANN异构计算专题分论坛
     扫码进群即可获取免费报名券和午餐券 
  • [活动公告] 11月15日,CANN Meetup 北京站,邀您共赴一场技术盛宴
    11月15日,CANN Meetup 北京站,邀您共赴一场技术盛宴
  • [问题求助] GaussDB监控采集报错:函数"pg_last_wal_receive_lsn()"不存在 (SQLSTATE 42883)
    技术大神们好,我在使用GaussDB时遇到一个监控采集方面的错误,特来求助。我的collector在尝试采集replication、replication_slot指标时失败了,报错信息如下:time=2025-09-05T09:34:16.375+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication duration_seconds=0.0711601 err="ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.674+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_replication ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.711+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_replication_slots ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.755+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.4515532 err="ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-11T15:33:59.609+08:00 level=ERROR source=gaussdb_exporter.go:684 msg="error scraping dsn" err="queryNamespaceMappings errors encountered, namespace: pg_stat_replication error: Error running query on database \"113.44.80.136:8000\": pg_stat_replication ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883), namespace: pg_replication_slots error: Error running query on database \"113.44.80.136:8000\": pg_replication_slots ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)" dsn="gaussdb://root:PASSWORD_REMOVED@113.44.80.136:8000/circle_test?sslmode=disable"相关SQL:SELECT *, (CASE pg_is_in_recovery () WHEN 't' THEN pg_last_wal_receive_lsn () ELSE pg_current_wal_lsn () END) AS pg_current_wal_lsn, ( CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), PG_LSN ('0/0')) :: FLOAT ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), PG_LSN ('0/0')) :: FLOAT END ) AS pg_current_wal_lsn_bytes, ( CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), replay_lsn) :: FLOAT ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), replay_lsn) :: FLOAT END ) AS pg_wal_lsn_diff FROM pg_stat_replication;SELECT slot_name, DATABASE, active, (CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), restart_lsn) ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), restart_lsn) END) AS pg_wal_lsn_diff FROM pg_replication_slots;SELECT slot_name, slot_type, CASE WHEN pg_is_in_recovery () THEN pg_last_wal_receive_lsn () - '0/0' ELSE pg_current_wal_lsn () - '0/0' END AS current_wal_lsn, 0 AS confirmed_flush_lsn, active FROM pg_replication_slots;错误提示很明确:SQL查询中引用了名为 pg_last_wal_receive_lsn() 的函数,但该函数在数据库系统中不存在。我想了解:问题根因:这是否是因为我的GaussDB版本(或特定模式)中,系统函数与监控工具期望的不一致?pg_last_wal_receive_lsn() 函数在当前版本的GaussDB中是否存在?这个函数是否是PostgreSQL特有的而非GaussDB的内置函数?解决方案:对于这类复制监控指标采集,GaussDB的正确实践是什么?是需要使用不同的系统函数,还是需要查询特定的系统视图来获取接收LSN信息?是否需要启用特定的复制监控功能或配置?版本差异:pg_last_wal_receive_lsn() 函数是否是某些PostgreSQL版本中特有的?我当前使用的GaussDB版本可能基于哪个PostgreSQL基础版本,以及GaussDB自身对此功能的支持情况如何?任何关于此问题的排查思路、系统函数差异说明或版本兼容性信息都将非常有帮助!感谢!背景信息/补充说明(可选):我使用的GaussDB版本是:gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是:Prometheus gaussdb_exporter希望得到大家的指点,谢谢!
  • [问题求助] GaussDB监控采集报错:pg_replication_slots表中列"wal_status"不存在 (SQLSTATE 42703)
    技术大神们好,我在使用GaussDB时遇到一个监控采集方面的错误,特来求助。我的collector在尝试采集replication_slot指标时失败了,报错信息如下:time=2025-09-17T10:45:23.325+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.6615468 err="ERROR: Column \"wal_status\" does not exist. (SQLSTATE 42703)"相关SQL:SELECT     slot_name,     slot_type,     0 AS current_wal_lsn,     0 AS confirmed_flush_lsn,     active,     0,     wal_status FROM pg_replication_slots;错误提示很明确:SQL查询中引用了名为 wal_status的列,但该列在目标表中不存在。我想了解:问题根因:这是否是因为我的GaussDB版本(或特定模式)中,系统视图或系统表的结构与采集工具期望的不一致?replication_slot相关的系统视图究竟是哪个?(例如是pg_replication_slots吗?)这个视图在当前版本的GaussDB中是否不包含 wal_status列?解决方案:对于这类监控指标采集,GaussDB的正确实践是什么?是需要查询不同的系统视图,还是需要启用特定的监控开关或配置?版本差异:wal_status列是否是某些更新版本中才加入的?我当前使用的GaussDB版本可能是什么?任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助!感谢!背景信息/补充说明(可选):我使用的GaussDB版本是:gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是:Prometheus gaussdb_exporter希望得到大家的指点,谢谢!
  • [问题求助] GaussDB监控采集报错:pg_replication_slots表中列"safe_wal_size"不存在 (SQLSTATE 42703)
    技术大神们好,我在使用GaussDB时遇到一个监控采集方面的错误,特来求助。我的collector在尝试采集replication_slot指标时失败了,报错信息如下:time=2025-09-17T10:17:36.080+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.8542995 err="ERROR: Column \"safe_wal_size\" does not exist. (SQLSTATE 42703)"相关SQL:SELECT slot_name, slot_type, 0 AS current_wal_lsn,   0 AS confirmed_flush_lsn, active, safe_wal_size, '' FROM pg_replication_slots;错误提示很明确:SQL查询中引用了名为 safe_wal_size的列,但该列在目标表中不存在。我想了解:问题根因:这是否是因为我的GaussDB版本(或特定模式)中,系统视图或系统表的结构与采集工具期望的不一致?replication_slot相关的系统视图究竟是哪个?(例如是pg_replication_slots吗?)这个视图在当前版本的GaussDB中是否不包含 safe_wal_size列?解决方案:对于这类监控指标采集,GaussDB的正确实践是什么?是需要查询不同的系统视图,还是需要启用特定的监控开关或配置?版本差异:safe_wal_size列是否是某些更新版本中才加入的?我当前使用的GaussDB版本可能是什么?任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助!感谢!背景信息/补充说明(可选):我使用的GaussDB版本是:gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是:Prometheus gaussdb_exporter希望得到大家的指点,谢谢!
总条数:124 到第
上滑加载中