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 |
|