rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
65 Commits 1 Branch 1 Tag
cb1ef1dff4b4b87803a2e449486b0a90539997a8
Commit Graph
5 Commits
Author SHA1 Message Date
opsx cb1ef1dff4 fix(alerts,analysis): 告警引擎稳定性 5 项修复；每日量接口去掉同步 Loki 查询（20s→10ms） 
=== 一、告警引擎稳定性审查（引擎本身是异步的：ticker + goroutine）===
1) 【高】ticker 无重叠保护
   ticker 每 1 分钟触发；一轮规则检查 8 条 × 20~30s = 2~4 分钟，远超一分钟。
   原来每过一分钟就再开一轮 → 查询越堆越多，抢走页面查询的 Loki 资源，
   每轮越来越慢，最终表现为"告警不响了"。
   → 新增 alertCheckRunning(atomic.Bool)，上一轮未完成直接跳过本轮并记日志。

2) 【高】单条规则无超时
   RunAlertCheck(context.Background()) 没有 deadline：Loki 一旦挂住，整轮永久运行，
   叠加问题 1 会让引擎再也不启动新一轮（静默死亡）。
   → 每轮总超时 5 分钟（alertRoundTimeout）+ 单条规则 90s（alertRuleTimeout）。

3) 【中】panic 只在整个 tick 层 recover
   一条规则 panic 会让本轮后续规则全部跳过。
   → per-rule recover，panic 记为一条 failed 投递记录，后续规则继续。

4) 【中】冷却记录每分钟写一条，把真实发送记录挤光
   AlertDeliveries 只保留最近 50 条，而处于冷却期时每个 tick 都写一条 cooldown，
   一小时内真实的"已发送"记录就全被挤掉了，发送历史没法看。
   → recordCooldownThrottled()：同一规则 10 分钟最多写一条。附单测。

5) 规则串行本身保留（避免同时压垮 Loki），但配合 1) 才安全。

=== 二、每日日志量接口：20 秒 → 10 毫秒 ===
根因：GetDailyVolumeHistory 里**同步** await 一次"整天 index/stats"补抓当天数据，
那次查询超时 20s → 整个接口 20s → 前端超时 → 页面显示"每日日志量没数据"；
更糟的是这条重查询还和页面的 histogram/stats 抢 Loki，导致那两个接口同时 502
（访问日志实证：daily-volume latency_ms 20000.997，stats/histogram 502）。
→ 接口改为**只读库**，不触发任何 Loki 查询；当天数据由后台每 30 分钟的
  定时任务补（CaptureRecentDailyVolumes）。
→ 同时把整天 index/stats 的超时从 20s 提到 90s（370GB/天，20s 不够）。
实测：10ms。

=== 三、通知通道改名「默认告警」(schemaVersion v8→v9) ===
"lark 默认告警" / "默认通知通道（待配置 Webhook）" → 统一为「默认告警」。
只改名，不动 Webhook、不动 enabled：
首次部署创建的占位通道必须保持「空 Webhook + 禁用」，由管理员自己填，
否则会出现"已启用但空地址"的通道，告警一命中就全部投递失败。

=== 四、其它文案 ===
「每日日志量」副标题精简为「每天的日志总量，平台保留历史趋势」，
并移除「平台留存历史」徽标（用户反馈多余）。

=== 实测（303134c0c718）===
  /logs/daily-volume：10ms（原 20000ms）
  通道列表：id=1 name="默认告警" enabled=true hasWebhook=true
  go test ./... 全绿（含新增 TestRecordCooldownThrottled）
 2026-10-29 03:38:30 +00:00
opsx 607b67a2ed fix(alerts,analysis,dashboard): 阈值再上调 + 告警风暴全局闸门；修 subtitle/门控/饼图 Top5 
=== 1. 告警阈值第二轮上调（500~5000 这一档仍然太敏感）===
实测业务高峰期这些量级就是常态，阈值贴着基线等于"每天准点报警"：
    应用错误激增   50000 → 100000（冷却 120m → 240m）
    ingress 5xx      500 → 2000  （冷却 240m）
    ingress 4xx     5000 → 20000 （冷却 240m）
    数据库连接失败   200 → 1000  （冷却 240m）
迁移 v7→v8，只改"仍等于旧默认值"的规则，用户手动调过的不动。

