rlwj-lab/LokiStack
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
63 Commits 1 Branch 1 Tag
fbefcc86dfb6084c196e24dbea331bd3f08f7eda
Commit Graph
6 Commits
Author SHA1 Message Date
hermes-agent 7e3356e32b feat(collectors): 主机采集器容器优先托管 + 采集器日志查看 + 推送地址纠正 
现象
1. 主机采集器只有 systemd 一条路，跨发行版差异大（这轮已踩过 param 被删、日志路径、
   时间戳格式三处）；进程存活/开机自启也没有统一保证。
2. 「采集器日志」在主机模式下无法从平台查看，排「起没起来/在报什么错」必须 SSH。
3. 实测发现：Loki 部署把 listenIP 填成 0.0.0.0 时，部署记录 endpoint 是
   http://0.0.0.0:3100，采集器照抄去推 -> connect: connection refused，
   而容器/systemd 都是 running、平台 status=active —— 日志静默丢失。

根因
1. 托管方式写死在代码里（promtail 二进制 + systemd 单元），没有能力探测。
2. 没有对外暴露采集器自身日志的接口。
3. 渲染 promtail 配置时直接用 deployment.Endpoint，没有校验它是不是「可连接的推送地址」；
   另外容器用 bridge 网络，127.0.0.1 在容器里指向容器自身，同机 Loki 也会推失败。

修法
- services/collector_host_runtime.go（新增）
  * detectHostCapabilities：一次 SSH 往返探测 架构/init/systemd/docker可用/开机自启/SELinux/journald
  * chooseHostRunMode：docker 优先 -> systemd 兜底 -> 两者都没有则明确报错（不裸跑进程）
  * installHostDocker：grafana/promtail:3.4.0 容器，--restart=always --memory=256m --cpus=1
    --log-opt max-size=10m,max-file=3，挂 /etc/promtail(:ro) /var/lib/promtail /var/log(:ro)
    (+journald 相关)，SELinux Enforcing 时 --security-opt label=disable；
    先 docker run --rm -check-syntax 校验配置，再替换正式配置
  * waitContainerRunning：看 Status + RestartCount，起来就崩立即报错并带回 docker logs
  * hostPushEndpoint：0.0.0.0/:: 换真实主机 IP；容器模式下 127.0.0.1/localhost 也换；
    换不了明确报错
  * CollectorLogs：主机 docker logs / journalctl，K8s DaemonSet Pod 日志、Sidecar fluent-bit 容器日志
- collector_deployer.go：installHost 探测->选模式->渲染配置->分发；systemd 路径从 docker 迁回时
  清理同名容器；卸载时容器与 systemd 两种方式都清（RunMode 对老记录是空的）
- 拉不到镜像（内网无外网）时降级 systemd 二进制托管，其它错误原样抛出
- models/collector.go：新增 runMode 并纳入 Sanitized；services.Update 白名单同步
- 接口 GET /api/v1/collectors/:id/logs?tail=N；前端卡片加「运行方式」+「日志」弹窗
- build.sh：detect_go 的 INFO 走 stderr（原来被打进 GO_CMD，构建必失败）

验证（172.19.16.8 / pre-cex-ops-jenkins，collector id=2）
- 安装后 runMode=docker，容器 Up，RestartPolicy=always，systemd promtail 自动停用
- 推送地址自动纠正为 http://172.19.16.8:3100，Loki 近 10 分钟查到 4919 条
  job=system/job=app、host=pre-cex-ops-jenkins
- docker 垫片模拟「docker 不可用」-> 自动回退 runMode=systemd、unit active+enabled、
  日志接口 source=systemd；移除垫片重装 -> 切回 docker
- 卸载：容器 0 个、unit 文件不存在、/etc/promtail 不存在、runMode 清空；重装恢复 running/0 重启
- K8s 采集器日志接口 source=kubernetes（顺带暴露 429 限流，见后续日志量治理）
- go vet 干净；go test ./... 全绿（新增 chooseHostRunMode / hostPushEndpoint 等 6 组用例）；
  tsc -b 通过
