yldmdocs

snuba · Sentry 的事件分析与查询层

snuba 是 getsentry/snuba 在本集群的自托管部署，作为 Sentry 的事件分析后端：它从 Kafka 消费事件、写入 ClickHouse 列式数据库，并对外提供查询 API。整套部署放在独立的 snuba namespace，由四个 Deployment（snuba-api、snuba-consumer、snuba-outcomes-consumer、snuba-replacer）组成，全部使用同一镜像 getsentry/snuba:26.2.1，靠 command 区分各自角色。

这是无源码可读的上游二进制服务，下面只列 manifest 能验证的事实（镜像、副本、命令、端口、依赖的 Vault secret、NetworkPolicy 出入向）。本目录没有 kustomization.yaml，也没有 ServiceMonitor / HPA / VPA / PDB / Ingress。namespace 名义上归在 README 的 observability 类下，但 manifest 里所有 Pod 都调度到 workload: app 节点。

部署形态

  • Name
    namespace
    Description
    snuba（独立 namespace，namespace.yaml 带 kubernetes.io/metadata.name: snuba 标签，供 NetworkPolicy 的 namespaceSelector 命中）。
  • Name
    工作负载
    Description
    四个 Deployment，各 1 副本：snuba-api（查询 API）、snuba-consumer（errors 存储消费者）、snuba-outcomes-consumer（outcomes_raw 存储消费者）、snuba-replacer（errors 存储的 replacer）。
  • Name
    镜像与版本
    Description
    全部 getsentry/snuba:26.2.1。无 kustomization，因此镜像 tag 不受 argocd-image-updater 管理，需手工改 Deployment。
  • Name
    命令分工
    Description
    snuba-api: snuba api；snuba-consumer: snuba rust-consumer --storage=errors --consumer-group=snuba-consumers --auto-offset-reset=latest --no-strict-offset-reset；snuba-outcomes-consumer: snuba rust-consumer --storage=outcomes_raw --consumer-group=snuba-outcomes-consumers --auto-offset-reset=latest --no-strict-offset-reset；snuba-replacer: snuba replacer --storage=errors --auto-offset-reset=latest --no-strict-offset-reset。
  • Name
    调度
    Description
    所有 Deployment 均 nodeSelector: workload=app。没有 podAntiAffinity（单副本，无需打散）。
  • Name
    端口
    Description
    仅 snuba-api 暴露 HTTP 1218（containerPort name http）；三个消费者类 Deployment 不开端口。
  • Name
    资源
    Description
    每容器 requests 100m / 256Mi。limits：snuba-api 与 snuba-consumer 为 500m / 1Gi，snuba-outcomes-consumer 与 snuba-replacer 为 500m / 512Mi。namespace 级 ResourceQuota 上限 requests 2 CPU / 4Gi、limits 4 CPU / 8Gi；LimitRange 给未声明的容器默认 500m / 1Gi（request 100m / 256Mi）。
  • Name
    存储
    Description
    无 PVC。snuba 自身无状态，数据落在外部的 ClickHouse / Kafka / Redis。

配置与依赖

四个 Deployment 共享同一组环境变量来连接外部依赖，没有 ConfigMap，配置走 env 与上游内置的 SNUBA_SETTINGS=docker profile。

  • Name
    ClickHouse
    Description
    CLICKHOUSE_HOST=clickhouse.clickhouse.svc.cluster.local、CLICKHOUSE_PORT=9000（NetworkPolicy 还放行到 ClickHouse 的 8123 HTTP 端口）。列式存储后端，事件最终写到这里。
  • Name
    Kafka
    Description
    DEFAULT_BROKERS=kafka.kafka.svc.cluster.local:9092。消费者从这里拉取 errors / outcomes 事件流。
  • Name
    Redis
    Description
    REDIS_HOST / REDIS_PORT / REDIS_PASSWORD 三项均来自 Secret snuba-secret，由 ExternalSecret 从 Vault 拉取。
  • Name
    ExternalSecret
    Description
    snuba-secret 经 ClusterSecretStore vault-backend 从 yldm/production/sentry 取 redis_host / redis_port / redis_password 三个 property（refreshInterval: 1h，creationPolicy: Owner）。注意：snuba 复用的是 Sentry 的 Redis 凭据路径，而非独立的 yldm/production/snuba。
  • Name
    snuba-api 额外 env
    Description
    UWSGI_MAX_REQUESTS=10000、UWSGI_DISABLE_LOGGING=true。

访问与监控

  • Name
    Service
    Description
    snuba，ClusterIP，端口 1218 → 1218（name http），selector app=snuba, component=api——只选中 snuba-api，三个消费者不在 Service 后端。集群内消费方用 snuba.snuba.svc.cluster.local:1218。
  • Name
    Ingress
    Description
    无。snuba 不对外暴露，只在集群内被 Sentry 访问。
  • Name
    健康检查
    Description
    仅 snuba-api 配了探针：liveness / readiness 都打 GET /health:1218（liveness initialDelaySeconds 30 / period 10，readiness initialDelaySeconds 10 / period 5）。消费者类 Deployment 无探针。
  • Name
    NetworkPolicy
    Description
    snuba（podSelector app=snuba，含 Ingress + Egress）。Ingress：只允许来自 sentry namespace 到 1218。Egress：放行到 clickhouse namespace 的 8123/9000、kafka namespace 的 9092、redis namespace 的 6379，以及 kube-system 的 DNS UDP 53。
  • Name
    监控/伸缩
    Description
    无 ServiceMonitor、PrometheusRule、HPA、VPA、PDB。

返回 observability 总览

评论