Portainer Agent connectivity and log retrieval for failed deployments

Question

Container Log Accessibility via Portainer Agent
Portainer provides a UI for accessing container and service logs by proxying requests to the underlying runtime or orchestrator API. When managing remote environments, this process relies heavily on the Portainer Agent's connectivity to the primary instance.
In scenarios where a stack deployment is marked as failed, the availability of logs depends on whether the container persists and if the Agent remains reachable. Because Portainer does not store logs internally, the visibility of diagnostic data is tied to the runtime logging driver and the current state of the endpoint connection.
There is uncertainty regarding how the UI handles log requests when the Agent is disconnected but the container daemon is still operational, particularly during the convergence phase of a failed deployment.

Does the Portainer UI provide a fallback mechanism for log retrieval if the Agent is unreachable but the Docker socket is accessible?
How does the log metadata and timestamping differ when switching between standalone Docker endpoints and Kubernetes endpoints for the same container image?

Tasadduq Burney · Answer

Log Accessibility and Agent Connectivity
The Portainer UI does not provide a fallback mechanism for log retrieval if the Portainer Agent is unreachable, even if the underlying Docker socket is operational. Because Portainer acts as a proxy to the runtime API, the Agent is the exclusive communication bridge for remote environments. If the Agent is disconnected, the UI cannot issue the API calls necessary to stream logs from the daemon.

Likely Explanation for Log Loss
In failed stack deployments, the inability to view logs usually stems from one of two states:

Connectivity Failure: The Agent is down or network-partitioned, breaking the proxy link between the Portainer Server and the runtime.
  Container Lifecycle: The orchestrator (especially in Kubernetes or Swarm) may have already terminated and removed the failed container/pod. Since Portainer does not store logs internally, once the runtime deletes the container, the logs are purged unless an external logging driver (e.g., Syslog, Fluentd) is configured.

Log Metadata: Docker vs. Kubernetes
Timestamping and metadata differ based on the endpoint type because Portainer queries different APIs:

Feature
      Standalone Docker Endpoint
      Kubernetes Endpoint

API Source
      Docker Daemon API
      Kubernetes API (Pod Logs)

Timestamping
      Dependent on the Docker logging driver (e.g., json-file).
      Managed by the K8s API/CRI; standardized across the cluster.

Persistence
      Logs persist until the container is removed.
      Logs may be purged quickly based on K8s pod rotation policies.

Verification Steps
To determine if the issue is a Portainer Agent failure or a container lifecycle issue, use the following scoped commands on the host machine:

Verify Agent Status: Check if the agent container is running:
    docker ps | grep portainer_agent
  
  Direct Log Access: Bypass Portainer to see if the logs still exist in the runtime:
    docker logs [container_id]
    For Kubernetes: kubectl logs [pod_name]

Diagnostic Detail Needed: Are you using a custom logging driver (e.g., Gelf, Splunk) or the default json-file/journald drivers? This changes whether logs survive container deletion.

Portainer Agent connectivity and log retrieval for failed deployments

Container Log Accessibility via Portainer Agent

1 answer

Log Accessibility and Agent Connectivity

Likely Explanation for Log Loss

Log Metadata: Docker vs. Kubernetes

Verification Steps

Your perspective belongs here.

0 question comments

Feature	Standalone Docker Endpoint	Kubernetes Endpoint
API Source	Docker Daemon API	Kubernetes API (Pod Logs)
Timestamping	Dependent on the Docker logging driver (e.g., `json-file`).	Managed by the K8s API/CRI; standardized across the cluster.
Persistence	Logs persist until the container is removed.	Logs may be purged quickly based on K8s pod rotation policies.