LokiStack

121 Commits 1 Branch 1 Tag

3 Commits

Include renames

Author	SHA1	Message	Date
opsx	c1f822fb10	refactor: 移除资源用量的可选 Prometheus 接入与平台监控页 CI / Frontend (lint + build + test) (push) Canceled after 0s Details CI / Backend (go vet + test) (push) Canceled after 0s Details - 资源用量弹窗:删除 applyPrometheus/promQueryValue 与峰值/限流字段 (LOKI_USAGE_PROMETHEUS_URL 从未内置,代码恒走降级),统一提示「未接入 Prometheus:暂无峰值/限流数据」;扩容建议改基于 metrics-server 实时值 - 移除「平台监控」菜单页与 /api/v1/system/metrics-summary; 原始指标保留在标准 /api/v1/metrics(Prometheus 文本格式)可自行抓取 - 手册/落地页/CHANGELOG 同步(去除备份恢复与监控页宣传,指标端点表述中性化)	2026-10-29 15:16:18 +08:00
opsx	572efc89a4	fix(reliability): 采集器并发去重 + 备份恢复即时重载 + context 贯穿请求链 - CollectorService 安装/卸载按采集器互斥去重(重复触发不再并发 docker rm/run 互踩);删除后卸载失败留日志 - ApplyStagedBackup 替换文件后立即 Reload 内存态,消除「重启前旧内存落盘覆盖恢复文件」竞态;暂存文件名升级 lokistack.json(兼容旧名) - GetUsage/Validate 全链路 context 贯穿:请求取消即中止 SSH/k8s 查询(异步调用点显式 Background)	2026-10-29 13:29:25 +08:00
opsx	bad2a1e624	fix(hosts,collectors,usage): 主机验证结果失真 + 主机模式系统日志解析 + metrics 单位 === 一、主机「测试连接」永远显示旧错误（真实 bug）=== HostService.Validate 的失败分支也写 status=active，且从不写 statusMessage： if info, err := client.GetHostInfo(ctx); err == nil { 更新 os/arch } else { s.Update(id, {status:"active"}) } // ← 失败也标记成功结果：连不上也显示正常，页面永远停在几分钟前的旧错误文案，用户改了 IP 再点测试，还以为"改了还是不行"。改为区分成功/失败并写清原因：成功 → status=active + os/arch + statusMessage="连接成功" 失败 → status=error + statusMessage=FormatSSHError(err) === 二、回环地址在平台里必然连不上 === 平台跑在容器/Pod 内，127.0.0.1 指向平台自身。 - 新建主机时拦截：hostIP 为 127.0.0.1/localhost/::1 直接报错并解释原因 - 前端表单同步校验 + 文案 - SSH 错误映射补充：连接被拒绝时提示可能是地址填了回环 === 三、主机模式采集系统日志（两处会导致采集失败）=== 1. pipeline 一律套 cri 阶段：cri 只认容器运行时格式，套在 /var/log/messages 这类 syslog 上会取不到时间戳、整行被丢。 → appPipelineStages() 按路径判断：容器日志用 cri，普通文本日志只做限流。 2. promtailExternalLabels 写死 8 空格缩进：主机模板 external_labels 只有 4 空格，一旦给采集器配置了标签就生成非法 YAML，Promtail 装不上。 → 增加 indent 参数，主机 6 空格 / DaemonSet 8 空格。 3. 新增 system 采集任务： /var/log/{messages,secure,cron,maillog,syslog,dmesg} 正则解析 syslog 时间戳（Jan _2 15:04:05，Asia/Shanghai）+ 限流测试：TestHostPromtailConfigValid / CRIPathKeepsCRIStage / PlainFileHasNoCRIStage TestPromtailManifestParses 全部通过 === 四、资源用量 CPU 解析（nanocores）=== metrics-server 返回的 CPU 常是纳核（如 "194533645n"=194.5m）。原解析只处理 "m"，导致 194 亿核、页面出现"CPU 已达 limit 的 4863341125%"。 → parseQuantityMilli 支持 n/u/m/整核实测：CPU 当前=178m，峰值=3300m，建议"峰值占 limit 82%，可考虑提前扩容" === 五、其他 === - 添加集群默认改用 Token 认证（最小权限、可随时吊销） - RBAC 片段补 metrics.k8s.io（资源面板需要，独立 API 组常被漏授） - 文案去掉 Grafana 需求描述（平台自身不部署 Grafana）镜像：lghost/lokistack:latest + v0.1 = sha256:7bddd0f4d1f1	2026-10-28 17:58:30 +00:00

Author