=== 2. 告警风暴抑制：新增全局闸门 ===
单条规则的 cooldown 只能防"同一条重复"，挡不住"多条规则同时炸"。
实际踩过：一次存储抖动让 8 条内置规则同时命中，10 秒内群里刷了 8 条，
之后大家开始无视这个群 —— 告警疲劳比漏报更难挽回。
新增 overStormLimit()：最近 1 小时内全平台成功发送数 ≥ 12 条时，
后续命中不再发送，只写一条状态为 cooldown 的发送记录并注明
"告警风暴抑制：最近 1 小时已发送 N 条（上限 12）"，可见可追溯。

=== 3. 分析页 subtitle 仍是裸 key ===
中文语言包缺顶层 subtitle（英文包有），i18next 找不到就把 key 原样输出。
补齐：「按应用与命名空间看日志量、错误与趋势，找出最吵的业务」。

=== 4. 分析页三条"没有应用维度的数据"的真正原因 ===
「活跃应用」「应用日志量 Top 5」「应用日志量流图」都依赖 by-app 重查询，
而这条查询被**底部排行卡片的可见性**门控（rankingEnabled: rankingView.inView）——
用户不滚到底就永远不发请求，于是顶部三块永远是空的。
改为进页面就发（两阶段渲染：索引类指标先出，app 维度到货后补）。
懒加载只保留在真正位于底部的「每日日志量」「Ingress 分析」。

=== 5. 饼图改 Top 5 + 文案 ===
用户要求：应用日志量 Top 5 用饼图。TOP_SLICES 8 → 5，
标题改「应用日志量 Top 5」，副标题写明"其余归入其他"。

=== 6. 卡片顺序 ===
「每日日志量」从中间移到「应用排行」之后（更靠底部，慢慢加载）。

=== 7. 仪表盘 ===
整个「平台自检」卡片（含所有指标行）按用户要求移除。

=== 实测（2e8c88817b6a）===
  v8 迁移：4 条规则阈值上调，日志齐全
  当前阈值：FATAL>10 / panic>10 / OOM>5 / StackOverflow>5 /
            应用错误>100000 / ingress 5xx>2000 / 4xx>20000 / DB 连接>1000
  冷却：低频规则 120m，高频规则 240m
 2026-10-28 23:43:14 +00:00
opsx b49677f6a6 feat: 运维标杆化打磨 P0/P1/P2 —— 审计日志、真实指标、备份恢复、菜单收敛 
审计发现 5 处硬伤（/metrics 空壳、零备份、prod 双副本数据分裂、零审计、资源偏紧），
本轮全部落地。

=== P0-1 真实 /metrics（原来是空壳）===
原实现只返回一行注释 `# LokiStack Metrics`，注释却写着"可被 Prometheus 抓取"，
平台挂了/DB 写不进去/告警引擎卡死都只能靠用户反馈。
现接入 prometheus/client_golang，四层指标：
  HTTP    : lokistack_http_requests_total / _duration_seconds / _in_flight_requests
  存储    : lokistack_db_size_bytes / _db_save_duration_seconds / _db_save_total / _db_records
  业务    : lokistack_deployments{status,mode} / lokistack_collectors{status,type,run_mode}
  后台任务: lokistack_alert_evaluations_total / _duration_seconds / lokistack_loki_queries_total
  + go_* / process_*（GoCollector、ProcessCollector）

关键点：path 标签用 c.FullPath() 路由模板，不用原始 URL —— 否则 117 个 Deployment
会把 Prometheus 基数炸掉。指标定义下沉 pkg/metrics 叶子包，避开
services ↔ repository 循环依赖。

=== P0-2 备份与恢复（原来 0 处代码）===
平台全部状态在 /app/data/opsxloki.json（51KB）+ kubeconfigs/ + known_hosts/，
DB 丢了 = 失去"这些资源是谁建的"的映射，从此无法管理/卸载/升级在跑的 Loki。

  CLI : lokistack backup --output <path> / restore <pkg> / self-check / version
  API : GET /system/backup（下载）/ POST /system/restore（校验暂存）/
        POST /system/restore/apply（确认应用）/ GET /system/backups
  K8s : kubernetes/pdb-backup.yaml —— 每日 03:30 CronJob，保留最近 7 份

安全设计：
  - manifest.json 记录 ENCRYPTION_KEY 的 sha256 前 16 位**指纹**，用于恢复时
    校验"这把钥匙能不能解开这份备份"，不泄露密钥本身
  - 恢复分两步（校验暂存 → 确认应用），应用前自动把当前 DB 备份为
    opsxloki.json.before-restore.<时间戳>
  - 包内不含明文密钥（kubeconfig 本就是加密态）

