Skip to main content

Viewing logs

Kernel messages can be retrieved with talosctl dmesg command:
Service logs can be retrieved with talosctl logs command:
Container logs for Kubernetes pods can be retrieved with talosctl logs -k command: If some host workloads (e.g. system extensions) send syslog messages, they can be retrieved with talosctl logs syslogd command.

Sending logs

Service logs

You can enable logs sendings in machine configuration:
Several destinations can be specified. Supported protocols are UDP and TCP. The only currently supported format is json_lines:
Messages are newline-separated when sent over TCP. Over UDP messages are sent with one message per packet. msg, talos-level, talos-service, and talos-time fields are always present; there may be additional fields. Every message sent can be enhanced with additional fields by using the extraTags field in the machine configuration:
The specified extraTags are added to every message sent to the destination verbatim.

Kernel logs

Kernel log delivery can be enabled with the talos.logging.kernel kernel command line argument, which can be specified in the .machine.installer.extraKernelArgs:
Also kernel logs delivery can be configured using the document in machine configuration:
Kernel log destination is specified in the same way as service log endpoint. The only supported format is json_lines. Sample message:
extraKernelArgs in the machine configuration are only applied on Talos upgrades, not just by applying the config. (Upgrading to the same version is fine).

Filebeat example

To forward logs to other Log collection services, one way to do this is sending them to a Filebeat running in the cluster itself (in the host network), which takes care of forwarding it to other endpoints (and the necessary transformations). If Elastic Cloud on Kubernetes is being used, the following Beat (custom resource) configuration might be helpful:
The input configuration ensures that messages and timestamps are extracted properly. Refer to the Filebeat documentation on how to forward logs to other outputs. Also note the hostNetwork: true in the daemonSet configuration. This ensures filebeat uses the host network, and listens on 127.0.0.1:12345 (UDP) on every machine, which can then be specified as a logging endpoint in the machine configuration.

Fluent-bit example

First, we’ll create a value file for the fluentd-bit Helm chart.
Next, we will add the helm repo for FluentBit, and deploy it to the cluster.
Now we need to find the service IP.
Finally, we will change talos log destination with the command talosctl edit mc.
This example configuration was well tested with Cilium CNI, and it should work with iptables/ipvs based CNI plugins too.

Vector example

Vector is a lightweight observability pipeline ideal for a Kubernetes environment. It can ingest (source) logs from multiple sources, perform remapping on the logs (transform), and forward the resulting pipeline to multiple destinations (sinks). As it is an end to end platform, it can be run as a single-deployment ‘aggregator’ as well as a replicaSet of ‘Agents’ that run on each node. As Talos can be set as above to send logs to a destination, we can run Vector as an Aggregator, and forward both kernel and service to a UDP socket in-cluster. Below is an excerpt of a source/sink setup for Talos, with a ‘sink’ destination of an in-cluster Grafana Loki log aggregation service. As Loki can create labels from the log input, we have set up the Loki sink to create labels based on the host IP, service and facility of the inbound logs. Note that a method of exposing the Vector service will be required which may vary depending on your setup - a LoadBalancer is a good option.