SHA1

Message

Date

opsx

c1f822fb10

refactor: 移除资源用量的可选 Prometheus 接入与平台监控页

CI / Frontend (lint + build + test) (push) Canceled after 0s

Details

CI / Backend (go vet + test) (push) Canceled after 0s

Details

- 资源用量弹窗:删除 applyPrometheus/promQueryValue 与峰值/限流字段
  (LOKI_USAGE_PROMETHEUS_URL 从未内置,代码恒走降级),统一提示
  「未接入 Prometheus:暂无峰值/限流数据」;扩容建议改基于 metrics-server 实时值
- 移除「平台监控」菜单页与 /api/v1/system/metrics-summary;
  原始指标保留在标准 /api/v1/metrics(Prometheus 文本格式)可自行抓取
- 手册/落地页/CHANGELOG 同步(去除备份恢复与监控页宣传,指标端点表述中性化)

2026-10-29 15:16:18 +08:00

opsx

572efc89a4

fix(reliability): 采集器并发去重 + 备份恢复即时重载 + context 贯穿请求链

- CollectorService 安装/卸载按采集器互斥去重(重复触发不再并发 docker rm/run 互踩);删除后卸载失败留日志
- ApplyStagedBackup 替换文件后立即 Reload 内存态,消除「重启前旧内存落盘覆盖恢复文件」竞态;暂存文件名升级 lokistack.json(兼容旧名)
- GetUsage/Validate 全链路 context 贯穿:请求取消即中止 SSH/k8s 查询(异步调用点显式 Background)

2026-10-29 13:29:25 +08:00

opsx

bad2a1e624

fix(hosts,collectors,usage): 主机验证结果失真 + 主机模式系统日志解析 + metrics 单位

=== 一、主机「测试连接」永远显示旧错误（真实 bug）===
HostService.Validate 的失败分支也写 status=active，且从不写 statusMessage：
    if info, err := client.GetHostInfo(ctx); err == nil { 更新 os/arch }
    else { s.Update(id, {status:"active"}) }   // ← 失败也标记成功
结果：连不上也显示正常，页面永远停在几分钟前的旧错误文案，
用户改了 IP 再点测试，还以为"改了还是不行"。

改为区分成功/失败并写清原因：
    成功 → status=active + os/arch + statusMessage="连接成功"
    失败 → status=error + statusMessage=FormatSSHError(err)

=== 二、回环地址在平台里必然连不上 ===
平台跑在容器/Pod 内，127.0.0.1 指向平台自身。
- 新建主机时拦截：hostIP 为 127.0.0.1/localhost/::1 直接报错并解释原因
- 前端表单同步校验 + 文案
- SSH 错误映射补充：连接被拒绝时提示可能是地址填了回环

=== 三、主机模式采集系统日志（两处会导致采集失败）===
1. pipeline 一律套 cri 阶段：cri 只认容器运行时格式，
   套在 /var/log/messages 这类 syslog 上会取不到时间戳、整行被丢。
   → appPipelineStages() 按路径判断：容器日志用 cri，普通文本日志只做限流。
2. promtailExternalLabels 写死 8 空格缩进：主机模板 external_labels 只有 4 空格，
   一旦给采集器配置了标签就生成非法 YAML，Promtail 装不上。
   → 增加 indent 参数，主机 6 空格 / DaemonSet 8 空格。
3. 新增 system 采集任务：
   /var/log/{messages,secure,cron,maillog,syslog,dmesg}
   正则解析 syslog 时间戳（Jan _2 15:04:05，Asia/Shanghai）+ 限流

测试：TestHostPromtailConfigValid / CRIPathKeepsCRIStage / PlainFileHasNoCRIStage
      TestPromtailManifestParses 全部通过

=== 四、资源用量 CPU 解析（nanocores）===
metrics-server 返回的 CPU 常是纳核（如 "194533645n"=194.5m）。
原解析只处理 "m"，导致 194 亿核、页面出现"CPU 已达 limit 的 4863341125%"。
→ parseQuantityMilli 支持 n/u/m/整核
实测：CPU 当前=178m，峰值=3300m，建议"峰值占 limit 82%，可考虑提前扩容"

=== 五、其他 ===
- 添加集群默认改用 Token 认证（最小权限、可随时吊销）
- RBAC 片段补 metrics.k8s.io（资源面板需要，独立 API 组常被漏授）
- 文案去掉 Grafana 需求描述（平台自身不部署 Grafana）

镜像：lghost/lokistack:latest + v0.1 = sha256:7bddd0f4d1f1

2026-10-28 17:58:30 +00:00