- 镜像 lghost/lokistack:latest = :v0.1 = sha256:906a6d5369d7，Pod imageID 一致
 2026-10-28 20:01:38 +00:00
opsx c983d0e3c1 feat(collectors): 可编辑采集配置（B 档结构化编辑器）+ 修 host 标签 / syslog 时间戳 
=== 一、两个线上 bug（172.19.16.8 真机取证）===

1) host 标签是字面量 ${HOSTNAME}
   Promtail 不做环境变量展开（除非 -config.expand-env + systemd Environment），
   实测 21,825 条日志的 host 全是 "${HOSTNAME}"，无法按主机过滤。
   → 安装时 `hostname -s` 探测真实主机名并渲染进配置，结果存 Collector.ResolvedHostname，
     让「预览配置」与线上一致。

2) 系统日志时间戳解析失效
   TencentOS 4 的 /var/log/messages 是 ISO8601（2026-07-17T15:38:24.923784+08:00），
   旧正则按传统 syslog（Oct 28 18:11:06）写死 → timestamp 阶段匹配不上，用的是采集时间，
   回填历史日志时间全错。
   → 安装时探测目标机格式：iso8601 → RFC3339Nano；rfc3164 → Jan _2 15:04:05 + Local；
     系统日志路径同时探测（Ubuntu 没有 messages，写死会一条都采不到）。

   实测：写一条 10 分钟前的 ISO8601 探针行，Loki 里 loki_ts 与该行自身时间偏差 **0 秒**；
   另写一条 2 小时前的被 Loki 以 entry too far behind 拒绝 —— 恰好反证时间戳是按事件时间
   解析后推送的（旧实现会用采集时间，反而被接收）。

=== 二、B 档：结构化多 Job 编辑器 ===

后端
- models/scrape_job.go：ScrapeJob + ValidateScrapeJobs
  校验 job 名格式、绝对路径、**敏感路径拦截**（/etc/shadow、/etc/sudoers、/root/.ssh、
  id_rsa、*.pem…）、正则可编译、job/host/__path__ 保留标签名、数量上限。
- services/promtail_host_config.go：多 job 渲染；多路径展开成多个 static_configs；
  pipeline 顺序硬约束 cri → multiline → json → timestamp → drop → limit；
  encoding 写在 scrape_config 级（放进 static_configs 里 promtail 直接起不来）。
- services/host_profile.go：探测 distro / init / hostname / 时区 / 架构 / journald
  与真实存在的系统日志路径。
- CollectorService：renderConfig 实时渲染、PreviewConfig（只渲染不落库）、
  Update 支持 scrapeJobs 并校验、安装结果（hostname/syslog 格式/配置快照）落库。
- 新增 POST /api/v1/collectors/:id/preview → {config, warnings, hostname, syslogFormat}。
- installHost：配置先写 .new + `promtail -check-syntax` 通过才替换，重启后轮询
  systemctl is-active，失败把 journalctl 尾部带回前端。

前端
- 采集项结构化编辑器：名称/路径/标签常驻，多行合并 / JSON / 自定义时间戳 / 命中丢弃 /
  限流折叠在「高级」里；「预览 YAML」弹窗在保存前看到将要下发的配置。
- 本地即时校验 + 旧数据（只有 logPath）自动迁移成 app + system 两个采集项。

=== 三、验证（host-verify-promtail @172.19.16.8）===
- 预览：host=pre-cex-ops-jenkins（无 ${HOSTNAME}），2 job / 3 条系统日志路径 /
  ISO8601 正则 / 多行 + drop + 限流 全部按填写渲染。
