 opsx
|
cb91470d75
|
perf(analysis): 分层加载 + 修复裸 i18n key + 单位混用；附 Loki 查询方式的实测对比
=== 1. 界面显示裸 key（trend.subtitle / daily.subtitle / table.subtitle）===
根因：中文语言包只加了 title，**没有 subtitle**，而英文包有。
i18next 找不到 key 就把 key 原样输出，所以界面上出现 "trend.subtitle" 这种文字。
已补齐 zh 的 trend/stream/pie/daily/table 五个 subtitle，并把文案改成
人话（说明数据来源与是否需要等待），例如：
trend : 按时间分桶的日志量（来自索引统计，秒级返回）
daily : 近 7 个自然日的每日总量（来自索引统计，不受上方时间范围影响）
table : 按日志条数排前 10 的应用，点「查看日志」跳到查询页
=== 2. 分层加载：上面的先出，下面滚到再算 ===
新增 hooks/useInView.ts（IntersectionObserver，提前 200px 触发，只触发一次）。
- 首屏只跑索引类查询（histogram + index/stats），**合计 <100ms**
- 「每日日志量」「应用排行」「Ingress 分析」三块滚动到视口才发查询
- 排行卡片加载中显示"正在按应用统计（需读取日志内容，通常 20~30 秒）…"，
不再是空表格让人以为卡死
=== 3. 修复自己引入的单位混用（重要）===
趋势图数据源从 count_over_time 换成 index/volume_range 后，返回值是**字节**，
但排行表里的值是**条数**，两者混用导致：
- 统计卡显示 7956179750 这种看不懂的裸数字
- 排行占比算成 0.0x%（分子条数、分母字节）
修法：
- 统计卡拆成两张且都走索引接口（实测 histogram 50ms / index-stats 43ms）：
日志条数（索引统计） ← index/stats entries，精确条数
日志体积（索引统计） ← volume_range 累计，格式化为 GB
- 排行占比分母改用 apps 自身条数合计
- 去掉"告警行数"卡片：为了把重查询从 3 条降到 2 条已放弃全局 warn 统计，
显示一个恒为 0 的数字比不显示更误导
=== 4. Loki 查询方式实测对比（15 分钟 astralx，370GB/天）===
直接打 Loki，逐个验证卡在哪：
sum(count_over_time({ns}[30s])) step=30s 61s 超时 ← 全集群全局
sum by (app,ns)(count_over_time([30s])) step=30s 19.7s 5.5GB ← 现用
sum by (app,ns)(count_over_time([15m])) step=15m 47s 超时 ← 反直觉！
sum by (app)(count_over_time([30s] |= error)) step=30s 12.7s 5.5GB
单 app gateway count_over_time step=30s 12.6s 0.58GB
index/volume (limit=200) 2.2s ← 只给 selector 级，不能按 app
index/volume_range (step=60s) 133ms
index/stats 112ms ← entries/bytes 精确
两个结论（写进注释，避免以后又"优化"回去）：
a) **不要把 range 和 step 一起放大**：`[15m]` + step=15m 看着"点数少"，
实际要让 Loki 为单个 evaluate 点加载 15m 的 chunk，比 [30s]+step=30s 慢 2 倍以上
（47s 超时 vs 19.7s）。
b) **按 app 分组无法走索引**：Loki 3.4 的 index/volume 只回落到 selector 标签，
不支持 aggregateBy=app（传了也无效果）。所以 per-app 排行只能读日志内容，
20 秒左右是这台集群的物理下限 —— 只能靠懒加载 + 明确提示来改善体感。
=== 实测（v8-1028-2232 / 7a05683a91ae）===
logs/histogram 50ms logs/stats 43ms
by-app 排行 25077ms（懒加载，滚动到才发）
中文 subtitle 已进包：来自索引统计 / 按量排前 / 各命名空间的日志量占比 /
近 7 个自然日 / 按日志条数排前 10 各命中 1 次
|
2026-10-28 22:34:04 +00:00 |
|
|
opsx
|
fa7ddd67c1
|
perf(analysis): 分析页按索引/内容分层，告警默认阈值抬高
=== 1. 分析页"一直转圈/请求超时(40000ms)"的真实原因 ===
三个问题叠加，逐个量化：
a) 首屏用空 namespace 发查询
页面初始 namespace=''，等策略返回前就发出 `{namespace=~".+"}` 全集群查询，
策略到位后又查一次 → 一次访问跑两遍。
→ 加 namespaceReady 门控：解析完再发（effectiveSourceId）。
b) histogram 索引查询和内容查询抢同一个信号量
/logs/histogram 首选 index/volume_range（毫秒级），但仍要先抢重型令牌，
而令牌被 4 条 count_over_time（各 14~29s）占满 → 排队/429/超时。
→ 索引路径**不再占用重型令牌**（15s 独立超时），只有回退到
count_over_time 时才抢令牌。实测各跨度(15m/1h/6h/24h)均 0s。
c) 重查询条数过多
原来 4 条全局 count_over_time（total/error/warn）+ 2 条 by-app，
串行 1~2 分钟。现在只留 2 条 by-app：
- 全局总量已由 histogram（索引）提供
- 全局 error 由 errByApp 序列求和得出
- 全局 warn 放弃（优先级最低却要 20s）
实测 by-app 单条 26s，两条串行 ~52s；主图 0s 先出。
d) 日报 7 天 count_over_time（2.6TB 扫描）必然失败
→ 改走 /logs/histogram（索引）按自然日聚合，只出"每日总量"，
应用维度交给下方 Top 应用表格（有自己的时间范围）。
实测 7 天跨度毫秒级。
=== 2. 告警默认阈值抬高（告警疲劳治理）===
验证时用 `{namespace="astralx"}` + 阈值 0 触发了一次：
15 分钟命中 3051 万条 —— 阈值 0 等于把告警变成日志流复读机。
新基线（15 分钟窗口，冷却统一 120 分钟）：
致命日志 FATAL 0 → 10
Go panic 0 → 10
JVM OutOfMemoryError 0 → 5
StackOverflowError 0 → 5
应用错误激增 1000 → 50000（改名，原"error > 1000"名不副实）
ingress-nginx 5xx 100 → 500
ingress-nginx 4xx 1000 → 5000
数据库连接失败 50 → 200
迁移只改"仍等于旧默认值"的规则，用户手动调过的阈值不动。
设计原则写进 seed 注释：绝不用 threshold 0；宁可少报也不要让人对告警脱敏；
绝对阈值不跨环境通用，大集群必须按 app/namespace 收窄。
=== 实测（v6-1028-2218 / 0bf66199de66）===
规则 8 条，阈值=0 的规则数 0，冷却全部 120m
histogram astralx（15m/1h/6h/24h）: 0s
by-app metrics astralx 15m: 26s，正常返回数据
|
2026-10-28 22:20:19 +00:00 |
|
|
opsx
|
95dcd9408c
|
fix(logs,analysis,alerts): 数据源不可达、分析页超时、告警规则混入基础设施项
=== 1. 主机模式数据源地址 0.0.0.0 → 主机真实 IP（查询页"永远加载中"的根因）===
现象：切换数据源后命名空间/App 下拉不动，一直显示"加载中…"，控制台报
Get "http://0.0.0.0:3100/loki/api/v1/labels": dial tcp 0.0.0.0:3100: connect: connection refused
根因：主机模式部署的 endpoint 记的是**容器监听地址** 0.0.0.0:3100，
而平台进程不在被采集主机上，0.0.0.0 只在本机有意义。
EnsureLogSourceForDeployment 把它原样写成了数据源 URL。
修法：
- 新增 reachableEndpoint()：把 0.0.0.0 / [::] 换成关联主机的真实 IP
- schemaVersion v3→v4 迁移 fixUnreachableLogSourceURLs()，修正已有脏数据
- 实测：http://0.0.0.0:3100 → http://172.19.16.8:3100，该源 label 查询由 502 变 200
=== 2. 前端：区分"加载中"与"加载失败" ===
原来用 `loading={!options.length}` 表示加载中 —— 数据源不可达时列表永远为空，
于是界面永远转圈，把真实错误完全藏起来了（这次的 0.0.0.0 就是这样被掩盖的）。
改为独立的 namespaceLoading / namespaceError 两个状态：
- 切换数据源先清空旧 options（否则显示上一个源的命名空间，看着像"没反应"）
- 失败显示"加载失败"并在旁边给「重试」按钮，不用刷新整页
=== 3. 日志分析页：主图改走索引接口（原来 5 条 count_over_time 全超时）===
实测 astralx（约 370GB/天）15 分钟窗口：
count_over_time → exec 29s + 排队 95s，超过 30s 护栏 → 502
index/volume_range → 0s
改为两阶段渲染：
- 总量趋势改用 /logs/histogram（内部 index/volume_range），**0s 出图**
- 错误/警告/app 维度仍需读日志内容，串行执行，先渲染主图再更新
- heavyQueryTimeout 30s → 90s（实测 error 维度查询 14s 可完成）
=== 4. 告警规则按日志平台定位收敛 ===
- seed 里删掉「Kubernetes 节点 NotReady」「容器 OOMKilled」：
这类属于 kube-state-metrics / Prometheus 的职责，用日志字符串匹配不可靠
- 迁移里清掉线上已存在的同类规则（3 条）
- 修 AlertRule / NotifyChannel 重复 ID（同 logSources 一样漏在 sequences 重建外）
=== 5. 告警页 UI ===
- 规则列表由"每条一张卡"改为紧凑表格（一屏看全，阈值可对齐比较）
- 通知通道（飞书/Lark/Webhook）从「系统设置」搬到告警页折叠区：
规则和"发到哪"是一件事的两半，分两页配容易漏配导致告警发不出去
=== 6. 权限收敛 ===
- /alerts 加 adminOnly：普通用户按查询授权只看「日志查询」，不再看到告警菜单
- 系统设置从侧栏移到右上角齿轮（低频平台配置，不占侧栏一位）
=== 7. 迁移设计教训（写进代码注释）===
v2 时把"告警去重 + 清基础设施规则"塞进 case 1，但线上库已到 v2，
那段代码永远不执行。**结构变更只要逻辑变了、目标库已达该版本，就必须再抬一版**，
不能改历史迁移分支。
=== 实测（v4-1028-2210 / 979bdb4a48e8）===
v4 迁移：数据源 URL 修正 http://0.0.0.0:3100 → http://172.19.16.8:3100
source 1 label：200，0s（astralx / log）
source 2 label：200，0s（不再 connection refused）
分析页 histogram astralx 15m：0s
分析页 metrics error astralx 15m：14s
告警规则：10 条（已无基础设施类）、ID 唯一
另清理 172.19.16.8 上 13 个残留容器，回收 6.1GB
|
2026-10-28 22:11:48 +00:00 |
|
|
opsx
|
a32f93f533
|
feat(deployments,analysis): 保留弹框重设计 + 分析页命名空间筛选 + 过期 chunk 真正删除
=== 一、保留策略弹框重设计（RetentionDialog）===
旧版问题：
1. 主输入是 YAML textarea，用户必须会写 `limits_config.retention_period: 30d`
2. 三个按钮：取消 / 仅保存 / 保存并应用 —— 「仅保存」只改部署记录不重载 Loki，
今天已经造成一次真实故障：DB 记录 7 天、运行时 ConfigMap 是 24h，配置漂移
3. 「查看完整配置」是独立按钮 + 独立状态，多一次点击
4. 硬编码提示 `retention_delete_delay: 2h`，而实际已改成 10m，属于误导
新版：
- 主输入改为**保留天数数字框**（1–3650），YAML 由前端拼，用户不用写
- 快捷预设 1/7/14/30/90，实时显示「= 720 小时」
- >7 天给出存储成本提示
- 完整运行 config 改成 `<details>` 折叠，展开即自动加载（去掉独立按钮）
- **按钮只剩 2 个：取消 / 保存并应用**
- 删掉硬编码的 compactor 提示块
=== 二、日志分析页加命名空间筛选 ===
根因：analysis 页写死 namespace: ''，等价 `{namespace=~".+"}` —— 一次分析扫全集群
（实测约 370 GB/天），5 条 count_over_time 跑 30s 都出不来，页面永远转圈。
- 新增命名空间下拉（从 Loki label values 拉取，localStorage 记忆）
- 默认取业务命名空间 astralx（其次列表首个），不再默认全集群
- 「全部命名空间（较慢）」降级为显式选项
- 命名空间未就绪时先显示 loading，避免先发一次全集群查询
- 5 条查询改**分批（每批 2 条）**执行 + 429 自动重试一次
=== 三、后端并发/超时调整 ===
- 重查询并发上限 2 → 4，且拿不到令牌时**排队最多 10s**再拒绝
（原来立即 429，导致分析页 5 条并发里有 3 条直接失败）
- maxLogQueryLimit 1000 → 5000，与前端下拉完全对齐（原来前端选 5000 会被静默截断）
=== 四、过期 chunk 真正删除（关键修复）===
实测发现：索引表已从 COS 删除，但 chunk 对象仍残留 21,354 个 / 24.8 GB，
最老的 45 小时前 —— 因为 Loki 默认 `retention_delete_delay` = **2h**，
标记后要等 2 小时才真正删 chunk。
- 配置显式设置 `compactor.retention_delete_delay: 10m`
- 已用 `loki -verify-config` 校验（config is valid）
- 删除前后对比：
对象数 46,536 → 23,934；占用 53.61 GB → 27.25 GB
超期对象 21,354 个 / 24.8 GB → **0 个**
桶内最老对象 45.2h → 24.4h（= 保留期 1 天）
- deployment_config_test 同步调整：retention_delete_delay 从"禁止出现"移入"必须存在"
镜像：lghost/lokistack:latest + v0.1 = sha256:b4d98e016bca
|
2026-10-28 17:05:57 +00:00 |
|
|
opsx
|
2da0a2bece
|
feat(analysis): Ingress 访问分析卡 — 自动加载、无 ingress 自动折叠
- 新增常驻「Ingress 访问分析」卡:自动探测 ingress-nginx/ingress 命名空间并聚合访问日志
(PV/UV、4xx/5xx、慢请求、接口排行、异常/慢请求 Top10、请求明细),随数据源与时间范围刷新
- 从历史恢复 ingress 洞察表与聚合工具到 analysis 域(ingress-access-log 解析已在 lib)
- 折叠交互:未检测到 ingress-nginx 时自动收起并显示徽章;手动切换记入 localStorage 优先生效
|
2026-10-28 22:43:57 +08:00 |
|
|
opsx
|
5ce90fe2e5
|
fix(analysis): 去掉原始日志底栏与命名空间筛选
按产品/设计锁死：删底部 goQuery 虚线卡（表内「查看日志」保留）；筛选栏去掉命名空间下拉与 labelValues 加载，指标固定全命名空间聚合。
|
2026-10-28 22:06:38 +08:00 |
|
|
Codex
|
016d3ecdfd
|
feat(frontend): analysis/logs 筛选下拉改可搜索 Select
数据源换 ui/select；命名空间复用 SearchableValueSelect 工具条态（可搜、全部置顶、loading）；与 ahead 功能 tip 分开。
|
2026-10-28 22:02:45 +08:00 |
|
|
Codex
|
f993d5b420
|
fix(frontend): logs/analysis P0 — 职责拆分与布局收口
砍 analysis 明细可视化改「去日志查询」；无数据源 EmptyState；日图标固定近7天。
logs 去掉负 margin、页头常显、筛选/查询分层；level 色阶；Label 保持默认收起。
|
2026-10-28 21:54:40 +08:00 |
|