=== P0-3 prod compose 双副本 → 单副本 ===
lokistack-1 / lokistack-2 各挂独立数据卷 + nginx 轮询 = 数据分裂：
页面刷新两次可能看到不同结果，写操作只落一个副本。不是高可用。
已改单实例（nginx 仅做反代），文件顶部与 nginx.conf 都写明原因。

=== P0-4 操作审计日志（借鉴 /usr/local/src/aiops 的字段口径）===
aiops 是每个 controller 各写 recordXxxAudit()；本平台有 60+ 写接口，
逐个埋点必然漏，漏掉的那个恰好最危险（删集群、改存储凭证）。
改为 **gin 中间件统一记录** + handler 通过 SetAudit 补充业务语义：
  models/audit.go     : 字段对齐 aiops，另加 Method/Path/Before/After
  services/audit.go   : 写入 + 90 天/2 万条自动裁剪 + 脱敏 + diff 生成
  middleware/audit.go : 自动识别 module/action/resource，跳过只读接口
  controllers/audit.go: 列表/详情/统计（仅 admin）
敏感字段（password/secretKey/privateKey/token）写入前统一替换为 ***。

=== P1 稳定性 ===
- 平台资源 1C/1Gi → 4C/4Gi 限（500m/512Mi 请求）：JSON DB 全量读写 +
  每分钟告警评估 + 批量发布并发，1Gi 会 OOM
- terminationGracePeriodSeconds: 30 —— 收到 SIGTERM 要等 DB 完整落盘，
  否则 kubelet SIGKILL 会把 JSON 写一半（全库丢失）
- liveness timeoutSeconds 10s（默认 1s 写盘时会被误杀）
- PDB minAvailable: 0 —— 让 kubectl drain 正确等待重建，不卡维护
- DB schemaVersion + migrateSchema() 版本递进迁移（原先加字段全靠零值兜底）
- scripts/release.sh —— 不可变 tag <版本>-<日期>-<commit> + IfNotPresent，
  根治 latest 并发构建互相覆盖导致的静默回滚（本项目已实际踩过）
- PVC 保持 30Gi（按长期增长预留，云盘单价低，不做在线扩容）

=== P2 易用性 ===
- 一键自检 GET /system/self-check + 仪表盘自检卡：真实探活 Loki /ready、
  集群凭据解密、磁盘空间、主机状态、近 24h 失败操作
- 审计日志页 /audit：统计卡 + 用户名/模块/结果筛选 + 变更前后 diff 弹窗
- 菜单收敛 13 → 7（页内 tab 切换，URL 全部不变）：
    资源接入 = 集群 + 主机 + 存储
    日志服务 = Loki 实例 + 采集器
    日志     = 查询 + 分析
    系统管理 = 用户 + 审计 + 设置
  新增 GroupTabs 组件 + meta.group/groupKey，侧栏按分组去重并正确高亮

测试：go vet 通过、go test 全绿、tsc 通过
 2026-10-28 21:27:01 +00:00
opsx f3733f0bfc feat: 品牌统一 LokiStack + 全站中英 i18n + 用户批量删除 + 主题定时切换与浅色侧栏 
- 品牌: Go 模块/数据文件/二进制/构建部署资产全部 opsx→lokistack;前端 localStorage 命名空间迁移(读旧写新,含按用户 id 前缀迁移);修复 nginx upstream 与 Makefile 引用已改名服务的断裂
- i18n: react-i18next 落地,common + 11 个页面域命名空间全站中英(菜单/顶栏/登录/列表页/表单/确认弹窗/状态徽章);设置页语言即时切换;修复词典自注册导致的循环导入白屏
- 用户管理: 批量删除(POST /users/batch-delete,不删自己/最后管理员,部分失败不阻断)+ 行复选/全选/批量工具条
- 主题: 浅色侧栏(中性灰激活态)、四态模式(浅色/深色/跟随系统/定时切换,按时区判定)、顶栏太阳月亮二态、设置页紧凑分段选择器
- UI: 登录记住用户名、CardActionButton 统一五页卡片操作钮、shadcn Badge 替换手写徽章、语义色修正
- 清理: 移除主机 Web 终端(前后端)、k8s-helm/Helm 遗留代码与字段、README 重写精简
- 修复: 侧栏与日志告警 order 重复、路由标题 i18n key 未翻译、词典双逗号等
 2026-10-27 17:11:38 +08:00
logan 2d73661dd1 feat: complete Loki query, insights, settings and deployment workflows 
Add the Loki query UI, access policies, ingress insights, alert and registry settings, and their backend APIs. Include the related Kubernetes deployment and collector updates required by the integrated application.

Validated with go test ./..., npm run build, and npm run lint.
 2026-10-25 21:28:32 +08:00