- 部署：promtail active、NRestarts=0、-check-syntax 通过，主机侧配置与预览逐行一致。
- Loki：新数据 host 全为 pre-cex-ops-jenkins；job=system 415 条/5min、job=app 40 条/5min。
- 负向 7/7 返回指名到字段的 400：/etc/shadow、/root/.ssh/id_rsa、相对路径、坏正则、
  job 名带空格、保留标签名、空路径。

镜像：lghost/lokistack:latest + v0.1 = sha256:26172f51187d
 2026-10-28 18:41:39 +00:00
opsx 02705382f1 fix(collector): Sanitized() 漏掉采集范围三字段，导致编辑框读不到配置 
背景：基于 f3733f0（品牌统一 + i18n 重构）构建部署后发现，采集器 API
返回里完全没有了 targetNamespaces / appLabelSource / appInclude 三个键。

根因：重构引入了 models.SanitizedJSON() + Collector.Sanitized()，
后者是**白名单式** map 输出，写的时候这三个字段还不存在，重构时也没补进去。
controller 全部走 SanitizedJSON(collector)，所以这三个字段被静默丢弃。

影响（比"少显示几个字段"严重）：
  编辑采集策略弹框读 collector.targetNamespaces 为 undefined
  → 命名空间面板显示"全集群采集"（实际配的是 astralx+log）
  → 用户只要点一次保存，就会把 targetNamespaces 写成 []
  → 下次「部署」生成的 Promtail 白名单消失，开始全集群采集（日志量暴涨）
  appLabelSource / appInclude 同理。

修复：Collector.Sanitized() 补三个字段。

验证：
  GET /api/v1/collectors/1
    targetNamespaces = ['astralx', 'log']   ← 修复前该键不存在
    appLabelSource   = ''
    appInclude       = null
  三个键均存在 ✅
  Promtail DaemonSet 12/12 未受影响 ✅
  Promtail ConfigMap 白名单（astralx, log）、app 四级回退、pod_phase drop 全部保留 ✅

镜像：lghost/lokistack:latest + v0.1 = sha256:648316ae13c5
 2026-10-27 10:30:21 +00:00
opsx 41633f0b38 feat(collector): 采集命名空间多选 + app 标签来源可自定义 + app 白名单 
=== 一、采集命名空间改为多选（原来只有文本输入）===
- CollectorEditDialog 重写：勾选式多选面板，从
  GET /clusters/:id/namespaces 拉取真实命名空间列表
- "所有命名空间（全集群采集）"一键全选（targetNamespaces 置空即全集群）
- 支持搜索过滤命名空间；已选数量实时显示
- 保存时为空数组 → Promtail 不加 namespaces 白名单

=== 二、app 标签取值来源可配置 ===
新增 Collector.AppLabelSource：
  留空（默认）= app.kubernetes.io/name → app → controller 名(去hash) → pod 名 四级回退
  可填任意 Pod 标签，如 app.kubernetes.io/name / app / k8s.kuboard.cn/name
  也可直接写 __meta_kubernetes_pod_label_xxx
  → 作为最高优先级插到回退链最前，其余仍兜底

模板侧新增：
  sanitizePromLabel()      标签名 → Prometheus meta label（. / 等转 _）
  promtailAppSourceLabel() 解析用户配置
  promtailAppIncludeFilter() 生成白名单 keep 规则

=== 三、app 白名单（控制采集量）===
新增 Collector.AppInclude []string：
  填了之后生成
    - source_labels: [app]
      regex: ^(app1|app2)$
      action: keep
  只保留匹配的日志流 —— 这是收敛日志量最直接的手段

service.Update 同步支持 appLabelSource / appInclude（兼容 []string 与逗号分隔字符串）。

前端 CollectorEditDialog：
  采集命名空间 = 勾选多选 + 全选
  app 标签取值来源 = 输入框 + 5 个常用值 datalist 提示
  只采集这些 app = 逗号分隔输入

镜像：lghost/lokistack:latest + v0.1 = sha256:43369d06cb28
 2026-10-27 03:55:13 +00:00
