可观测性后端前端运维【免费下载链接】kenerStunning status pages, batteries included!项目地址https://gitcode.com/gh_mirrors/ke/kener点击查看免费下载Kener 的官方 Roadmap 文档以清单形式记录了项目从文件系统时代到现代状态页平台的全部演进目标。本文逐项对照当前仓库版本 4.1.7见 package.json的源码、迁移脚本与文档验证每个路线图条目的实际落地状态已完成项给出具体的实现文件与调用链未完成项说明其在当前代码中的可验证现状帮助自托管部署者与贡献者快速判断哪些能力已经可用、哪些仍处于规划状态。Roadmap 完整清单继承原文档 roadmap.md/docs/content/v3/roadmap.md) 位于 v3 文档目录中完整内容如下状态符号与原文一致☑ 表示已完成、☐ 表示未完成、删除线表示已关闭并从待办中移除状态路线图条目☑Move from file system to sqlite3从文件系统迁移到 SQLite3☑Add support for webhooks增加 Webhook 支持☑Support DNS probe支持 DNS 探测☑Color Customization颜色自定义☑Support for github enterprise支持 GitHub Enterprise☐Add Rate limiting to APIs为 API 增加限流☐Add support for custom themes支持自定义主题☑Handle uploaded images for docker containers为 Docker 容器处理上传的图片☑Introduce sitemap.xml引入 sitemap.xml☑Migrate from moment to date-fns for status page状态页从 moment 迁移到 date-fns原文注moment 曾保留在 dashboard计划之后移除☑Create Admin UI创建管理后台原文注在 3.0.0 版本发布☐Webhook customizationWebhook 自定义已划掉关闭☐Monitor Update Screen监控更新界面☐i18n for admin dashboard管理后台国际化以下按已完成项 → 未完成项的顺序逐项给出仓库内的实现证据。已完成项源码级验证1. 从文件系统迁移到 SQLite3这是路线图的第一项也是 Kener 数据架构的转折点早期版本把站点计算数据直接写在磁盘目录里v3 文档 how-it-works.md/docs/content/v3/how-it-works.md) 中描述的src/lib/server/data目录模式迁移后所有业务数据统一进入关系型数据库。当前仓库 knexfile.ts 展示了迁移后的完整形态const databaseURL process.env.DATABASE_URL || sqlite://./database/kener.sqlite.db;默认连接串即 SQLite 文件 knexfile.ts对应客户端为better-sqlite3knexfile.ts 中client better-sqlite3package.json 依赖里包含better-sqlite3: ^12.5.0同时保留了postgresqlpg与mysqlmysql2两条分支Postgres/MySQL 下配置了 Web/Worker 双连接池DATABASE_POOL_MAX默认 10、DATABASE_WORKER_POOL_MAX默认 5把 SvelteKit 请求流量与 BullMQ 后台任务隔离SQLite 则复用单连接数据库结构由 migrations/ 目录下 30 余个 Knex 迁移脚本管理最早的 20250111153517_init.ts 建立初始表结构后续迁移覆盖了告警配置、订阅系统重构20260128120000_redesign_subscription_system.ts、RBAC 权限表20260330120000_add_rbac_tables.ts等演进开发与部署流程中也固化了这一事实package.json的migrate、preseed脚本都会先执行knex migrate:latest。这一迁移的直接收益是 Docker 单容器部署无需再挂载数据卷来保存业务状态——数据全部落在数据库文件或外部数据库里。2. Webhook 通知支持路线图第二项 Add support for webhooks 对应 Kener 告警通知体系中的 Webhook 通道完整实现位于 webhook_notification.ts与 email_notification.ts、slack_notification.ts、discord_notification.ts 并列在 src/lib/server/notification/ 目录下。发送流程webhook_notification.ts可以分为四个阶段环境变量密钥注入调用GetRequiredSecrets扫描 webhook 正文、自定义 Header 与目标 URL识别形如环境变量占位的密钥引用再通过ReplaceAllOccurrences将其替换为真实值避免在数据库里明文存储敏感信息Header 合并默认携带三组请求头user-agent: Kener/version、accept: application/json、content-type: application/json用户自定义的 JSON Header 会按键名不区分大小写合并同名键覆盖默认值Mustache 模板渲染正文使用Mustache.render渲染并显式关闭 HTML 转义escape: (text) text保证 JSON 正文不被破坏POST 请求与错误处理通过fetch以 POST 方式发出请求非 2xx 响应与网络异常都会返回结构化的{ error, details }对象便于上游队列记录失败原因。默认 Webhook 正文模板在 webhook_alert_template.ts 中是一份 JSON包含的 Mustache 变量覆盖告警全貌{ alert_id: {{alert_id}}, alert_name: {{alert_name}}, alert_for: {{alert_for}}, alert_status: {{alert_status}}, alert_severity: {{alert_severity}}, alert_message: {{alert_message}}, alert_source: {{alert_source}}, alert_timestamp: {{alert_timestamp}}, alert_cta_url: {{alert_cta_url}}, alert_incident_id: {{#alert_incident_id}}...{{/alert_incident_id}}, is_resolved: {{is_resolved}}, site_url: {{site_url}}, site_name: {{site_name}}, colors_up: {{colors_up}}, colors_down: {{colors_down}}, colors_degraded: {{colors_degraded}}, colors_maintenance: {{colors_maintenance}} }值得注意的是colors_*系列变量见下一节的颜色自定义能力也随 Webhook 下发第三方系统可以直接按 Kener 站点配色渲染告警。3. DNS 探测DNS ProbeSupport DNS probe 是监控探测层的一项能力用于把域名解析本身作为可监控对象。实现位于 src/lib/server/dns.ts核心是一个DNSResolver类配置与文档入口对应 monitors-dns.md/docs/content/v3/monitors-dns.md)。从源码可以归纳出该探测器的几个关键设计UDP 递归查询基于dns2构造查询包经dgramUDP socket 发送默认 nameserver 为8.8.8.8dns.ts默认查询超时 3000msDEFAULT_QUERY_TIMEOUT_MSdns.tsDNS-over-TLS 查询queryOverTls方法支持 TLS 加密传输默认 DoT 端口 853dns.ts按 RFC 7858 在报文前加 2 字节长度前缀并提供tlsServername、allowSelfSignedCert、timeoutMs等选项允许对接自签证书的自建 DoT 服务权威服务器优先getAuthoritativeNameServers会沿域名层级逐级resolveNs找到权威 NS 记录queryAuthoritativeRecord先向权威服务器发问无应答再回退到递归解析器——这对验证域名是否真的指向某 IP比纯递归查询更可靠多记录类型支持 A/AAAA/NS/CNAME/MX 等类型的数据提取extractDatadns.ts记录类型清单由AllRecordTypesclientTools.ts统一定义。4. 颜色自定义Color Customizationv3 主题文档 theme.md/docs/content/v3/theme.md#L74-L76) 的 Colors 一节明确说明你可以修改 UP / DEGRADED / DOWN / MAINTENANCE 四种状态的颜色默认分别为绿、黄、红、蓝色系。该能力在源码中体现为站点数据中的colors_up、colors_down、colors_degraded、colors_maintenance四个键值它们一方面驱动状态页渲染另一方面被 notification_utils.ts 注入到各类通知模板变量中Webhook、邮件模板中均可见实现站点配色 → 告警配色的一致性。v3 旧文档customize-site.md/docs/content/v3/customize-site.md#L103)曾指出主题色只能改src/app.postcss而路线图勾选表明颜色自定义已经产品化为站点配置项。5. GitHub Enterprise 支持Support for github enterprise 一项对应 GitHub 集成中的apiURL可配置能力。v3 文档 customize-site.md/docs/content/v3/customize-site.md#L118-L144) 的 github 一节给出配置示例github: apiURL: https://api.github.com owner: username repo: repository incidentSince: 720其中apiURL默认为https://api.github.com使用 GitHub Enterprise 时改为企业实例的 API 地址即可incidentSince单位为小时默认 720 小时控制多久之前的 issue 不再被计为活跃事件。这一条目在 v3 时代以 GitHub issue 作为事件incident后端的方式完成是 GitHub Enterprise 用户私有化部署 Kener 的前提之一。6. Docker 容器的上传图片处理Handle uploaded images for docker containers 解决的是容器场景下的持久化痛点若上传文件只写在容器文件系统里容器重建后图片即丢失。当前仓库的做法是把图片直接存进数据库见迁移脚本 20260106120000_add_images_table.tsawait knex.schema.createTable(images, (table) { table.string(id, 32).primary(); // nanoid generated ID with prefix table.text(data).notNullable(); // base64 encoded image data table.string(mime_type, 50).notNullable(); // image/png, image/jpeg, image/svgxml table.string(original_name, 255); // original filename table.integer(width); // image width after resize table.integer(height); // image height after resize table.integer(size); // size in bytes table.timestamp(created_at).defaultTo(knex.fn.now()); table.timestamp(updated_at).defaultTo(knex.fn.now()); });data列保存 base64 编码的图片数据配合sharppackage.json 依赖sharp: ^0.34.5做缩放后再入库。图片随数据库一起持久化后Docker 容器重建、迁移实例都不再丢失上传内容与该路线图条目的意图一致。7. sitemap.xmlIntroduce sitemap.xml 的实现在路由 sitemap.xml/server.ts/sitemap.xml/server.ts)站点根路径下直接产出application/xml响应。实现支持三种模式由站点数据键sitemap的mode字段控制默认autooff直接返回 404关闭 sitemapmanual仅输出站点数据中sitemap.urls手工配置的 URL 列表auto自动聚合三类 URL——全部页面经 GetAllPages 获取、所有ACTIVE且未隐藏的监控经 GetMonitors 过滤status: ACTIVE, is_hidden: NO、当月与上月的事件页/events/YYYY 月份再追加手工配置项作为补充此模式依赖siteURL配置缺失时同样返回 404。所有 URL 都经过escapeXml转义server.ts/sitemap.xml/server.ts#L95-L102)防止用户配置的页面路径破坏 XML 结构。这一实现保证了自托管站点无需额外爬虫或 SEO 工具即可向搜索引擎声明完整 URL 清单。8. 从 moment 迁移到 date-fns路线图对此项有补充说明moment 曾保留在 dashboard计划之后移除。对照当前仓库可以确认迁移已经彻底完成package.json 依赖中包含date-fns: ^4.1.0与date-fns-tz: ^3.2.0且没有moment依赖在src目录下检索不到任何import moment语句仅在 tool.ts 留下//use js date instead of moment的注释直接印证了迁移动作本身。即原文中dashboard 里还留着 moment的遗留问题在当前版本已清理时间处理统一走 date-fns配合 date-fns-tz 处理时区。9. Admin UI管理后台Create Admin UI 标注发布于 3.0.0当前仓库中对应整个 src/routes/(manage)/manage) 路由组是一个功能完整的管理前端。仅 manage/app/manage/app) 子目录就包含 22 个功能模块监控与数据monitors/、monitoring-data/、badges/事件与通知incidents/、maintenances/、alerts/、triggers/、templates/、subscriptions/站点与外观site-configurations/、customizations/、pages/、internationalization/、analytics-providers/安全与身份api-keys/、users/、roles/、oidc/、captcha-providers/、embed/配合迁移脚本中的 RBAC 表结构20260330120000_add_rbac_tables.ts与users表去掉role字段20260331120000_remove_role_from_users.ts管理后台已经从能用演进到带细粒度权限的成熟形态。10. Webhook customization已划掉关闭原清单中 Webhook customization 一项被同时打了复选框和删除线☐ ~~Webhook customization~~从符号语义看是关闭移出待办的条目。而它的目标能力实际上已由上述 Webhook 模板机制吸收实现默认模板 webhook_alert_template.ts 中的每个变量都允许在管理后台manage/app/templates/manage/app/templates)编辑配合GetRequiredSecrets的环境密钥机制用户可以在不改代码的情况下完全自定义 Webhook 正文与 Header。因此该项关闭而非完成是合理的——能力落地方式与最初设想的单列功能不同。未完成项当前代码中的状态1. Add Rate limiting to APIs该条目仍是 ☐ 未完成。从源码结构看src/routes/(api)/api/v4/api/v4) 下的公开 API 路由incidents、maintenances、monitors、pages、site目前未见任何限流中间件或X-RateLimit-*响应头的生成逻辑。但 v4 API 文档已按目标行为编写authentication.md/docs/content/v4/api-reference/authentication.md#L107-L122) 的 Rate Limiting 一节描述了 API Key 的默认限流为 100 次/分钟并规划了X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset三个响应头。文档先行、实现未落地的状态与该条目在路线图上的未完成标记一致部署侧的文档reverse-proxy.md/docs/content/v4/guides/reverse-proxy.md)也提示用户可以先在反向代理层自行实现限流作为过渡方案。2. Add support for custom themes仍为 ☐。当前主题能力集中在 v3 文档 theme.md/docs/content/v3/theme.md) 描述的范围深浅色默认主题、状态条样式Partial/Full、圆角、摘要类型、状态色、字体含 Google Fonts / Bunny Fonts 与自定义 Font URL Family以及注入head的 Custom CSS。从文档与源码结构看尚不存在完整自定义主题整体换肤/主题包机制这与路线图未完成标记一致。3. Monitor Update Screen仍为 ☐。当前监控更新操作走的是 APIsrc/routes/(api)/api/v4/monitors/api/v4/monitors) 的 PATCH 接口与管理后台表单仓库中未见独立的监控批量更新界面实现条目保持未完成状态。4. i18n for admin dashboard仍为 ☐且现状对比鲜明状态页国际化已完成src/lib/locales 目录下有 24 个语言文件en.json、zh-CN.json、zh-TW.json、ja.json、ko.json、ru.json、ar 语系之外的cs/de/dk/es/fa/fr/hi/it/nb-NO/nl/pl/pt-BR/sk/tr/uk/vi等配合 src/lib/stores/i18n.ts 与 src/lib/server/i18n.ts 完成访客侧多语言配套脚本 scripts/check-translations.js、scripts/sort-translations.js 用于维护翻译完整性管理后台尚未接入对 src/routes/(manage)) 目录检索未找到 i18n 引用后台 UI 文案仍为单语言。管理后台中名为internationalization/的模块manage/app/internationalization/manage/app/internationalization)是配置站点访客多语言的管理界面而非后台自身国际化两者不要混淆。落地证据汇总表路线图条目状态仓库内证据位置文件系统 → SQLite3☑knexfile.ts、migrations/Webhook 支持☑webhook_notification.ts、webhook_alert_template.tsDNS 探测☑src/lib/server/dns.ts颜色自定义☑theme.md/docs/content/v3/theme.md#L74-L76)、notification_utils.tsGitHub Enterprise☑customize-site.md/docs/content/v3/customize-site.md#L118-L144)Docker 图片处理☑20260106120000_add_images_table.tssitemap.xml☑sitemap.xml/server.ts/sitemap.xml/server.ts)moment → date-fns☑package.jsondate-fns 依赖、无 moment、tool.tsAdmin UI☑src/routes/(manage)/manage)Webhook 自定义☑/已关闭由模板机制吸收见 manage/app/templates/manage/app/templates)API 限流☐无实现目标行为见 authentication.md/docs/content/v4/api-reference/authentication.md#L107-L122)自定义主题☐现有能力边界见 theme.md/docs/content/v3/theme.md)监控更新界面☐现有更新路径manage/app/monitors/manage/app/monitors)、API PATCH 接口/api/v4/monitors)管理后台 i18n☐状态页 24 语言见 src/lib/locales后台未接入小结这份 Roadmap 的价值在于它同时记录了从哪里来文件系统 YAML 配置时代和到哪里去管理界面 数据库 多通道通知的现代形态。截至当前仓库版本清单中 9 项能力已有可在源码中逐行验证的实现SQLite 存储、Webhook、DNS 探测、颜色自定义、GitHub Enterprise、Docker 图片持久化、sitemap.xml、date-fns 迁移、Admin UI仅剩 API 限流、自定义主题、监控更新界面与管理后台国际化 4 项处于未完成状态其中 API 限流在 v4 文档中已定义了明确的行为规范是可以预期最先落地的条目。对于计划基于 Kener 二次开发或长期自托管的读者建议以本文的证据表为基线优先关注未完成项对应的目录src/routes/(api))、src/routes/(manage))在后续版本中的变化。赞分享可观测性后端前端运维【免费下载链接】kenerStunning status pages, batteries included!项目地址https://gitcode.com/gh_mirrors/ke/kener点击查看免费下载相关推荐DesktopNaotu 功能路线图全解析从已实现功能清单到未来规划百度脑图离线版DesktopNaotu 功能路线图全解析从已实现功能清单到未来规划百度脑图离线版 导读 DesktopNaotu 是百度脑图的离线桌面版思维导图工具桌面应用前端UltimateRecyclerView 0.4.2 功能路线图解析从 UpcomingChanges 规划到源码落地验证UltimateRecyclerView 0.4.2 功能路线图解析从 UpcomingChanges 规划到源码落地验证 本文以仓库根目录下的 UpcomiAI 技能人工智能深度研究数据分析媒体生成pure_live 本地缓存清理确认与事务审计从重复弹窗到 UI/存储双层单次事务的完整落地pure_live 本地缓存清理确认与事务审计从重复弹窗到 UI/存储双层单次事务的完整落地 本篇文章基于 pure_live 仓库的专项审计文档 CACHE音视频直播移动开发上一篇【亲测免费】 Obsidian Local Images Plus 插件安装和配置指南下一篇MLKit 常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考