Cluster Logs
The Logs tab in Clusters → Observability is the retained log explorer for VictoriaLogs.
Use it to search Kubernetes and application logs that have already been collected into the cluster log store.
Requirements
Section titled “Requirements”The Logs tab requires VictoriaLogs to be installed from Observability → Settings.
Until the service is installed, the tab stays in a not-installed state and links back to Settings.
What the Logs tab does
Section titled “What the Logs tab does”The explorer runs queries against the in-cluster VictoriaLogs service.
You can:
- run free-text queries
- run LogsQL filter expressions
- choose the lookback window
- choose the result limit
- apply quick filters based on values found in the current result set
- inspect normalized log formatting in a structured table
- open the VictoriaLogs UI when private UI exposure is configured
The Logs tab is intended for retained log search, not raw kubectl logs
streaming.
Query behavior
Section titled “Query behavior”Edka runs queries against the VictoriaLogs API using:
- the query string from the search bar
- a selected lookback window
- a selected row limit
- any active quick-filter clauses
If the current query returns no log entries, the UI shows that explicitly instead of treating the search as a transport failure.
When the current result set hits the row cap, Edka tells you the response was capped so you can narrow the time window or query.
Quick filters
Section titled “Quick filters”The Logs tab builds quick filters from the current result set.
Current quick filters cover:
- namespace
- pod
- container
- HTTP method
- request path
- status code
These filters are generated from the fields already present in the returned log entries, then reapplied as exact-match clauses on the next query.
This is useful when you start with a broad query such as error, then narrow
to a single namespace, pod, or response class without manually writing the
field filters yourself.
Log formatting
Section titled “Log formatting”Edka normalizes common log shapes before rendering them in the result table.
For example, if a log line contains structured request metadata, the table can promote values such as:
- HTTP method
- request path
- status code
- latency
- body size
- component name
- subject or username
- client IP
- user agent
This makes mixed application logs easier to scan than showing only the raw JSON payload or message field.
What VictoriaLogs stores
Section titled “What VictoriaLogs stores”VictoriaLogs is installed as a managed observability service and stores retained cluster logs on a persistent volume inside the cluster.
The managed setup includes:
- a single-node VictoriaLogs server
- a built in Kubernetes collector
From Observability → Settings, Edka can manage:
- retention period
- maximum disk-usage threshold before old data is dropped
- storage size and storage class
- server CPU and memory requests and limits
- collector CPU and memory requests and limits
- an optional exclude filter for noisy log sources
- private UI exposure through Tailscale-aware traffic classes
The Settings view also shows runtime status such as:
- server pod readiness
- collector pod readiness
- restart count
- server CPU and memory usage vs requests and limits
- collector CPU and memory usage vs requests and limits
- PVC capacity and utilization
- warnings from the managed app
Retention and collector filters
Section titled “Retention and collector filters”Logs are retained locally according to the VictoriaLogs settings on the cluster.
Two settings matter most operationally:
- Retention period controls how long logs are kept
- Max disk usage stops retaining older logs once the volume reaches the configured utilization threshold
You can also set an Exclude Filter to skip known-noisy containers or namespaces before they are collected into VictoriaLogs.
Private UI access
Section titled “Private UI access”If VictoriaLogs UI exposure is enabled in Observability → Settings, Edka shows an Open UI action in the Logs tab.
Current behavior:
- exposure is private, not public internet access
- the Tailscale operator must already be installed on the cluster
- access is routed through a Tailscale-aware traffic class
When to use Logs vs Diagnostics
Section titled “When to use Logs vs Diagnostics”Use Logs when you need:
- retained application or workload logs
- search across namespaces or pods
- field-based narrowing of noisy results
- historical incident triage beyond a single pod
Use Diagnostics when you need:
- Kubernetes warning events
- pods requiring attention
- node readiness signals
- K3s-level troubleshooting