opsx e006fc1a0e fix(promtail): app 标签通用回退 + 跳过僵尸 Pod + SecretKey 不下发 + 采集命名空间可选 
=== 一、astralx 只采集到 2 个 app（核心问题）===
实证：用户的 Deployment Pod 模板只有 k8s.kuboard.cn/name 标签，
     没有 app / app.kubernetes.io/name。原模板的 app 只从这两个标签取，
     所以 115 个服务的 app 全是空值，Loki 里 app 只剩零星 2 个。

修复：app 四级回退，全部基于 Kubernetes 原生元数据（跨集群通用）：
  1) app.kubernetes.io/name   标准约定
  2) app                      常见简写
  3) __tmp_controller_name    Pod owner(ReplicaSet) 去 hash → Deployment 名
                              （__meta_kubernetes_pod_controller_name 由
                                Promtail 直接从 K8s API 读取，任何集群都有，
                                不依赖 Kuboard/Rancher 等第三方工具注入的标签）
  4) pod name                 兜底，保证 app 永不为空

同时修复 PromtailHelmValues 模板同样的 app 逻辑，
并修正其 __meta_kubernetes__pod_name 双下划线笔误。

验证：astralx 的 app 值从 2 个 → 73 个。

=== 二、15 分钟 27 万条日志的真相 ===
排查结论：不是重复采集（positions 存 hostPath /run/promtail，Pod 重启不丢）。
真实原因：cex-openapi-gateway 残留 347 个 Evicted + 37 个 Error 的僵尸 Pod，
        只有 1 个 Running。这些 Pod 的日志文件仍在 /var/log/pods/ 下，
        Promtail 会把它们的历史异常堆栈（Reactor at reactor.core.publisher...）
        全量采集，造成 27 万条的假象并污染存储。

修复：relabel_configs 首条加 drop 规则：
  - source_labels: [__meta_kubernetes_pod_phase]
    regex: (Succeeded|Failed)
    action: drop
（两个模板都加）

=== 三、SecretKey 不再下发给前端 ===
安全要求：避免任何登录用户点「显示」按钮就能拿到对象存储 SK。
- StorageConfig.Sanitized(): secretKey 返回空串，仅保留 hasSecretKey 标记
  （accessKey 仍明文返回，便于管理员核对用的是哪个 AK）
- 测试连接：StorageTestRequest 新增 id 字段，secretKey 留空时后端用
  库里保存的凭据解密补齐（新建存储仍强制填写）
- 前端编辑时 SecretKey 一律留空 = 不修改，placeholder 显示
  「已保存 · 留空则不修改」，测试时带上 id

=== 四、采集器支持指定命名空间 ===
- Collector 新增 TargetNamespaces []string，对应 promtail 的
  kubernetes_sd_configs.namespaces.names（为空=全集群）
- PromtailDaemonsetYAML 新增 promtailNamespaceFilter 生成白名单
- service.Update 支持 targetNamespaces（兼容 []string 与逗号分隔字符串）
- 前端 CollectorEditDialog 增加「采集命名空间」输入（逗号分隔）

镜像：lghost/lokistack:latest + v0.1 = sha256:05b1505aedae
 2026-10-27 03:30:25 +00:00
Logan.LiandClaude 673b2c60c8 feat: 新增「部署客户端」日志采集器模块 
三种采集器（host-promtail / k8s-daemonset / k8s-fluentbit-sidecar），每种关联已部署 Loki：
- host-promtail：SSH 安装 Promtail（复用 deployBinary）
- k8s-daemonset：helm 安装 Promtail DaemonSet（复用 deployHelm）
- k8s-fluentbit-sidecar：kubectl patch 注入 Fluent Bit sidecar

含 Collector 数据模型、三个部署器、配置模板、CRUD API、前端页面。
附带 UI 优化：ErrorBoundary、部署卡片浏览器访问按钮、菜单名称调整。

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-06-29 19:26:41 +08:00