lablink_allocator_service.routes.health¶
lablink_allocator_service.routes.health
¶
Health and capacity reporting.
GET /api/health reports per-dependency readiness rather than a bare 200 so
a deployment stuck mid-startup is distinguishable from a healthy one: 200 +
"healthy" only once every check passes, 503 + "starting" otherwise.
GET /api/health/connections reports Postgres connection usage against the
configured maximum. Deliberately a separate route: /api/health is polled in
a tight loop by start.sh during boot and by lablink deploy afterwards, and
neither should pay for a Postgres aggregate to learn whether the service is up.
Attributes¶
bp = Blueprint('health', __name__)
module-attribute
¶
logger = logging.getLogger(__name__)
module-attribute
¶
Classes¶
Functions:¶
connection_health()
¶
Report PostgreSQL connection usage.
Reports usage against the server's configured maximum, for checking headroom before scaling a deployment up.
active_connections counts client backends only — the things
max_connections bounds — excluding the background-worker rows
pg_stat_activity also carries. It includes the connection serving this
request. max_connections is read from PostgreSQL, so it tracks
whatever is actually configured.
idle_in_transaction distinguishes a leaked pooled connection from
ordinary load; a non-zero value that doesn't fall back to zero is worth
investigating. It counts idle in transaction (aborted) too — an
aborted-but-open transaction pins locks just like a live one.
The same numbers appear on the /admin panel, which escalates to a
banner above 90%.
Success Response:
- Code:
200 OK - Content:
level is ok, warning above 80% utilization, or critical above
90%. High utilization still answers 200 — busy is not broken.
Error Response:
- Code:
503 Service Unavailablewith{"status": "unavailable"}when the numbers can't be read — the database isn't initialized yet, or the query failed (including a pool with no free connections). Never means the pool is merely busy.
Source code in packages/allocator/src/lablink_allocator_service/routes/health.py
connection_stats()
¶
Postgres client connection usage, or None if unreadable.
None rather than raising: both callers must degrade -- /admin renders "unavailable" and the JSON route answers 503.
Source code in packages/allocator/src/lablink_allocator_service/routes/health.py
health_check()
¶
Readiness check.
Auth: None — this is what load balancers, lablink deploy and lablink status poll.
Returns a structured readiness report rather than a bare 200. The
checks map always covers database, scheduler and reboot_service,
and gains a tailscale entry when the configured connectivity needs
one, or a tunnel entry for reverse-tunnel deployments.
Success Response:
- Code:
200 OKwhen every gating check isok - Content:
Error Response:
- Code:
503 Service Unavailablewith"status": "starting"when a gating check fails.
A dead client tunnel does not make the allocator unready: unattached client tunnels are reported but deliberately don't gate readiness — a registering client is unattached until its tunnel comes up. The allocator's own dependencies (tunnel server, database) do gate.
Source code in packages/allocator/src/lablink_allocator_service/routes/health.py
135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 | |