Log

doc
1

See also: How to manage logs

A log is a computer-generated record about entities, activities, usage patterns, etc., within a system. In Juju, logs are produced by jujud and keep track of machine and unit agents, models, controllers, etc.

Contents:

Juju agent logs - machines

In machine deployments, Juju agent logs are organised into a number of files. These files are located on every machine that Juju creates, including the controller. Specifically, they can be found under /var/log/juju, and may include:

Agent log files

Agent log files (e.g., /var/log/juju/unit-controller-0.log ) contain the logs for the machine and unit agents.

Model log files

Model log files (e.g., /var/log/juju/models/admin-test-3850c8.log) contain the logs for all the workers on a model.

The audit log file

The audit log file (/var/log/juju/audit.log) logs all the client commands and all the API calls and errors responses associated with a controller, classified as one of the following:

  • Conversation: A collection of API methods associated with a single top-level CLI command.
  • Request: A single API method.
  • ResponseErrors: Errors resulting from an API method

The audit log file can be found only on controller machines.

The logsink log file

The logsink file (logsink.log) contains all the agent logs shipped to the controller, in aggregated form. These logs will end up in Juju’s internal database, MongoDB.

In a controller high availability scenario, logsink.log is not guaranteed to contain all messages since agents have a choice of several controllers to send their logs to. The debug-log command should be used for accessing consolidated data across all controllers.

The machine-lock log file

The machine-lock log file (machine-lock.log) contains logs for the file lock that synchronises hook execution on Juju machines. (A machine will only ever run one hook at a time.)

Juju agent logs - Kubernetes

In Kubernetes deployments, logs are written directly to stdout of the container and can be retrieved with native Kubernetes methods: kubectl logs <pod-name> -n <model-name> .

By default, it will fetch the logs from the main container charm container. When fetching logs from other containers, use additional -c flag to specify the container, i.e. kubectl logs -c <container-name> <pod-name> -n <model-name> .


Contributors: @charlie4284 , @manadart, @reneradoi, @tmihoc

1 Like
2
3
4

I think it would be helpful to have a section on retrieving logs for kubernetes agents. Perhaps something like below?

Kubernetes agent logs

Kubernetes logs are written directly to stdout of the container and can be retrieved with native Kubernetes methods. kubectl logs <pod-name>. By default, it will fetch the logs from the main container charm container. When fetching logs from other containers, use additional -c flag to specify the container, i.e. kubectl logs -c <container-name> <pod-name>.

1 Like
5

@charlie4284 If you wish, you can make the change directly. (I’ve checked and your trust level is high enough to allow that.) Please also add a Contributors line and your name to it on the bottom of the doc, as follows:

<small><br> **Contributors:** @charlie4284 </small>

It’s something we’ve started doing on all new edits to the docs, for any feedback factored into the edit.

1 Like
6

For the record: fixed a typo (: instead of .) and added the namespace-parameter to the kubectl commands in the Kubernetes agent logs section.

1 Like
7

Thanks! (I was going to add you to the contributors but I see you’re already there – good!)

2 Likes