yldmdocs

可观测性 (observability)

observability 类把集群的指标、日志、链路和错误追踪集中在一处：Prometheus 收指标、Loki 收日志、Tempo 收链路，三路数据统一汇入 Grafana 展示；Sentry（背靠 Snuba + ClickHouse）单独负责应用错误追踪。所有组件都由 ArgoCD 从 bootstrap/applications/observability/ 下的 Application 同步进各自独立的 namespace。

这一类大多是有状态的单副本服务，靠存储而非多副本保证可用性。Loki、Prometheus、Tempo 都是 replicas: 1；Grafana 无状态、可被 HPA 横向扩容；Sentry/Snuba 则是多个 Deployment（web/worker/cron、api/consumer/replacer）组合而成。

三件套 + 展示 + 错误追踪

把六个服务按职责分成三组来理解：

  • 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 配成数据源。
  • Name
    错误追踪 Sentry + Snuba
    Description
    Sentry 接收应用上报的异常事件；Snuba 是 Sentry 的查询/存储层，把事件写入并查询 ClickHouse。两者配套部署，缺一不可。

组件清单

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

服务镜像副本namespaceService 端口Ingress host
grafanagrafana/grafana:12.3.6-security-04HPA 1–3grafana3000grafana.yldm.tech
lokigrafana/loki:3.7.21loki3100—
prometheusquay.io/prometheus/prometheus:v3.12.01prometheus9090prometheus.yldm.tech
sentrygetsentry/sentry:24.11.0web 2 / worker 2 / cron 1sentry9000sentry.yldm.tech
snubagetsentry/snuba:26.2.1api/consumer/replacer/outcomes 各 1snuba1218—
tempografana/tempo:3.0.21tempo3200tempo.yldm.tech
  • Name
    grafana
    Description
    无状态 Deployment，由 grafana-hpa（CPU 触发，minReplicas: 1 / maxReplicas: 3）扩容，配 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、nfs-client(RWX)，配 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
    sentry
    Description
    三类 Deployment：sentry-web(×2)、sentry-worker(×2)、sentry-cron(×1)，加一个 sentry-init Job。依赖 PostgreSQL、Redis、Kafka（kafka.kafka.svc.cluster.local:9092）和 Snuba（snuba.snuba.svc.cluster.local）。配置全部来自 Vault yldm/production/sentry。数据 PVC + PDB。
  • Name
    snuba
    Description
    四个 Deployment：snuba-api(:1218)、snuba-consumer、snuba-replacer、snuba-outcomes-consumer。后端是 ClickHouse（clickhouse.clickhouse.svc.cluster.local）+ Kafka + Redis。与 Sentry 共用 Vault key yldm/production/sentry。
  • 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 指标。
  • 错误：应用 SDK 上报异常到 Sentry（:9000）→ Sentry 经 Kafka 把事件交给 Snuba → Snuba 写入并查询 ClickHouse → Sentry web 界面展示。
Sentry/Snuba 这条链路依赖的 PostgreSQL、Redis、Kafka、ClickHouse 都不在本类里，属于 数据层 与 消息队列。错误追踪要正常工作，这些后端必须先就绪。

访问入口

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

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

Loki 与 Snuba 不对外开 ingress，仅在集群内被 Grafana / Sentry 等通过 ClusterIP Service 调用。更上层的架构和 GitOps 同步机制见 集群架构。

评论