lablink_allocator_service.routes.vm_telemetry¶
lablink_allocator_service.routes.vm_telemetry
¶
VM telemetry: client-VM writes and the operator's read side.
Both directions over the same columns live here on purpose — POST and GET
/api/vm-status are two ends of one column, and splitting them by auth
gate would scatter one concern across two files.
Auth differs per direction, so read the decorators carefully:
@require_client_secret for anything a client VM pushes,
@auth.login_required for anything an operator reads.
Attributes¶
MAX_LOG_SIZE = 1 * 1024 * 1024
module-attribute
¶
bp = Blueprint('vm_telemetry', __name__)
module-attribute
¶
logger = logging.getLogger(__name__)
module-attribute
¶
Functions:¶
get_all_vm_status()
¶
Get the status of all VMs.
Returns a JSON object mapping each VM hostname to its current status. Used by the admin dashboard.
Success Response:
- Code:
200 OK - Content:
Error Response:
- Code:
404 Not Foundif no VMs are found in the database. - Code:
500 Internal Server Erroron failure.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
get_vm_logs_by_hostname(hostname)
¶
Get the stored logs for a specific VM.
Used by the admin log viewer page.
URL Parameters:
hostname(string, required): The hostname of the VM.
Query Parameters:
errors_only(boolean, optional, defaultfalse): Whentrue, bothcloud_init_logsanddocker_logsare reduced to their error lines — lines carrying an uppercase level token (ERROR,CRITICAL,FATAL, plus cloudflared'sERR/FTLand postgres'PANIC), together with any traceback that follows them. Matching is case-sensitive so the client startup script's--retry-all-errorsandstatus=errorlines are not treated as errors, and a short denylist suppresses client reporting-path failures that do not affect the VM's usability (GPU-health and in-use-status report failures, and session-metrics push failures). A stream with no error lines becomes"", notnull.
Success Response:
- Code:
200 OK - Content:
Error Response:
- Code:
404 Not Foundif the VM is not found. - Code:
503 Service Unavailableif the logs are not yet available because the VM's log shipper has not started reporting yet. - Code:
500 Internal Server Erroron failure.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
heartbeat()
¶
Record a client-VM liveness heartbeat.
Periodic liveness ping. Lets the allocator detect silent failures — a dead container, a broken network, a hung host, an OOM, or an out-of-band VM termination — that no other endpoint would reveal. The body also carries cheap health signals for early warning.
Auth: Client secret (resolved from the vm_id field).
Request Body: application/json
Client Usage: Sent by the client's heartbeat service every
HEARTBEAT_INTERVAL_SECONDS. A client that stops heartbeating for longer
than the staleness window becomes eligible for automatic recovery.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
receive_vm_logs(hostname)
¶
Receive and store logs pushed from a VM.
Receives batched log lines pushed from a VM by the log_shipper.sh
script, which tails the VM's cloud-init output and the client
container's Docker logs.
URL Parameters:
hostname(string, required): The hostname of the VM.
Request Body: application/json
{
"log_group": "/aws/ec2/lablink",
"log_stream": "lablink-vm-prod-1",
"messages": ["log line 1", "log line 2"]
}
Success Response:
- Code:
200 OK - Content:
{"message": "VM logs posted successfully."}
Error Response:
- Code:
400 Bad Requestif required fields are missing. - Code:
404 Not Foundif the VM does not exist. - Code:
500 Internal Server Erroron failure.
Client Usage: Not called directly from packages/client code. The
log_shipper.sh script, installed on each VM by the OpenTofu user-data
script, tails the VM's cloud-init output log and the client
container's Docker logs, batches new lines, and POSTs them here. ANSI
escapes are stripped and each log type is capped at 1MB.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 | |
receive_vm_metrics(hostname)
¶
Receive and store startup metrics from a VM.
Called by the client VM to post timing metrics for cloud-init and
container startup.
URL Parameters:
hostname(string, required): The hostname of the VM reporting metrics.
Request Body: application/json
Success Response:
- Code:
200 OK - Content:
{"message": "VM metrics posted successfully."}
Error Response:
- Code:
404 Not Foundif the VM does not exist. - Code:
500 Internal Server Erroron failure.
Client Usage: user_data.sh posts cloud-init timings during boot,
and the client container's start.sh entrypoint posts its own start/end
times at the end of its startup sequence. This helps in monitoring
startup duration.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
update_gpu_health()
¶
Update the GPU health status of a VM.
Request Body: application/json
Success Response:
- Code:
200 OK - Content:
{"message": "GPU health status updated successfully."}
Error Response:
- Code:
400 Bad Requestifhostnameorgpu_statusis missing. - Code:
500 Internal Server Erroron failure.
Client Usage: Called by the check_gpu service, which is started by
start.sh and runs continuously. The service periodically runs
nvidia-smi, determines the GPU status (Healthy, Unhealthy, or
N/A), and reports whenever the status changes. The value lands in the
Healthy column — the auto-reboot service decides what to do about an
unhealthy VM.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
update_inuse_status()
¶
Update the in-use status of a VM.
Called by the client VM to indicate whether a user is actively using it.
Request Body: application/json
Success Response:
- Code:
200 OK - Content:
{"message": "In-use status updated successfully."}
Error Response:
- Code:
400 Bad Requestifhostnameorstatusis missing. - Code:
500 Internal Server Erroron failure.
Client Usage: Called by the update_inuse_status service, which is
started by start.sh and runs continuously. The service monitors for the
presence of the research software process (e.g., sleap). When the
process starts, it sends status: true; when it stops, status: false.
This lets the allocator know if a user is actively using the VM.
Source code in packages/allocator/src/lablink_allocator_service/routes/vm_telemetry.py
update_vm_status()
¶
Update the overall status of a VM.
Called by the client VM during its startup sequence to report its
current status (initializing, running, error, rebooting).
Request Body: application/json
Success Response:
- Code:
200 OK - Content:
{"message": "VM status updated successfully."}
Error Response:
- Code:
400 Bad Requestifhostnameorstatusis missing. - Code:
500 Internal Server Erroron failure.
Client Usage: Not called from the packages/client code. It is
called by the user_data.sh script during the client VM's initial boot
sequence (cloud-init), which reports initializing, running, and
error statuses so the allocator can track the VM's progress before the
client service container has started. An error trap in user_data.sh
automatically sends an error status if any command fails, which can
then trigger the auto-reboot service.