Metabase Monitor 之 Erroring questions定位、排查与批量重跑出错问题【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase导读Erroring questions出错问题是 Metabase 管理监控Monitor模块中的一个专用页面它集中列出“最近一次运行返回了错误”的所有问题Question并展示错误信息、所属数据库与所在集合等关键线索。本文以 docs/monitor/erroring-questions.md 为骨架结合仓库内前端组件与后端审计查询的实现讲解该页面的打开方式、表格字段、搜索与批量重跑操作并深入到源码层解析它是如何从应用数据库聚合出出错问题清单的。注意Erroring questions 属于 Metabase 企业版EE功能对应{% include plans-blockquote.html featureErroring questions %}的标识需要商业版许可证或嵌入式许可证方可使用。一、功能概述一眼看到上次跑挂了的问题日常使用中问题/仪表盘出错往往分散在订阅通知、仪表盘刷新或手动查询等不同场景里。Erroring questions 页面把这些错误收敛到一个清单中凡是最后一次执行返回错误的问题都会出现在列表里管理员无需逐个打开问题排查即可直接定位故障面。该页面为用户展示的每一条出错问题包含三类核心信息文档明确列出的三要素错误信息Error message最近一次运行产生的错误文本摘要返回错误的数据库Database执行出错时所在的数据库包含该问题的集合Collection问题存放的集合便于按归属范围定位。二、如何打开 Erroring questions按文档操作路径打开 Monitor监控 页面在左侧边栏点击Erroring questions。在源码中该入口对应的页面组件为ErrorOverview位于 ErrorOverview.tsx路由挂在企业版 Monitor 的 routes.tsx 下。页面顶部使用MonitorHeaderTitle渲染 Erroring questions 标题主体由搜索框ErroringQuestionsSearch、结果表格ErroringQuestionsTable与分页控件PaginationControls组成。三、表格列比文档三要素更完整的诊断信息文档只强调了错误信息 / 数据库 / 集合三项而实际表格前端列定义见 ErroringQuestionsTable.tsx提供了更完整的诊断维度共 11 列列表头字段说明Questioncard_name问题名称点击行可跳转到问题详情页Errorerror_substr最近一次错误的文本摘要等宽字体展示Collectioncollection_name问题所属集合Databasedatabase_name出错时关联的数据库Schemaschema_name数据表所在 SchemaTabletable_name关联的数据表Last run atlast_run_at最近一次运行时间精确到分钟Total runstotal_runs累计运行次数Dashboards its innum_dashboards该问题被放入的仪表盘数量Created byuser_name问题创建者Updated atupdated_at问题最近更新时间从数据模型types.ts 中的ErroringCard可以看出每一行除文档提到的三要素外还携带schema_name、table_name、last_run_at、total_runs、num_dashboards、user_name、updated_at等字段方便判断挂了多少次、影响多少个仪表盘、最近一次运行时间。3.1 排序除Dashboards its in等少数列外大部分列都支持点击表头排序。可排序字段在SORT_COLUMNS中完整定义见 types.tscard_name, error_substr, collection_name, database_name, schema_name, table_name, last_run_at, total_runs, num_dashboards, user_name, updated_at默认排序为last_run_at倒序最新的出错问题排在最前定义于 utils.ts 的DEFAULT_SORTINGexport const DEFAULT_SORTING: ErroringQuestionsSorting { column: last_run_at, direction: desc, };3.2 分页页面采用每页 50 条的分页PAGE_SIZE 50见 utils.ts页码通过 URL query 参数?pageN维护。源码中还处理了一个边界情况当筛选条件变化导致结果集缩小、URL 中的页码越界时isStrandedPage会自动回退到第 0 页避免用户停留在空页面上。四、搜索按问题、错误、数据库或集合过滤文档说明可以按问题、错误、数据库或集合搜索。对应的搜索框组件在 ErroringQuestionsSearch.tsx输入框占位提示即为Search by question, error, database, or collection。实现细节上搜索输入采用**防抖debounce**机制SEARCH_DEBOUNCE_DURATION避免每次击键都触发一次查询请求搜索结果结合排序与分页实时更新列表。搜索关键字在表格里覆盖的范围由后端查询决定包括问题名称card.name、错误文本latest_qe.error、数据库名称db.name以及集合名称coll.name——与文档描述完全对应。五、检查修复效果批量重跑Rerun文档给出的核心操作是选中一个或多个问题并重新运行以检查错误是否已修复。这与前端 ErrorOverview.tsx 中handleRerunSelected的实现一致通过表格行前的复选框或表头全选选择要重跑的问题底部弹出批量操作栏BulkActionBar显示已选 N 个问题点击Rerun selected按钮对每个选中的卡片逐个调用useLazyGetCardQueryQuery即POST /api/card/:id/query在后台重新执行重跑期间对应行显示加载态且不可再次被选中isRowSelectable排除rerunningCardIds避免重复提交所有重跑结束后自动refetch()刷新列表已修复的问题会从列表中消失仍出错的问题继续保留——这正是文档所说检查是否已修复的落地机制。重跑请求采用 fire-and-forget 方式单个请求失败也不会中断其他问题的重跑.catch(() undefined)慢查询也不会阻塞用户继续选择其他问题排队重跑。六、源码纵深后端如何聚合出错问题清单前端页面本身不查业务数据库而是以内部查询internal query的方式调用企业版审计模块预定义的查询。在 utils.ts 的getErroringQuestionsQuery中可以看到{ type: internal, fn: metabase-enterprise.audit-app.pages.queries/bad-table, args: [search, column, direction], limit: PAGE_SIZE, offset: PAGE_SIZE * page, }其中bad-table的完整实现位于 enterprise/backend/src/metabase_enterprise/audit_app/pages/queries.clj定义在metabase-enterprise.audit-app.pages.queries命名空间并通过audit.i/internal-query多方法注册同时被 handle_audit_queries.clj 的中间件路由识别。其核心 SQL 逻辑HoneySQL 构建可以从源码中还原数据源以report_card问题卡片为主表左连接collection、metabase_database、metabase_table、core_user以及三个公共 CTE——query-runs运行记录计数、latest-qe最近一次查询执行记录、dashboards-count仪表盘引用计数过滤条件card.archived false只统计未归档问题latest_qe.error IS NOT NULL必须有最近一次执行记录且带错误——这正是上次运行出错的判定依据card.database_id ! audit-db-id排除元数据库审计数据库本身避免噪声错误摘要error_substr取latest_qe.error前 60 个字符并拼接...MySQL 与其它数据库的substring起始索引差异已做适配保证表格列不至于被完整错误堆栈撑爆统计列total_runs累计执行次数、num_dashboards所在仪表盘数量分别来自query_runs与dashboards-countCTEcollection_name为空时回退为Our Analytics搜索与排序common/add-search-clause对问题名、错误文本、数据库名、集合名做模糊匹配common/add-sort-clause将前端传入的排序列与方向安全映射到 SQLORDER BY总数统计通过窗口函数count(*) over ()计算总行数并交给流式xform提取为结果根部的total_count前端用它渲染分页控件的总数showTotal。从这段实现可以看出Erroring questions 本质上是把审计数据库中最近一次查询执行记录latest query execution的错误字段作为事实来源再与问题卡片、数据库、集合等元数据做关联投影最终生成一份可搜索、可排序、可分页的诊断清单。七、使用建议与边界重跑是真执行点击 Rerun 会真实地向数据库重新发起该问题的查询而不是只读历史记录。对重跑影响较大的查询建议先确认当前数据库负载。只覆盖最后一次执行判定依据是latest_qe.error如果某问题最近一次运行成功、但更早的运行曾出错它不会出现在该列表中。修复后的验证闭环典型排查流程是——按错误关键词搜索 → 打开问题定位根因 → 修复 → 回到列表勾选重跑 → 问题从清单消失即视为修复完成。企业版专属该能力位于metabase-enterprise目录下前端 monitor/tools/ErrorOverview 与后端 audit_app开源版不包含此页面列表数据来源于企业版审计应用采集的查询执行历史。总结Erroring questions 把哪些问题上次运行出错了、错在哪里、影响多大沉淀为一个可搜索、可排序、可批量重跑的管理员工具。本文不仅覆盖了官方文档的全部操作要点入口、三要素信息、搜索、批量重跑还通过 前端 ErrorOverview 与 后端 bad-table 查询 还原了从审计执行记录到诊断清单的完整数据链路。对于需要长期维护大量问题与仪表盘的企业环境建议将该页面纳入日常巡检结合 Monitor 首页、应用日志 与 后台任务 一起使用可以更快形成发现错误 → 定位根因 → 验证修复的闭环。【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考