Logs, metrics and alarms
Inspect current workloads, narrow down recent logs and keep an inbox of unhealthy resources.
Open a service to inspect its pods, events, resource use and logs. Resource samples come from Kubernetes metrics-server. Missing or stale samples remain unavailable; they are not displayed as zero consumption.
The dashboard keeps a short, bounded series while a resource view is open. This is live inspection, not a retained historical metrics database. The default installation does not add Prometheus, Loki or Elasticsearch for these views.
Search recent logs#
The log explorer accepts a SQL-like predicate:
severity >= ERROR AND message ILIKE '%timeout%'
Use JSON fields when your application emits structured logs:
json.status >= 500 AND json.request.method IN ('GET', 'POST')
Fields include timestamp, message, severity, pod, container and service. Nested JSON fields use json.field notation. Combine comparisons with AND, OR, NOT and parentheses. LIKE uses percent for a sequence and underscore for one character; ILIKE ignores case. Missing JSON fields need an explicit IS NULL check.
This is a filter language, not SQL access to a database. SELECT statements, joins, functions and writes are not supported. Plain-text log lines retain DEFAULT severity even when their message contains the word “error.”
hakopod logs shop --service api --query "severity >= ERROR" --since 1h
hakopod logs shop --service api --pod POD_NAME --previous --tail 500
Search samples up to eight newest pods, or an explicitly selected pod/container. A histogram counts matching lines in that sampled window. Respect truncation notices: Kubernetes rotation, deleted pods and node loss can remove logs, and a requested window can be at most 24 hours. A bounded search cannot be combined with --follow.
Act on runtime alarms#
The inbox tracks application readiness, service readiness and node conditions including NotReady, DiskPressure, MemoryPressure and PIDPressure. It evaluates runtime observations even while the dashboard is closed.
By default, a condition must stay unhealthy for 120 seconds before firing. Fresh healthy observations recover an active incident. Unknown or stale observations do not claim recovery. Acknowledging an alarm marks your response; it does not fix the workload or silence a future episode.
Application settings inherit from the environment, then the project. Installation settings apply to node conditions. Edit a scope's enabled rules and hold interval where you have the required permissions.
Enable email deliberately#
Inbox rules are enabled by default; email is off. The installation operator must configure the external SMTP provider, and an authorized user must enable email at the appropriate scope. Production SMTP uses STARTTLS and validates the server certificate.
Recipients are enabled, verified accounts that currently have access to the affected resources. Application email groups service failures rather than sending a separate message for every service. Configuration indicates delivery is available; it does not prove receipt by an external mailbox. Retries can occasionally duplicate a message after a process interruption.
Open a terminal when needed#
Choose a running pod in the service inspector. The default executable is /bin/sh; the image must actually contain it. Database presets use a client already in the container. Hakopod does not install debugging tools or put database passwords into terminal commands.
hakopod terminal shop --service api --pod POD_NAME
Container terminals require a human session with deployment-write permission. CI keys cannot open them. Sessions are tied to the exact pod and credential, expire after ten minutes and close when access is revoked or the connection ends. A process deliberately detached inside a container may continue after disconnection.
Node and management-host terminals are a separate, tightly restricted operator permission. They are not implied by ordinary service access. Remember that application logs and interactive commands can expose injected secrets; grant access accordingly.