feat(snuba): healthcheck adjustments preparing for distroless

[oioki]

The snuba-api and consumer healthchecks shell out to /bin/bash, /bin/sh (via CMD-SHELL), and rm — none of which ship in the distroless snuba image. Setting SNUBA_IMAGE=ghcr.io/getsentry/snuba:nightly-distroless today produces:

OCI runtime exec failed: exec failed: ... "/bin/sh": no such file or directory

Replaces both healthchecks with Python scripts that use only python3 (already on PATH in both the regular and distroless image variants):

• snuba/healthcheck/api.py — GETs /health and asserts the body contains "ok". Same semantics as the previous bash + /dev/tcp probe.
• inline python script — deletes /tmp/health.txt, equivalent to the previous rm.

Both print a single-line stderr message on failure (e.g. snuba /health unreachable: [Errno 111] Connection refused) instead of a multi-line Python traceback, so docker inspect output stays readable while services are coming up.

Scripts are mounted via a single volumes: on x-snuba-defaults, so every snuba-* service inherits the mount automatically. The existing CA-cert override mechanism appends to the volumes list, so the two mounts coexist without conflict.

This was tested on our self-hosted instance, snuba-api and snuba-errors-consumer containers.

Benefits:

1. Less packages => more secure
2. Substantial decrease in image size:

ghcr.io/getsentry/snuba:nightly              abe01615a1a7       1.25GB             0B
ghcr.io/getsentry/snuba:nightly-distroless   5e219ac03d79        521MB             0B   U

3. Extra benefit is pythonic healthchecks produce human-readable responses, see at the bottom.

Cons:

1. Here be dragons

snuba-api

$ docker inspect sentry-self-hosted-snuba-api-1 | jq -r '.[0].State.Health.Log'
[
  {
    "Start": "2026-05-28T09:49:06.850261615-07:00",
    "End": "2026-05-28T09:49:23.917876298-07:00",
    "ExitCode": 1,
    "Output": "snuba api unreachable at http://127.0.0.1:1218/health: [Errno 111] Connection refused\n"
  },
  {
    "Start": "2026-05-28T09:49:53.918966729-07:00",
    "End": "2026-05-28T09:49:59.879922084-07:00",
    "ExitCode": 1,
    "Output": "snuba api unreachable at http://127.0.0.1:1218/health: [Errno 111] Connection refused\n"
  },
  {
    "Start": "2026-05-28T09:50:29.882185641-07:00",
    "End": "2026-05-28T09:50:34.125341371-07:00",
    "ExitCode": 1,
    "Output": "snuba api unreachable at http://127.0.0.1:1218/health: [Errno 111] Connection refused\n"
  },
  {
    "Start": "2026-05-28T09:51:04.126660248-07:00",
    "End": "2026-05-28T09:51:04.486342517-07:00",
    "ExitCode": 0,
    "Output": ""
  },
  {
    "Start": "2026-05-28T09:51:34.487846543-07:00",
    "End": "2026-05-28T09:51:34.702643283-07:00",
    "ExitCode": 0,
    "Output": ""
  }
]

snuba-errors-consumer

$ docker inspect sentry-self-hosted-snuba-errors-consumer-1 | jq -r '.[0].State.Health.Log'
[
  {
    "Start": "2026-05-28T09:50:26.350838447-07:00",
    "End": "2026-05-28T09:50:29.240829374-07:00",
    "ExitCode": 1,
    "Output": "consumer heartbeat file missing: /tmp/health.txt\n"
  },
  {
    "Start": "2026-05-28T09:50:34.246044319-07:00",
    "End": "2026-05-28T09:50:40.073553928-07:00",
    "ExitCode": 1,
    "Output": "consumer heartbeat file missing: /tmp/health.txt\n"
  },
  {
    "Start": "2026-05-28T09:50:45.074577311-07:00",
    "End": "2026-05-28T09:50:45.750771059-07:00",
    "ExitCode": 1,
    "Output": "consumer heartbeat file missing: /tmp/health.txt\n"
  },
  {
    "Start": "2026-05-28T09:50:50.751778994-07:00",
    "End": "2026-05-28T09:50:51.063516212-07:00",
    "ExitCode": 1,
    "Output": "consumer heartbeat file missing: /tmp/health.txt\n"
  },
  {
    "Start": "2026-05-28T09:50:56.071875071-07:00",
    "End": "2026-05-28T09:50:56.422598864-07:00",
    "ExitCode": 0,
    "Output": ""
  }
]

[aldy505]

Nope, this is going to problematic, as the monthly release would become ghcr.io/getsentry/snuba:26.6.0-distroless, which may not exist.

[aldy505]

It'd be best if this two is configurable through environment variables or other means. Editing the file here right away is a no-go, users shouldn't get into git conflict troubles.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2503d4e. Configure here.}

[oioki]

Tested on our self-hosted instance by switching snuba tag from :nightly to :nightly-distroless in .env file, all snuba components are "healthy".