> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # EVE-OS Logging Overview > Understand how EVE-OS generates, stores, and exports logs from edge nodes, and how those logs reach Edge Infrastructure Services. ## Introduction EVE-OS (Edge Virtualization Engine) collects logs from the operating system and from your edge applications through a single built-in pipeline, then stores them on the edge node and uploads a copy to Edge Infrastructure Services. Understanding this pipeline helps you know where to find logs, how quickly they appear, and how to control what gets recorded. ## How It Works Unlike a standard Linux server, an edge node running EVE-OS does not expose a `/var/log` directory or an interactive login. Instead, all logs move through an internal pipeline in stages. * In the **generate** stage, EVE-OS agents, the kernel, and your edge applications write log messages into an in-memory buffer as they run. * In the **persist** stage, EVE-OS writes those messages to disk on the edge node under `/persist/newlog`, then compresses them into gzip files. * In the **export** stage, EVE-OS uploads the compressed files to Edge Infrastructure Services, oldest first, and moves them to a local *sent* queue after a successful upload. Uploaded logs are retained on disk as a circular buffer up to a quota (2 GB by default) and are recycled oldest-first only when space runs low. Because uploads are batched rather than continuous, logs typically appear in the Edge Infrastructure Services console within a few minutes. The delay can be longer if the edge node has been offline and is catching up. EVE-OS separates logs into two streams. * The **device stream** contains logs from EVE-OS itself, such as its networking and application-management agents. * The **application stream** contains logs from your edge applications, with a separate set of files for each application. You can configure an individual application to keep its logs on the edge node only, in which case EVE-OS stores them locally but never uploads them. The pipeline also protects against data loss and disk exhaustion. If an upload fails repeatedly, EVE-OS retains the affected files locally up to a limit so you can still retrieve them. EVE-OS also enforces an on-disk quota and recycles the oldest, least critical logs first when space runs low. This logging pipeline is part of core EVE-OS and works the same way on both the EVE-KVM and EVE-K variants. The main difference is in application logs, because each variant runs edge workloads through a different virtualization layer and therefore labels guest and hypervisor logs differently. ## How EVE-OS Logs Relate to Other Logs and Integrations The logs described in this article are the runtime logs that EVE-OS generates on the edge node. Several other surfaces in Edge Infrastructure Services display or forward log-related data, and it helps to understand how they differ. * The log view in the Edge Infrastructure Services console is not a separate logging system. It displays the same device and application logs after EVE-OS uploads them, which is why entries appear with a short delay. * Enterprise events and user-action records are a separate stream. They describe activity within Edge Infrastructure Services, for example configuration changes and edge node state changes, rather than the runtime output of EVE-OS and your applications. * Integrations such as Splunk are export destinations, not additional log sources. When you configure a Splunk integration, Edge Infrastructure Services forwards the data you select (events, application logs, and/or metrics) to your Splunk instance so you can analyze it in your own tools. * The OpenTelemetry (OTEL) export sends observability metrics, such as edge node and application health data, rather than log entries. * Some diagnostics stay on the edge node and are never uploaded, for example the on-device monitor logs. ## Key Benefits * Retrieve logs remotely through Edge Infrastructure Services or EdgeView without opening an SSH session or being on the edge node's network. * Rely on consistent, structured logs, because EVE-OS records each entry as a single JSON object that you can search and filter. * Keep troubleshooting data available even during connectivity problems, because EVE-OS persists and retries logs that cannot be uploaded. * Control cost and noise by tuning log verbosity, on-disk quotas, and per-application retention from Edge Infrastructure Services. * Use the same logging model across your fleet, because the pipeline behaves consistently on both EVE-KVM and EVE-K. ## Next Steps > [card] [Retrieve Logs with EdgeView, SSH, or Console](https://zededa.mintlify.site/new-ui/infrastructure-services/troubleshooting/gather-eve-os-logs.md) > > Retrieve logs remotely with Edge View, live on the device, or as a full diagnostic bundle. > [card] [Set Log Levels](https://zededa.mintlify.site/new-ui/infrastructure-services/troubleshooting/set-log-levels.md) > > Adjust logging verbosity for the device or a specific agent. > [card] [Download a Diagnostic Bundle](https://zededa.mintlify.site/new-ui/infrastructure-services/troubleshooting/collect-diagnostic-data.md) > > Gather a complete diagnostic bundle for support.