可观测性后端【免费下载链接】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.io 的 Grafana 数据源插件仓库目录 sdk/highlightinc-highlight-datasource是一个基于 Grafana 官方脚手架生成的 TypeScript Go 混合插件其根目录下的.config/目录集中存放了 ESLint、Prettier、Jest、TypeScript 与 Webpack 等工具的默认构建配置。本文以该目录自带的说明文档sdk/highlightinc-highlight-datasource/.config/README.md为主线逐项讲解如何在插件根目录安全地扩展这些配置并结合仓库中的真实实现jest.config.js、tsconfig.json、package.json、docker-compose.yaml以及前后端源码进行印证。读完本文你将掌握一套可复用的 Grafana 插件构建配置扩展方法并能定位 highlight.io 数据源插件中每一项配置的实际作用。认识.config目录自动生成、只读优先.config/目录由 Grafana 脚手架scaffolding自动生成其定位是“默认构建配置”专门用于支撑插件的开发、测试与构建流程。官方对它的使用边界给出了两条明确建议不要直接修改.config/目录中的任何文件。这些文件会随脚手架升级而更新手工改动会在后续同步时产生冲突或被覆盖如需定制应在插件项目根目录新建对应的配置文件并通过extends/ 合并的方式继承默认配置把自定义逻辑与默认配置解耦。这条“自动生成、不直接改、根目录覆盖”的约定正是本文全部扩展做法的底层原则。在 highlight.io 数据源插件仓库中可以找到与该约定一一对应的真实产物根目录下的 jest.config.js、jest-setup.js、tsconfig.json 都是典型的“继承.config/默认配置”的文件。扩展 ESLint 配置Grafana 脚手架提供了一套基于grafana/eslint-config的默认 ESLint 规则见 package.json 中的grafana/eslint-config依赖。要扩展它只需编辑插件项目根目录下的.eslintrc文件用extends指向.config/.eslintrc即可{ extends: ./.config/.eslintrc, rules: { react/prop-types: off } }上面的例子演示了如何在保留 Grafana 全部默认规则的同时关闭react/prop-types这条规则。其他规则的增删改均可照此办理——你只需维护根目录的.eslintrc.config/目录保持原样。与仓库脚本的配合扩展后的 ESLint 配置会通过以下 npm script 生效见 package.jsonlint: eslint src --ext ts,tsx --report-unused-disable-directives, lint:fix: yarn lint -- --fix注意 lint 范围是src目录前端源码插件后端为 Go 实现其代码规范由 Go 工具链如go vet、gofmt负责不在 ESLint 管辖范围内。扩展 Prettier 配置与 ESLint 类似Prettier 的默认配置位于.config/.prettierrc.js。在插件项目根目录新建.prettierrc.js先展开默认配置再覆盖你需要的选项module.exports { // Prettier configuration provided by Grafana scaffolding ...require(./.config/.prettierrc.js), semi: false, };这里通过对象展开把 Grafana 提供的默认配置完整继承下来仅把semi行尾分号改为false。由于默认配置和自定义配置分处两个文件后续 Grafana 脚手架升级默认配置时你的自定义项不会丢失。扩展 Jest 配置插件的单元测试基于 Jest。与 Jest 相关的配置分散在两个根目录文件中各自职责如下jest-setup.js在每个测试文件执行之前运行用于初始化 Jest DOMtesting library 依赖并应用必要的 polyfilljest.config.js主配置入口负责继承 Grafana 推荐的 Jest 设置。在 highlight.io 数据源插件仓库中这两个文件都有真实的极简实现jest-setup.js 仅做一件事——引入脚手架的 setup// Jest setup provided by Grafana scaffolding import ./.config/jest-setup;jest.config.js 在继承默认配置的同时强制将时区固定为 UTC以保证快照snapshot测试在不同本地时区下结果一致// force timezone to UTC to allow tests to work regardless of local timezone // generally used by snapshots, but can affect specific tests process.env.TZ UTC; module.exports { // Jest configuration provided by Grafana scaffolding ...require(./.config/jest.config), };ESM 报错的处理高频坑点使用 Jest 时一个常见问题是当import一个只提供 ESM 构建的 npm 包时Jest 会报SyntaxError: Cannot use import statement outside a module。原因在于 Jest 默认只转换node_modules之外的源码而 Grafana 的脚手架配置内部维护了一份已知的“需要转换的 ESM 包”清单grafanaESModules。解决方法是给 Jest 的transformIgnorePatterns传入这份清单并在需要时追加额外的包名。脚手架说明文档给出的扩展写法如下process.env.TZ UTC; const { grafanaESModules, nodeModulesToTransform } require(./config/jest/utils); module.exports { // Jest configuration provided by Grafana ...require(./.config/jest.config), // Inform jest to only transform specific node_module packages. transformIgnorePatterns: [nodeModulesToTransform([...grafanaESModules, packageName])], };其中nodeModulesToTransform([...])会把“已知 ESM 包 你新追加的包名”转换为 jest 的正则白名单其余node_modules仍按默认策略跳过转换。在 highlight.io 数据源插件中emotion/css、grafana/ui等现代依赖都是典型的需要纳入此白名单的对象。顺带一提该插件的 package.json 还引入了swc/jest与swc/core作为测试转换器配合babel/core处理 TS/TSX 编译这也是 Grafana 10.x 时代脚手架默认的转换链路。扩展 TypeScript 配置TypeScript 的默认配置位于.config/tsconfig.json。在插件项目根目录编辑tsconfig.json通过extends继承默认配置并用compilerOptions覆盖需要的选项{ extends: ./.config/tsconfig.json, compilerOptions: { preserveConstEnums: true } }仓库中真实的 tsconfig.json 正是这一模式的标准示范——继承.config/tsconfig.json只补充jsx: react和esModuleInterop: true{ compilerOptions: { jsx: react, esModuleInterop: true }, extends: ./.config/tsconfig.json }jsx: react让 TypeScript 以经典 React 运行时编译 JSX与项目前端使用 React 19 的配置一致见 package.json 的react依赖esModuleInterop: true允许import React from react这类默认导入写法是 Grafana 前端代码的常见约定。插件提供了typecheck: tsc --noEmit脚本见 package.json你可以随时用它验证扩展后的 TypeScript 配置是否正确。扩展 Webpack 配置三步走Webpack 是插件的核心打包器默认配置位于.config/webpack/webpack.config。扩展它需要三步每一步都有明确的文件与命令要求。第 1 步新建自定义 Webpack 配置文件在插件项目根目录新建webpack.config.ts作为自定义配置的宿主// webpack.config.ts import type { Configuration } from webpack; import { merge } from webpack-merge; import grafanaConfig from ./.config/webpack/webpack.config; const config async (env): PromiseConfiguration { const baseConfig await grafanaConfig(env); return merge(baseConfig, { // Add custom config here... output: { asyncChunks: true, }, }); }; export default config;这里用webpack-merge将 Grafana 的基础配置与自定义配置深度合并。示例中开启了output.asyncChunks你可以在此位置追加任何 webpack 配置项如自定义 loader、alias 或插件。第 2 步更新package.json的构建脚本要让 webpack 使用新配置需要把 package.json 中的build与dev脚本从指向.config/改为指向根目录的新文件build生产构建:-build: webpack -c ./.config/webpack/webpack.config.ts --env production, build: webpack -c ./webpack.config.ts --env production,dev开发监听模式:-dev: webpack -w -c ./.config/webpack/webpack.config.ts --env development, dev: webpack -w -c ./webpack.config.ts --env development,-c指定配置文件--env production/--env development把环境标识透传给配置函数即第 1 步中的env参数-w启用 watch 模式源码变更后自动重新打包。仓库当前 package.json 中的build、dev脚本即默认指向.config/webpack/webpack.config.ts遵循上述步骤即可无缝切换到自定义配置。第 3 步验证产物构建完成后打包结果输出到dist/目录其中包含后端可执行文件gpx_highlightinc_highlight_datasource该名称由 plugin.json 中的executable字段声明。dist/目录会被 docker-compose.yaml 挂载进 Grafana 容器因此修改 Webpack 配置后只需重建并重启容器即可在 Grafana 中看到新的插件行为。配置 Grafana Docker 镜像脚手架的所有 Docker 相关命令默认使用grafana-enterprise镜像。如果需要覆盖可在docker-compose.yaml的grafana服务构建块中增加grafana_image构建参数version: 3.7 services: grafana: container_name: myorg-basic-app build: context: ./.config args: grafana_version: ${GRAFANA_VERSION:-9.1.2} grafana_image: ${GRAFANA_IMAGE:-grafana}grafana_image构建参数从环境变量GRAFANA_IMAGE读取默认值为grafana社区版grafana_version同理从GRAFANA_VERSION读取默认值示例中为9.1.2运行时通过GRAFANA_IMAGExxx docker-compose up --build即可临时切换镜像适合在需要测试不同 Grafana 版本或企业版/社区版差异的场景下使用。仓库真实的 docker-compose.yaml 已经遵循了这一模式并把默认 Grafana 版本定为10.1.0与 plugin.json 中声明的grafanaDependency: 10.1.0相匹配。它还在extra_hosts中配置了host.docker.internal:host-gateway并把dist/、provisioning/、dashboards/分别挂载到容器的插件目录、provisioning 目录与仪表盘目录端口映射为3001:3000services: grafana: container_name: highlightinc-highlight-datasource extra_hosts: - host.docker.internal:host-gateway platform: linux/amd64 build: context: ./.config args: grafana_image: ${GRAFANA_IMAGE:-grafana} grafana_version: ${GRAFANA_VERSION:-10.1.0} ports: - 3001:3000/tcp volumes: - ./dist:/var/lib/grafana/plugins/highlightinc-highlight-datasource - ./provisioning:/etc/grafana/provisioning - ./dashboards:/var/lib/grafana/dashboards - ./grafana/data:/var/lib/grafana源码印证构建配置之外的插件本体理解构建配置的价值在于它能支撑起插件真正的功能。highlight.io 数据源插件的运行链路恰好与上面每一层配置一一对应可作为扩展配置后的验证入口1. 插件能力声明plugin.json{ type: datasource, name: Highlight.io, id: highlightinc-highlight-datasource, backend: true, executable: gpx_highlightinc_highlight_datasource, alerting: true, metrics: true, logs: true }backend: true说明插件同时包含 Go 后端进程由 Webpack 之外的 Mage 构建产出的gpx_*可执行文件alerting/metrics/logs声明了它支持告警、指标与日志数据源能力——这正是Metrics、LogLines等查询类型的来源。2. 前端查询构造src/datasource.ts前端继承 Grafana 的DataSourceWithBackend内置的tableOptions把查询资源限定为traces、logs、errors、sessions四种metricOptions定义了Count、CountDistinct、Min、Avg、P50、P90、P95、P99、Max、Sum、None等聚合函数且每个函数标注了可用的资源表getDefaultQuery()则给出默认查询参数如bucketCount: 50、limit: 10、默认按Timestamp分桶。TypeScript 配置上一节扩展的tsconfig.json正是为编译这些前端源码服务的。3. 后端 GraphQL 执行pkg/plugin/datasource.go后端NewDatasource在ClientId非空时使用 OAuth2 客户端凭证模式clientcredentials.Config自动换取访问令牌否则直接使用默认 HTTP 客户端——这对应了配置面板中“云托管填 Client ID/Secret、自托管留空”的行为。查询分发逻辑query()函数在Metric None时走日志行查询queryLogLines返回带FrameTypeLogLines元数据的日志帧否则走指标查询queryMetrics通过metricsGraphQL 查询拉取分桶指标按Timestamp或自定义bucket_by键构造时序/直方图帧。CheckHealth通过一次traces_metrics计数查询验证连接对应配置页的Save test按钮。4. 预置数据源配置provisioning/datasources/datasource.yamlapiVersion: 1 datasources: - name: Highlight.io type: highlightinc-highlight-datasource jsonData: clientID: projectID: 1344 tokenURL: https://pri.highlight.io/oauth/token backendURL: https://pri.highlight.io version: 1 editable: true这是开箱即用的演示配置projectID: 1344指向 highlight.io 官方演示项目backendURL与tokenURL指向云托管后端https://pri.highlight.ioclientID留空演示项目无需 OAuth。四个 jsonData 字段与前端 ConfigEditor.tsx 的输入框一一对应其中clientSecret作为安全字段写入secureJsonData仅在后端解密使用。扩展配置的注意事项与常见问题综合以上内容扩展构建配置时有几点需要格外留意自担风险.config/说明文档明确提示扩展基础配置属于“自担风险”操作配置不当可能导致项目构建、测试或与 Grafana 的集成出现问题永远通过根目录文件覆盖而非修改.config/无论是.eslintrc、.prettierrc.js、jest.config.js还是tsconfig.json、webpack.config.ts一律在插件根目录新建或修改用extends、对象展开或webpack-merge继承默认配置版本一致性本插件的构建链路依赖node 20见 package.json 的engines字段且 Grafana 依赖版本为10.1.0扩展 Webpack 或升级脚手架时应同时核对这两项约束Go 与 TS 双栈分工插件是 TypeScript前端 Go后端混合项目ESLint/Prettier/Jest/TypeScript/Webpack 配置只作用于src/前端部分后端由 Go 工具链管理二者构建流程相互独立但最终统一打包进插件目录。遵循“继承默认、根目录覆盖、自担风险”的原则你可以在不破坏 Grafana 脚手架可升级性的前提下为 highlight.io 数据源插件或其他任何基于 Grafana 脚手架生成的插件定制出一套完全符合团队规范的构建、测试与开发环境。赞分享可观测性后端【免费下载链接】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点击查看免费下载相关推荐在 Grafana 中接入 highlight.io数据源插件的安装、可视化查询与告警配置指南在 Grafana 中接入 highlight.io数据源插件的安装、可视化查询与告警配置指南 本文讲解如何通过 highlight.io 官方 Grafan可观测性后端使用 skpm 构建 react-sketchapp 插件从脚手架到自定义构建配置的完整指南使用 skpm 构建 react sketchapp 插件从脚手架到自定义构建配置的完整指南 导读 本文以 react sketchapp 官方指南 docs开发工具前端highlight.io Grafana 数据源接入指南安装、配置与自托管 OAuth 认证设置highlight.io Grafana 数据源接入指南安装、配置与自托管 OAuth 认证设置 highlight.io 提供官方 Grafana 数据源插可观测性后端上一篇dxwrapper 完整指南三步让老游戏在 Windows 10/11 上正常运行下一篇Squirrel-RIFE 免费AI视频补帧教程24fps升60fps实操创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深入 highlight.io Grafana 数据源插件：扩展 `.config` 脚手架构建配置的完整实践指南
可观测性后端【免费下载链接】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.io 的 Grafana 数据源插件仓库目录 sdk/highlightinc-highlight-datasource是一个基于 Grafana 官方脚手架生成的 TypeScript Go 混合插件其根目录下的.config/目录集中存放了 ESLint、Prettier、Jest、TypeScript 与 Webpack 等工具的默认构建配置。本文以该目录自带的说明文档sdk/highlightinc-highlight-datasource/.config/README.md为主线逐项讲解如何在插件根目录安全地扩展这些配置并结合仓库中的真实实现jest.config.js、tsconfig.json、package.json、docker-compose.yaml以及前后端源码进行印证。读完本文你将掌握一套可复用的 Grafana 插件构建配置扩展方法并能定位 highlight.io 数据源插件中每一项配置的实际作用。认识.config目录自动生成、只读优先.config/目录由 Grafana 脚手架scaffolding自动生成其定位是“默认构建配置”专门用于支撑插件的开发、测试与构建流程。官方对它的使用边界给出了两条明确建议不要直接修改.config/目录中的任何文件。这些文件会随脚手架升级而更新手工改动会在后续同步时产生冲突或被覆盖如需定制应在插件项目根目录新建对应的配置文件并通过extends/ 合并的方式继承默认配置把自定义逻辑与默认配置解耦。这条“自动生成、不直接改、根目录覆盖”的约定正是本文全部扩展做法的底层原则。在 highlight.io 数据源插件仓库中可以找到与该约定一一对应的真实产物根目录下的 jest.config.js、jest-setup.js、tsconfig.json 都是典型的“继承.config/默认配置”的文件。扩展 ESLint 配置Grafana 脚手架提供了一套基于grafana/eslint-config的默认 ESLint 规则见 package.json 中的grafana/eslint-config依赖。要扩展它只需编辑插件项目根目录下的.eslintrc文件用extends指向.config/.eslintrc即可{ extends: ./.config/.eslintrc, rules: { react/prop-types: off } }上面的例子演示了如何在保留 Grafana 全部默认规则的同时关闭react/prop-types这条规则。其他规则的增删改均可照此办理——你只需维护根目录的.eslintrc.config/目录保持原样。与仓库脚本的配合扩展后的 ESLint 配置会通过以下 npm script 生效见 package.jsonlint: eslint src --ext ts,tsx --report-unused-disable-directives, lint:fix: yarn lint -- --fix注意 lint 范围是src目录前端源码插件后端为 Go 实现其代码规范由 Go 工具链如go vet、gofmt负责不在 ESLint 管辖范围内。扩展 Prettier 配置与 ESLint 类似Prettier 的默认配置位于.config/.prettierrc.js。在插件项目根目录新建.prettierrc.js先展开默认配置再覆盖你需要的选项module.exports { // Prettier configuration provided by Grafana scaffolding ...require(./.config/.prettierrc.js), semi: false, };这里通过对象展开把 Grafana 提供的默认配置完整继承下来仅把semi行尾分号改为false。由于默认配置和自定义配置分处两个文件后续 Grafana 脚手架升级默认配置时你的自定义项不会丢失。扩展 Jest 配置插件的单元测试基于 Jest。与 Jest 相关的配置分散在两个根目录文件中各自职责如下jest-setup.js在每个测试文件执行之前运行用于初始化 Jest DOMtesting library 依赖并应用必要的 polyfilljest.config.js主配置入口负责继承 Grafana 推荐的 Jest 设置。在 highlight.io 数据源插件仓库中这两个文件都有真实的极简实现jest-setup.js 仅做一件事——引入脚手架的 setup// Jest setup provided by Grafana scaffolding import ./.config/jest-setup;jest.config.js 在继承默认配置的同时强制将时区固定为 UTC以保证快照snapshot测试在不同本地时区下结果一致// force timezone to UTC to allow tests to work regardless of local timezone // generally used by snapshots, but can affect specific tests process.env.TZ UTC; module.exports { // Jest configuration provided by Grafana scaffolding ...require(./.config/jest.config), };ESM 报错的处理高频坑点使用 Jest 时一个常见问题是当import一个只提供 ESM 构建的 npm 包时Jest 会报SyntaxError: Cannot use import statement outside a module。原因在于 Jest 默认只转换node_modules之外的源码而 Grafana 的脚手架配置内部维护了一份已知的“需要转换的 ESM 包”清单grafanaESModules。解决方法是给 Jest 的transformIgnorePatterns传入这份清单并在需要时追加额外的包名。脚手架说明文档给出的扩展写法如下process.env.TZ UTC; const { grafanaESModules, nodeModulesToTransform } require(./config/jest/utils); module.exports { // Jest configuration provided by Grafana ...require(./.config/jest.config), // Inform jest to only transform specific node_module packages. transformIgnorePatterns: [nodeModulesToTransform([...grafanaESModules, packageName])], };其中nodeModulesToTransform([...])会把“已知 ESM 包 你新追加的包名”转换为 jest 的正则白名单其余node_modules仍按默认策略跳过转换。在 highlight.io 数据源插件中emotion/css、grafana/ui等现代依赖都是典型的需要纳入此白名单的对象。顺带一提该插件的 package.json 还引入了swc/jest与swc/core作为测试转换器配合babel/core处理 TS/TSX 编译这也是 Grafana 10.x 时代脚手架默认的转换链路。扩展 TypeScript 配置TypeScript 的默认配置位于.config/tsconfig.json。在插件项目根目录编辑tsconfig.json通过extends继承默认配置并用compilerOptions覆盖需要的选项{ extends: ./.config/tsconfig.json, compilerOptions: { preserveConstEnums: true } }仓库中真实的 tsconfig.json 正是这一模式的标准示范——继承.config/tsconfig.json只补充jsx: react和esModuleInterop: true{ compilerOptions: { jsx: react, esModuleInterop: true }, extends: ./.config/tsconfig.json }jsx: react让 TypeScript 以经典 React 运行时编译 JSX与项目前端使用 React 19 的配置一致见 package.json 的react依赖esModuleInterop: true允许import React from react这类默认导入写法是 Grafana 前端代码的常见约定。插件提供了typecheck: tsc --noEmit脚本见 package.json你可以随时用它验证扩展后的 TypeScript 配置是否正确。扩展 Webpack 配置三步走Webpack 是插件的核心打包器默认配置位于.config/webpack/webpack.config。扩展它需要三步每一步都有明确的文件与命令要求。第 1 步新建自定义 Webpack 配置文件在插件项目根目录新建webpack.config.ts作为自定义配置的宿主// webpack.config.ts import type { Configuration } from webpack; import { merge } from webpack-merge; import grafanaConfig from ./.config/webpack/webpack.config; const config async (env): PromiseConfiguration { const baseConfig await grafanaConfig(env); return merge(baseConfig, { // Add custom config here... output: { asyncChunks: true, }, }); }; export default config;这里用webpack-merge将 Grafana 的基础配置与自定义配置深度合并。示例中开启了output.asyncChunks你可以在此位置追加任何 webpack 配置项如自定义 loader、alias 或插件。第 2 步更新package.json的构建脚本要让 webpack 使用新配置需要把 package.json 中的build与dev脚本从指向.config/改为指向根目录的新文件build生产构建:-build: webpack -c ./.config/webpack/webpack.config.ts --env production, build: webpack -c ./webpack.config.ts --env production,dev开发监听模式:-dev: webpack -w -c ./.config/webpack/webpack.config.ts --env development, dev: webpack -w -c ./webpack.config.ts --env development,-c指定配置文件--env production/--env development把环境标识透传给配置函数即第 1 步中的env参数-w启用 watch 模式源码变更后自动重新打包。仓库当前 package.json 中的build、dev脚本即默认指向.config/webpack/webpack.config.ts遵循上述步骤即可无缝切换到自定义配置。第 3 步验证产物构建完成后打包结果输出到dist/目录其中包含后端可执行文件gpx_highlightinc_highlight_datasource该名称由 plugin.json 中的executable字段声明。dist/目录会被 docker-compose.yaml 挂载进 Grafana 容器因此修改 Webpack 配置后只需重建并重启容器即可在 Grafana 中看到新的插件行为。配置 Grafana Docker 镜像脚手架的所有 Docker 相关命令默认使用grafana-enterprise镜像。如果需要覆盖可在docker-compose.yaml的grafana服务构建块中增加grafana_image构建参数version: 3.7 services: grafana: container_name: myorg-basic-app build: context: ./.config args: grafana_version: ${GRAFANA_VERSION:-9.1.2} grafana_image: ${GRAFANA_IMAGE:-grafana}grafana_image构建参数从环境变量GRAFANA_IMAGE读取默认值为grafana社区版grafana_version同理从GRAFANA_VERSION读取默认值示例中为9.1.2运行时通过GRAFANA_IMAGExxx docker-compose up --build即可临时切换镜像适合在需要测试不同 Grafana 版本或企业版/社区版差异的场景下使用。仓库真实的 docker-compose.yaml 已经遵循了这一模式并把默认 Grafana 版本定为10.1.0与 plugin.json 中声明的grafanaDependency: 10.1.0相匹配。它还在extra_hosts中配置了host.docker.internal:host-gateway并把dist/、provisioning/、dashboards/分别挂载到容器的插件目录、provisioning 目录与仪表盘目录端口映射为3001:3000services: grafana: container_name: highlightinc-highlight-datasource extra_hosts: - host.docker.internal:host-gateway platform: linux/amd64 build: context: ./.config args: grafana_image: ${GRAFANA_IMAGE:-grafana} grafana_version: ${GRAFANA_VERSION:-10.1.0} ports: - 3001:3000/tcp volumes: - ./dist:/var/lib/grafana/plugins/highlightinc-highlight-datasource - ./provisioning:/etc/grafana/provisioning - ./dashboards:/var/lib/grafana/dashboards - ./grafana/data:/var/lib/grafana源码印证构建配置之外的插件本体理解构建配置的价值在于它能支撑起插件真正的功能。highlight.io 数据源插件的运行链路恰好与上面每一层配置一一对应可作为扩展配置后的验证入口1. 插件能力声明plugin.json{ type: datasource, name: Highlight.io, id: highlightinc-highlight-datasource, backend: true, executable: gpx_highlightinc_highlight_datasource, alerting: true, metrics: true, logs: true }backend: true说明插件同时包含 Go 后端进程由 Webpack 之外的 Mage 构建产出的gpx_*可执行文件alerting/metrics/logs声明了它支持告警、指标与日志数据源能力——这正是Metrics、LogLines等查询类型的来源。2. 前端查询构造src/datasource.ts前端继承 Grafana 的DataSourceWithBackend内置的tableOptions把查询资源限定为traces、logs、errors、sessions四种metricOptions定义了Count、CountDistinct、Min、Avg、P50、P90、P95、P99、Max、Sum、None等聚合函数且每个函数标注了可用的资源表getDefaultQuery()则给出默认查询参数如bucketCount: 50、limit: 10、默认按Timestamp分桶。TypeScript 配置上一节扩展的tsconfig.json正是为编译这些前端源码服务的。3. 后端 GraphQL 执行pkg/plugin/datasource.go后端NewDatasource在ClientId非空时使用 OAuth2 客户端凭证模式clientcredentials.Config自动换取访问令牌否则直接使用默认 HTTP 客户端——这对应了配置面板中“云托管填 Client ID/Secret、自托管留空”的行为。查询分发逻辑query()函数在Metric None时走日志行查询queryLogLines返回带FrameTypeLogLines元数据的日志帧否则走指标查询queryMetrics通过metricsGraphQL 查询拉取分桶指标按Timestamp或自定义bucket_by键构造时序/直方图帧。CheckHealth通过一次traces_metrics计数查询验证连接对应配置页的Save test按钮。4. 预置数据源配置provisioning/datasources/datasource.yamlapiVersion: 1 datasources: - name: Highlight.io type: highlightinc-highlight-datasource jsonData: clientID: projectID: 1344 tokenURL: https://pri.highlight.io/oauth/token backendURL: https://pri.highlight.io version: 1 editable: true这是开箱即用的演示配置projectID: 1344指向 highlight.io 官方演示项目backendURL与tokenURL指向云托管后端https://pri.highlight.ioclientID留空演示项目无需 OAuth。四个 jsonData 字段与前端 ConfigEditor.tsx 的输入框一一对应其中clientSecret作为安全字段写入secureJsonData仅在后端解密使用。扩展配置的注意事项与常见问题综合以上内容扩展构建配置时有几点需要格外留意自担风险.config/说明文档明确提示扩展基础配置属于“自担风险”操作配置不当可能导致项目构建、测试或与 Grafana 的集成出现问题永远通过根目录文件覆盖而非修改.config/无论是.eslintrc、.prettierrc.js、jest.config.js还是tsconfig.json、webpack.config.ts一律在插件根目录新建或修改用extends、对象展开或webpack-merge继承默认配置版本一致性本插件的构建链路依赖node 20见 package.json 的engines字段且 Grafana 依赖版本为10.1.0扩展 Webpack 或升级脚手架时应同时核对这两项约束Go 与 TS 双栈分工插件是 TypeScript前端 Go后端混合项目ESLint/Prettier/Jest/TypeScript/Webpack 配置只作用于src/前端部分后端由 Go 工具链管理二者构建流程相互独立但最终统一打包进插件目录。遵循“继承默认、根目录覆盖、自担风险”的原则你可以在不破坏 Grafana 脚手架可升级性的前提下为 highlight.io 数据源插件或其他任何基于 Grafana 脚手架生成的插件定制出一套完全符合团队规范的构建、测试与开发环境。赞分享可观测性后端【免费下载链接】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点击查看免费下载相关推荐在 Grafana 中接入 highlight.io数据源插件的安装、可视化查询与告警配置指南在 Grafana 中接入 highlight.io数据源插件的安装、可视化查询与告警配置指南 本文讲解如何通过 highlight.io 官方 Grafan可观测性后端使用 skpm 构建 react-sketchapp 插件从脚手架到自定义构建配置的完整指南使用 skpm 构建 react sketchapp 插件从脚手架到自定义构建配置的完整指南 导读 本文以 react sketchapp 官方指南 docs开发工具前端highlight.io Grafana 数据源接入指南安装、配置与自托管 OAuth 认证设置highlight.io Grafana 数据源接入指南安装、配置与自托管 OAuth 认证设置 highlight.io 提供官方 Grafana 数据源插可观测性后端上一篇dxwrapper 完整指南三步让老游戏在 Windows 10/11 上正常运行下一篇Squirrel-RIFE 免费AI视频补帧教程24fps升60fps实操创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
