yldmdocs

可观测性 (observability)

observability 类把集群的指标、日志、链路集中在一处：Prometheus 收指标、Loki 收日志、Tempo 收链路，三路数据统一汇入 Grafana 展示。所有组件都由 ArgoCD 从 bootstrap/applications/observability/ 下的 Application 同步进各自独立的 namespace。

这一类大多是有状态的单副本服务，靠存储而非多副本保证可用性。Loki、Prometheus、Tempo 都是 replicas: 1；Grafana 无状态、可被 HPA 横向扩容。

三件套 + 展示

把四个服务按职责分成两组来理解：

  • Name
    指标 / 日志 / 链路 三件套
    Description
    Prometheus 抓 metrics、Loki 聚合日志、Tempo 存分布式 trace。三者是 Grafana 里三个并列的数据源（prometheus-main / loki-main / tempo-main），可在同一界面下钻、互相跳转（trace ID 关联日志与指标）。
  • Name
    展示层 Grafana
    Description
    唯一的可视化与告警面板入口，预置了 K8s、节点、APM、Loki、Tempo 以及各业务服务日志的 dashboard，并把 Prometheus / Loki / Tempo 配成数据源。

组件清单

下表是四个服务从 manifest 中可核实的事实（镜像、副本、Service 端口、ingress host）：

服务镜像副本namespaceService 端口Ingress host
grafanagrafana/grafana:12.3.6-security-041grafana3000grafana.yldm.tech
lokigrafana/loki:3.7.21loki3100—
prometheusquay.io/prometheus/prometheus:v3.12.01prometheus9090prometheus.yldm.tech
tempografana/tempo:3.0.21tempo3200—
  • Name
    grafana
    Description
    单副本 Deployment（Recreate 策略：单个 SQLite grafana.db 落在 Longhorn PVC 上，不能水平扩容，否则两个 Grafana 写同一个 db 会锁冲突/损坏），配 PDB maxUnavailable: 1。管理员凭据与 OAuth（Dex SSO，Vault key dex/clients/grafana）走 ExternalSecret，数据盘每天 02:00 由 backup-grafana CronJob 备份。
  • Name
    loki
    Description
    单副本 Deployment + DaemonSet promtail（grafana/promtail:3.6.11，每节点采日志推到 loki:3100/loki/api/v1/push）。数据 PVC 50Gi、local-path(RWO，钉节点)，配 VPA（updateMode: Recreate）与 PDB。
  • Name
    prometheus
    Description
    基于 kube-prometheus-stack（operator + node-exporter + kube-state-metrics + Alertmanager）。Prometheus retention 15d。大量 PrometheusRule（SLO、K8s system、node-exporter 等）与 ServiceMonitor（traefik、etcd、velero、consul、生产应用）随包提供。prometheus.yldm.tech 前挂 oauth2-proxy（v7.15.3）做 SSO；Alertmanager 走 alertmanager.yldm.tech，Telegram 通知凭据来自 Vault monitoring/alertmanager/telegram。多个组件配了 VPA。
  • Name
    tempo
    Description
    单副本，接收 OTLP（HTTP 4318 / gRPC 4317）和 Jaeger（HTTP 14268 / gRPC 14250）链路；HTTP API 在 3200。metrics_generator 会把 trace 派生的指标 remote-write 回 Prometheus。数据 PVC 50Gi、local-path(RWO)，钉在数据库节点本地盘上。配 ServiceMonitor 与 PrometheusRule。详见下方深度页。
Tempo 链路追踪深度页

数据如何流动

三类遥测数据各走各的采集路径，最后都在 Grafana 汇合：

  • 指标：被监控对象暴露 /metrics → ServiceMonitor 选中 → Prometheus 抓取存储（15d）→ Grafana 数据源 prometheus-main 读取。Tempo 的 metrics_generator 还会把链路派生指标 remote-write 进 Prometheus。
  • 日志：每节点的 promtail DaemonSet 采集容器日志 → 推送到 Loki（:3100）→ Grafana 数据源 loki-main 查询。
  • 链路：应用通过 OTLP / Jaeger 协议把 trace 发到 Tempo（:4317/:4318/:14268/:14250）→ Grafana 数据源 tempo-main 查询，并能用 trace ID 关联回 Loki 日志和 Prometheus 指标。

访问入口

对外暴露的面板都走 Traefik ingress（域名解析到 MetalLB 的 LoadBalancer IP）：

入口用途说明
grafana.yldm.tech统一可视化与告警Dex SSO 登录
prometheus.yldm.tech指标查询 / PromQL前置 oauth2-proxy 保护
alertmanager.yldm.tech告警路由（Telegram 通知）随 Prometheus 栈部署

Loki 与 Tempo 不对外开 ingress，仅在集群内被 Grafana 通过 ClusterIP Service 调用（Tempo 的查询 API 无内建认证，故只在集群内经 Grafana 数据源访问，不经 Cloudflare Tunnel 暴露）。更上层的架构和 GitOps 同步机制见 集群架构。

评论