可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载本篇基于 Highlight 官方更新日志 Changelog 283/6围绕三个核心主题展开错误页主动关联的 Related Resources 面板、搜索查询语法在空白符处理上的演进以及日志与 Trace 之间通过traceId建立的双向关联。读完本文你将理解这三项功能在产品层面的价值并能从仓库源码中找到对应的前端组件结构、ANTLR 语法规则与 ClickHouse 存储实现从而掌握 Highlight 如何将会话Sessions、错误Errors、日志Logs与分布式追踪Traces串联成完整的可观测性闭环。一、Related Resources让错误排查主动发现关联资源Changelog 28 首先介绍的理念是No error takes place in a vacuum没有错误是孤立发生的。Highlight 的架构建立在把 sessions、errors、logs、traces 全部连接起来的概念之上而本版本将这种连接方式从被动变成了主动当你在调查某个错误时界面上会直接出现指向相关会话、日志和 Trace 的按钮若按钮处于可点击状态即可一键跳转到关联资源深入挖掘错误成因。同样的关联按钮也出现在 Session Replay 页面上Traces 页面则提供了回跳对应会话的链接。前端实现RelatedResources 组件族从源码结构看这一功能由前端frontend/src/components/RelatedResources/目录下的组件族支撑各面板按资源类型分工RelatedResourcePanel.tsx 统一聚合 Error、Session、Trace、Logs 等面板ErrorPanel.tsx、SessionPanel.tsx、TracePanel.tsx、LogsPanel.tsx 分别对应文档提到的related sessions, logs, and traces按钮落地后的各类详情视图RelatedResourceList.tsx 与 ResourceTable.tsx 负责在面板内列出多条关联资源供切换浏览面板骨架与头部交互则分别位于 Panel.tsx 和 PanelHeader.tsx。资源在 URL 中流转related_resource 参数机制关联跳转的核心状态管理在 hooks.ts 中实现可以确认以下实现细节资源类型枚举。RelatedResource是判别联合类型hooks.ts 第 80-88 行覆盖error/session/trace/logs/errors/sessions/traces/events八类与文档中按钮可点击时跳转查看关联资源的产品行为一一对应。URL 编码。当前资源被 JSON 序列化后以 Base64 编码写入 URL 的related_resource查询参数常量RELATED_RESOURCE_PARAM定义于 hooks.ts 第 91 行编码逻辑在set回调中通过btoaSafe(JSON.stringify(newResource))完成。这意味着关联面板的状态是深链接deep link——用户可以把带关联面板的页面直接分享给同事。嵌套跳转与返回。set方法中有一段专门的逻辑当新资源类型与当前资源不同且canGoBack未显式指定时自动标记canGoBack truehooks.ts 第 151-158 行。这就是文档所说层层点击下钻后仍能返回上层资源的实现基础。面板宽度持久化。面板宽度通过related-resource-panel-width键写入 localStorage第 90、93-96 行刷新后保留用户调整过的布局。二、搜索查询演进空白符进入 HIDDEN 通道Changelog 28 指出搜索是一个庞大的问题域本版本做了四项持续改进语法解析中不再跳过空白符whitespace而是将其推入一个隐藏通道hidden channel使词法器lexer仍然能产出空白符 token更新了过滤器视觉标签visual tags的生成逻辑在解析器无法把输入切分为独立表达式的前提下改善分组的视觉呈现把错误提示区域移动到搜索输入框上方造成错误的 token 现在会以红色背景高亮显示。语法规则WS 通道的 channel(HIDDEN) 指令第一条改进在仓库根目录的 ANTLR 语法文件 SearchGrammar.g4 中有清晰落点。该语法定义了搜索查询的完整结构search_query入口规则第 4-7 行允许可选的空查询search_expr规则第 24-33 行支持括号分组、NOT取反、显式AND/OR、隐式ANDimplicit_and_op第 43-45 行、key op value键值表达式bin_op支持 ! : !等运算符第 60-63 行以及EXISTS操作符。关键的空白符处理位于文件末尾第 89-94 行fragment WHITESPACE : [ \t\n\r\f] ; WS : WHITESPACE - channel(HIDDEN) ; // Handle characters which failed to match any other token. This ensures all // characters are tokenized. ERROR_CHARACTERS : . ;WS : WHITESPACE - channel(HIDDEN)正是文档中push it to a hidden channel的直接体现词法器依旧为连续空白符产出WStoken但该 token 被分配到 HIDDEN 通道主解析通道DEFAULT中看不到它语法匹配因此不受干扰。这种写法相对传统的skip指令的优势在于——解析器上层仍然可以从 token 流中拿到空白符的精确位置信息这为文档第 2、4 条改进更好的分组视觉标签、出错 token 精确定位并标红提供了词法层面的基础只有每个空白符都有 token 且带位置信息前端才能准确计算每个 token 的起止坐标来绘制高亮与红色背景。配套地ERROR_CHARACTERS : . ;规则第 94 行兜底匹配任何未被其他规则覆盖的字符保证所有字符都被 tokenize——这也是出错 token 可以被红底高亮这一体验的前提任何一个非法字符都能对应到一个有坐标的 token而不是直接丢失在词法阶段。语法到前端解析器的生成链路仓库中存在两份该语法的产物可以印证生成链路antlr/SearchGrammar.g4 是语法的源头定义frontend/parser/src/components/Search/Parser/ 目录下包含 ANTLR 生成的 Go 解析器代码searchgrammar_lexer.go、searchgrammar_parser.go、searchgrammar_listener.go、searchgrammar_base_listener.go以及词法/解析元数据文件SearchGrammarLexer.tokens、SearchGrammarParser.tokens、SearchGrammar.interp、SearchGrammarLexer.interp。从源码结构看前端搜索框的实时语法检查正是基于这套生成解析器实现的用户在搜索框输入过滤条件时词法与解析错误被捕获并映射回 token 位置从而驱动文档所述错误显示在输入框上方、出错 token 标红的 UI 行为。三、日志与 Trace 的闭环为日志打上 traceIdChangelog 28 的第三项更新解释了日志与追踪之间的关联机制Highlight 系统在代码路径中实例化的每个新 span 都会携带一个traceId该 ID 帮助把一个 span 关联到其生命周期内发生的所有活动尤其是子 span 的创建本版本起日志也会被就近打上所属的traceId标签closing the loop闭上这个环即完成日志与 Trace 之间的双向关联。traceId 在存储层的落点在后端 ClickHouse 访问层中可以确认 traceId 的核心角色trace_row.go 提供WithTraceId方法TraceRow结构以TraceId字段承载该值traces.go 第 521 行有一处注释Doing this in code rather than Clickhouse so Clickhouse will use thetraceIdprojection——说明 Trace 查询刻意在应用层组织以便 ClickHouse 命中以traceId为键的投影projection保证按 traceId 检索时的查询性能errors.go 中错误行同样携带TraceID字段与日志、span 使用同一 ID 空间这正是文档所说连接 sessions, errors, logs, and traces的数据基础。按 trace_id 检索日志的查询能力日志侧的trace_id字段已被完整纳入搜索索引。logs_test.go 中的测试用例验证了多种查询形态均可正确解析并执行trace_id: no_match, // 精确等值匹配 Query: trace_id:match, // 冒号键值语法 Query: trace_id:*atc*, // 通配符模糊匹配 Query: trace_id:no_match, Query: trace_id:(match OR another), // 括号分组 OR此外sessions.go 中的字段映射表把trace_id映射到 ClickHouse 列TraceID说明会话维度同样可以按 traceId 检索。GraphQL 接口ExistingLogsTraces 反查除了由日志查 Trace系统还支持反向验证。私有 GraphQL API 中定义了ExistingLogsTraces查询其 resolver 位于 schema.resolvers.gofunc (r *queryResolver) ExistingLogsTraces(ctx context.Context, projectID int, traceIds []string, dateRange modelInputs.DateRangeRequiredInput) ([]string, error) { // ... return r.ClickhouseClient.ExistingTraceIds(ctx, project.ID, traceIds, dateRange.StartDate, dateRange.EndDate) }该接口接收一批traceIds与日期范围返回在日志表中真实存在的那些 traceId 子集用于前端判断哪些 Trace 有对应日志可关联——这与 Related Resources 面板按钮是否为激活态的交互逻辑相互呼应只有确实存在关联数据时按钮才可点击。小结三项更新如何共同构成可观测性闭环Changelog 28 的三项更新并非孤立功能而是同一条产品主线的三个侧面更新项产品价值仓库中的实现证据Related Resources调查错误时主动暴露关联的 sessions/logs/traces可下钻可返回frontend/src/components/RelatedResources/ 组件族与related_resource深链接机制Search query evolution空白符保留为 HIDDEN 通道 token、分组视觉标签改进、错误前置显示、出错 token 标红antlr/SearchGrammar.g4 与 frontend/parser 生成解析器Relate logs back to traces日志打上最近 span 的traceId日志与 Trace 双向可查trace_row.go、logs_test.go 与ExistingLogsTracesresolver对于使用者而言可以直接利用的能力包括在错误详情页点击 Related Resources 面板中的关联按钮跨资源下钻在搜索框中以trace_id:xxx、trace_id:*xxx*或trace_id:(a OR b)语法按追踪 ID 检索日志以及通过 URL 中携带related_resource参数的深链接与他人共享特定的排查上下文。需要注意的是以上机制均以当前仓库代码为准隐藏通道方案依赖 ANTLR 的channel(HIDDEN)指令与ERROR_CHARACTERS兜底规则配合日志按 traceId 关联依赖采集链路中 span 与日志的时序就近匹配实际行为可能随版本演进继续调整如搜索能力文档所述团队仍在持续攻克搜索这一庞大问题域。赞分享可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载相关推荐90分钟跑通基于arduino-esp32的ESP32超声波避障小车完整构建90分钟跑通基于arduino esp32的ESP32超声波避障小车完整构建 本文以 arduino esp32 核心为基础在 ESP32 DevKitC嵌入式物联网驱动开发终极指南如何快速修复Android设备Play Integrity验证问题终极指南如何快速修复Android设备Play Integrity验证问题 PlayIntegrityFix是一款专为Root用户设计的开源工具能够有效解决移动开发系统编程应用安全跑通一份赛后分析报告全流程用 gpt-computer-assistant 搭建 AI 体育分析系统跑通一份赛后分析报告全流程用 gpt computer assistant 搭建 AI 体育分析系统 这篇文章带你用一个下午用 gpt computer a人工智能大模型AI AgentAgent 框架自主智能体工具调用RAGAgent 记忆Agent 编排上一篇如何用Paged.js实现专业级文档分页完整实践指南下一篇终极指南如何用SuperImage在手机上实现8倍AI图像超分辨率增强创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载本篇基于 Highlight 官方更新日志 Changelog 283/6围绕三个核心主题展开错误页主动关联的 Related Resources 面板、搜索查询语法在空白符处理上的演进以及日志与 Trace 之间通过traceId建立的双向关联。读完本文你将理解这三项功能在产品层面的价值并能从仓库源码中找到对应的前端组件结构、ANTLR 语法规则与 ClickHouse 存储实现从而掌握 Highlight 如何将会话Sessions、错误Errors、日志Logs与分布式追踪Traces串联成完整的可观测性闭环。一、Related Resources让错误排查主动发现关联资源Changelog 28 首先介绍的理念是No error takes place in a vacuum没有错误是孤立发生的。Highlight 的架构建立在把 sessions、errors、logs、traces 全部连接起来的概念之上而本版本将这种连接方式从被动变成了主动当你在调查某个错误时界面上会直接出现指向相关会话、日志和 Trace 的按钮若按钮处于可点击状态即可一键跳转到关联资源深入挖掘错误成因。同样的关联按钮也出现在 Session Replay 页面上Traces 页面则提供了回跳对应会话的链接。前端实现RelatedResources 组件族从源码结构看这一功能由前端frontend/src/components/RelatedResources/目录下的组件族支撑各面板按资源类型分工RelatedResourcePanel.tsx 统一聚合 Error、Session、Trace、Logs 等面板ErrorPanel.tsx、SessionPanel.tsx、TracePanel.tsx、LogsPanel.tsx 分别对应文档提到的related sessions, logs, and traces按钮落地后的各类详情视图RelatedResourceList.tsx 与 ResourceTable.tsx 负责在面板内列出多条关联资源供切换浏览面板骨架与头部交互则分别位于 Panel.tsx 和 PanelHeader.tsx。资源在 URL 中流转related_resource 参数机制关联跳转的核心状态管理在 hooks.ts 中实现可以确认以下实现细节资源类型枚举。RelatedResource是判别联合类型hooks.ts 第 80-88 行覆盖error/session/trace/logs/errors/sessions/traces/events八类与文档中按钮可点击时跳转查看关联资源的产品行为一一对应。URL 编码。当前资源被 JSON 序列化后以 Base64 编码写入 URL 的related_resource查询参数常量RELATED_RESOURCE_PARAM定义于 hooks.ts 第 91 行编码逻辑在set回调中通过btoaSafe(JSON.stringify(newResource))完成。这意味着关联面板的状态是深链接deep link——用户可以把带关联面板的页面直接分享给同事。嵌套跳转与返回。set方法中有一段专门的逻辑当新资源类型与当前资源不同且canGoBack未显式指定时自动标记canGoBack truehooks.ts 第 151-158 行。这就是文档所说层层点击下钻后仍能返回上层资源的实现基础。面板宽度持久化。面板宽度通过related-resource-panel-width键写入 localStorage第 90、93-96 行刷新后保留用户调整过的布局。二、搜索查询演进空白符进入 HIDDEN 通道Changelog 28 指出搜索是一个庞大的问题域本版本做了四项持续改进语法解析中不再跳过空白符whitespace而是将其推入一个隐藏通道hidden channel使词法器lexer仍然能产出空白符 token更新了过滤器视觉标签visual tags的生成逻辑在解析器无法把输入切分为独立表达式的前提下改善分组的视觉呈现把错误提示区域移动到搜索输入框上方造成错误的 token 现在会以红色背景高亮显示。语法规则WS 通道的 channel(HIDDEN) 指令第一条改进在仓库根目录的 ANTLR 语法文件 SearchGrammar.g4 中有清晰落点。该语法定义了搜索查询的完整结构search_query入口规则第 4-7 行允许可选的空查询search_expr规则第 24-33 行支持括号分组、NOT取反、显式AND/OR、隐式ANDimplicit_and_op第 43-45 行、key op value键值表达式bin_op支持 ! : !等运算符第 60-63 行以及EXISTS操作符。关键的空白符处理位于文件末尾第 89-94 行fragment WHITESPACE : [ \t\n\r\f] ; WS : WHITESPACE - channel(HIDDEN) ; // Handle characters which failed to match any other token. This ensures all // characters are tokenized. ERROR_CHARACTERS : . ;WS : WHITESPACE - channel(HIDDEN)正是文档中push it to a hidden channel的直接体现词法器依旧为连续空白符产出WStoken但该 token 被分配到 HIDDEN 通道主解析通道DEFAULT中看不到它语法匹配因此不受干扰。这种写法相对传统的skip指令的优势在于——解析器上层仍然可以从 token 流中拿到空白符的精确位置信息这为文档第 2、4 条改进更好的分组视觉标签、出错 token 精确定位并标红提供了词法层面的基础只有每个空白符都有 token 且带位置信息前端才能准确计算每个 token 的起止坐标来绘制高亮与红色背景。配套地ERROR_CHARACTERS : . ;规则第 94 行兜底匹配任何未被其他规则覆盖的字符保证所有字符都被 tokenize——这也是出错 token 可以被红底高亮这一体验的前提任何一个非法字符都能对应到一个有坐标的 token而不是直接丢失在词法阶段。语法到前端解析器的生成链路仓库中存在两份该语法的产物可以印证生成链路antlr/SearchGrammar.g4 是语法的源头定义frontend/parser/src/components/Search/Parser/ 目录下包含 ANTLR 生成的 Go 解析器代码searchgrammar_lexer.go、searchgrammar_parser.go、searchgrammar_listener.go、searchgrammar_base_listener.go以及词法/解析元数据文件SearchGrammarLexer.tokens、SearchGrammarParser.tokens、SearchGrammar.interp、SearchGrammarLexer.interp。从源码结构看前端搜索框的实时语法检查正是基于这套生成解析器实现的用户在搜索框输入过滤条件时词法与解析错误被捕获并映射回 token 位置从而驱动文档所述错误显示在输入框上方、出错 token 标红的 UI 行为。三、日志与 Trace 的闭环为日志打上 traceIdChangelog 28 的第三项更新解释了日志与追踪之间的关联机制Highlight 系统在代码路径中实例化的每个新 span 都会携带一个traceId该 ID 帮助把一个 span 关联到其生命周期内发生的所有活动尤其是子 span 的创建本版本起日志也会被就近打上所属的traceId标签closing the loop闭上这个环即完成日志与 Trace 之间的双向关联。traceId 在存储层的落点在后端 ClickHouse 访问层中可以确认 traceId 的核心角色trace_row.go 提供WithTraceId方法TraceRow结构以TraceId字段承载该值traces.go 第 521 行有一处注释Doing this in code rather than Clickhouse so Clickhouse will use thetraceIdprojection——说明 Trace 查询刻意在应用层组织以便 ClickHouse 命中以traceId为键的投影projection保证按 traceId 检索时的查询性能errors.go 中错误行同样携带TraceID字段与日志、span 使用同一 ID 空间这正是文档所说连接 sessions, errors, logs, and traces的数据基础。按 trace_id 检索日志的查询能力日志侧的trace_id字段已被完整纳入搜索索引。logs_test.go 中的测试用例验证了多种查询形态均可正确解析并执行trace_id: no_match, // 精确等值匹配 Query: trace_id:match, // 冒号键值语法 Query: trace_id:*atc*, // 通配符模糊匹配 Query: trace_id:no_match, Query: trace_id:(match OR another), // 括号分组 OR此外sessions.go 中的字段映射表把trace_id映射到 ClickHouse 列TraceID说明会话维度同样可以按 traceId 检索。GraphQL 接口ExistingLogsTraces 反查除了由日志查 Trace系统还支持反向验证。私有 GraphQL API 中定义了ExistingLogsTraces查询其 resolver 位于 schema.resolvers.gofunc (r *queryResolver) ExistingLogsTraces(ctx context.Context, projectID int, traceIds []string, dateRange modelInputs.DateRangeRequiredInput) ([]string, error) { // ... return r.ClickhouseClient.ExistingTraceIds(ctx, project.ID, traceIds, dateRange.StartDate, dateRange.EndDate) }该接口接收一批traceIds与日期范围返回在日志表中真实存在的那些 traceId 子集用于前端判断哪些 Trace 有对应日志可关联——这与 Related Resources 面板按钮是否为激活态的交互逻辑相互呼应只有确实存在关联数据时按钮才可点击。小结三项更新如何共同构成可观测性闭环Changelog 28 的三项更新并非孤立功能而是同一条产品主线的三个侧面更新项产品价值仓库中的实现证据Related Resources调查错误时主动暴露关联的 sessions/logs/traces可下钻可返回frontend/src/components/RelatedResources/ 组件族与related_resource深链接机制Search query evolution空白符保留为 HIDDEN 通道 token、分组视觉标签改进、错误前置显示、出错 token 标红antlr/SearchGrammar.g4 与 frontend/parser 生成解析器Relate logs back to traces日志打上最近 span 的traceId日志与 Trace 双向可查trace_row.go、logs_test.go 与ExistingLogsTracesresolver对于使用者而言可以直接利用的能力包括在错误详情页点击 Related Resources 面板中的关联按钮跨资源下钻在搜索框中以trace_id:xxx、trace_id:*xxx*或trace_id:(a OR b)语法按追踪 ID 检索日志以及通过 URL 中携带related_resource参数的深链接与他人共享特定的排查上下文。需要注意的是以上机制均以当前仓库代码为准隐藏通道方案依赖 ANTLR 的channel(HIDDEN)指令与ERROR_CHARACTERS兜底规则配合日志按 traceId 关联依赖采集链路中 span 与日志的时序就近匹配实际行为可能随版本演进继续调整如搜索能力文档所述团队仍在持续攻克搜索这一庞大问题域。赞分享可观测性后端【免费下载链接】highlighthighlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.项目地址https://gitcode.com/gh_mirrors/hi/highlight点击查看免费下载相关推荐90分钟跑通基于arduino-esp32的ESP32超声波避障小车完整构建90分钟跑通基于arduino esp32的ESP32超声波避障小车完整构建 本文以 arduino esp32 核心为基础在 ESP32 DevKitC嵌入式物联网驱动开发终极指南如何快速修复Android设备Play Integrity验证问题终极指南如何快速修复Android设备Play Integrity验证问题 PlayIntegrityFix是一款专为Root用户设计的开源工具能够有效解决移动开发系统编程应用安全跑通一份赛后分析报告全流程用 gpt-computer-assistant 搭建 AI 体育分析系统跑通一份赛后分析报告全流程用 gpt computer assistant 搭建 AI 体育分析系统 这篇文章带你用一个下午用 gpt computer a人工智能大模型AI AgentAgent 框架自主智能体工具调用RAGAgent 记忆Agent 编排上一篇如何用Paged.js实现专业级文档分页完整实践指南下一篇终极指南如何用SuperImage在手机上实现8倍AI图像超分辨率增强创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
