monitoring-feature-observability

name	monitoring-feature-observability
description	Add or adjust monitoring for a Hypeman feature using repository standards for logs, traces, and metrics. Use when a user asks for instrumentation, observability reviews, telemetry consistency changes, metric design, or production-signal improvements.

Monitoring Feature Observability

Your task is to add monitoring for a specific feature or to perform a specific monitoring-related ask from the user.

Logging

• Logging uses structured slog JSON with per-subsystem levels (LOG_LEVEL, LOG_LEVEL_<SUBSYSTEM>). Logs are enriched with subsystem, and when trace context exists, trace_id/span_id: lib/logger/logger.go.
• During normal running of the system without requests or events being sent to the system, there should be minimal to no logging at the INFO level or greater. So ongoing maintenance items should not be logging at INFO or greater.
• During a request (for example, API call) or interrupt/event (for example, guest program stops), the normal case should have about one informative log at INFO level, usually just one log.
• Other useful but normal information within a single request/event should be at DEBUG level accordingly. Do not use TRACE level.
• Logs resulting from a single request or event should not provide much duplicated information.
• Logs with instance_id are also duplicated into per-instance logs/hypeman.log, and instance log APIs stream them, so be sure to set instance_id or other resourcetype_id accordingly.
• Use WARN and ERROR logs appropriately.
• Logs should be associated with traces.

Tracing

• All API requests should support tracing.
• Tracing should span down as far as reasonable, ideally all the way down unless there is a good reason not to.