=== 一、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
70 lines
2.8 KiB
Go
70 lines
2.8 KiB
Go
package models
|
||
|
||
import "time"
|
||
|
||
// Collector 日志采集器(部署客户端),关联一个已部署的 Loki 作为推送目标
|
||
type Collector struct {
|
||
ID uint `json:"id"`
|
||
Name string `json:"name"`
|
||
Type string `json:"type"` // host-promtail | k8s-daemonset | k8s-fluentbit-sidecar
|
||
LokiDeploymentID uint `json:"lokiDeploymentID"`
|
||
LokiDeployment *LokiDeployment `json:"lokiDeployment,omitempty"`
|
||
RefType string `json:"refType"` // host | cluster
|
||
HostID *uint `json:"hostID,omitempty"`
|
||
Host *Host `json:"host,omitempty"`
|
||
ClusterID *uint `json:"clusterID,omitempty"`
|
||
Cluster *Cluster `json:"cluster,omitempty"`
|
||
TargetDeployment string `json:"targetDeployment"` // sidecar 专用:目标 deployment 名
|
||
Namespace string `json:"namespace"` // 采集器自身部署所在的 k8s 命名空间
|
||
// TargetNamespaces 只采集这些命名空间的 Pod 日志;为空表示采集全集群。
|
||
// 对应 promtail 里 kubernetes_sd_configs.namespaces.names
|
||
TargetNamespaces []string `json:"targetNamespaces"`
|
||
LogPath string `json:"logPath"` // 采集日志路径
|
||
Labels string `json:"labels"` // 额外标签(JSON)
|
||
Status string `json:"status"` // pending | active | error
|
||
StatusMessage string `json:"statusMessage"`
|
||
Config string `json:"config"` // 生成的配置快照
|
||
CreatedAt time.Time `json:"createdAt"`
|
||
UpdatedAt time.Time `json:"updatedAt"`
|
||
}
|
||
|
||
func (c *Collector) Sanitized() map[string]interface{} {
|
||
var loki map[string]interface{}
|
||
if c.LokiDeployment != nil {
|
||
loki = map[string]interface{}{
|
||
"id": c.LokiDeployment.ID,
|
||
"name": c.LokiDeployment.Name,
|
||
"endpoint": c.LokiDeployment.Endpoint,
|
||
"status": c.LokiDeployment.Status,
|
||
}
|
||
}
|
||
var host map[string]interface{}
|
||
if c.Host != nil {
|
||
host = c.Host.Sanitized()
|
||
}
|
||
var cluster map[string]interface{}
|
||
if c.Cluster != nil {
|
||
cluster = c.Cluster.Sanitized()
|
||
}
|
||
return map[string]interface{}{
|
||
"id": c.ID,
|
||
"name": c.Name,
|
||
"type": c.Type,
|
||
"lokiDeploymentID": c.LokiDeploymentID,
|
||
"lokiDeployment": loki,
|
||
"refType": c.RefType,
|
||
"hostID": c.HostID,
|
||
"host": host,
|
||
"clusterID": c.ClusterID,
|
||
"cluster": cluster,
|
||
"targetDeployment": c.TargetDeployment,
|
||
"namespace": c.Namespace,
|
||
"logPath": c.LogPath,
|
||
"labels": c.Labels,
|
||
"status": c.Status,
|
||
"statusMessage": c.StatusMessage,
|
||
"createdAt": c.CreatedAt,
|
||
"updatedAt": c.UpdatedAt,
|
||
}
|
||
}
|