Getting logs from all cluster Pods and sending them to Loki

Чтение логов из всех подов кластера и направление их в Loki

Reading Pod logs from a specified namespace with a specified label and redirecting to Loki and Elasticsearch

Чтение логов подов из указанного namespace с указанным label и перенаправление одновременно в Loki и Elasticsearch

Reading logs from namespace=whispers with label app=booking and storing them into Loki and Elasticsearch:

Чтение логов подов из namespace whispers только с label app=booking и перенаправление одновременно в Loki и Elasticsearch:

Creating a source in namespace and reading logs of all Pods in that NS with forwarding them to Loki

Создание source в namespace и чтение логов всех подов в этом NS с направлением их в Loki

Namespaced pipeline - reading logs from test-whispers namespace (all Pods):

Следующий pipeline создает source в namespace test-whispers, читает логи всех подов в этом NS и пишет их в Loki:

Reading only Pods in the specified namespace and having a certain label

Чтение только подов в указанном namespace и с определенным label

Read logs from Pods with label app=booking in namespace test-whispers:

Пример чтения только подов, имеющих label app=booking, в namespace test-whispers:

Migration from Promtail to Log-Shipper

Переход с Promtail на Log-Shipper

Path /loki/api/v1/push has to be removed from the previously used Loki URL.

В ранее используемом URL Loki требуется убрать путь /loki/api/v1/push.

Vector will add this PATH automatically during working with Loki destination.

Vector сам добавит этот путь при работе с Loki.

Working with Grafana Cloud

Работа с Grafana Cloud

This documentation expects that you have created API key.

Данная документация подразумевает, что у вас уже создан ключ API.

Для начала вам потребуется закодировать в base64 ваш токен доступа к Grafana Cloud.

Firstly you should encode your token with base64.

Then you can create ClusterLogDestination

Затем нужно создать ClusterLogDestination

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: loki-storage spec: loki: auth: password: PFlPVVItR1JBRkFOQUNMT1VELVRPS0VOPg== strategy: Basic user: “" endpoint: # For example https://logs-prod-us-central1.grafana.net or https://logs-prod-eu-west-0.grafana.net type: Loki

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: loki-storage spec: loki: auth: password: PFlPVVItR1JBRkFOQUNMT1VELVRPS0VOPg== strategy: Basic user: “" endpoint: # Например https://logs-prod-us-central1.grafana.net или https://logs-prod-eu-west-0.grafana.net type: Loki

Now you can create PodLogginConfig or ClusterPodLoggingConfig and send logs to Grafana Cloud.

Теперь можно создать PodLogginConfig или ClusterPodLoggingConfig и отправлять логи в Grafana Cloud.

Adding Loki source to Deckhouse Grafana

Добавление Loki в Deckhouse Grafana

You can work with Loki from embedded to deckhouse Grafana. Just add GrafanaAdditionalDatasource

Вы можете работать с Loki из встроенной в Deckhouse Grafana. Достаточно добавить GrafanaAdditionalDatasource.

Elasticsearch < 6.X usage

Поддержка Elasticsearch < 6.X

For Elasticsearch < 6.0 doc_type indexing should be set. Config should look like this:

Для Elasticsearch < 6.0 нужно включить поддержку doc_type индексов. Сделать это можно следующим образом:

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: es-storage spec: type: Elasticsearch elasticsearch: endpoint: http://192.168.1.1:9200 docType: “myDocType” # Set any string here. It should not start with ‘_’ auth: strategy: Basic user: elastic password: c2VjcmV0IC1uCg==

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: es-storage spec: type: Elasticsearch elasticsearch: endpoint: http://192.168.1.1:9200 docType: “myDocType” # Укажите значение здесь. Оно не должно начинаться с ‘_’. auth: strategy: Basic user: elastic password: c2VjcmV0IC1uCg==

Index template for Elasticsearch

Шаблон индекса для Elasticsearch

It is possible to route logs to particular indexes based on metadata using index templating:

Существует возможность отправлять сообщения в определенные индексы на основе метаданных с помощью шаблонов индексов:

For the above example for each Kubernetes namespace a dedicated index in Elasticsearch will be created.

В приведенном выше примере для каждого пространства имен Kubernetes будет создан свой индекс в Elasticsearch.

This feature works well combining with extraLabels:

Эта функция также хорошо работает в комбинации с extraLabels:

1. If a log message is in JSON format, the service_name field of this JSON document is moved to the metadata level.
2. The new metadata field service is used for the index template.

1. Если сообщение имеет формат JSON, поле service_name этого документа JSON перемещается на уровень метаданных.
2. Новое поле метаданных service используется в шаблоне индекса.

Splunk integration

Пример интеграции со Splunk

It is possible to send logs from Deckhouse to Splunk.

Существует возможность отсылать события из Deckhouse в Splunk.

1. Endpoint must be equal to the Splunk instance name with the 8088 port and no path provided, e.g. https://prd-p-xxxxxx.splunkcloud.com:8088.
2. To add a token to ingest logs, go to Setting -> Data inputs, add a new HTTP Event Collector and copy a token.
3. Provide a Splunk index to store logs, e.g., logs.

1. Endpoint должен быть таким же, как имя вашего экземпляра Splunk с портом 8088 и без указания пути, например https://prd-p-xxxxxx.splunkcloud.com:8088.
2. Чтобы добавить token для доступа, откройте пункт меню Setting -> Data inputs, добавьте новый HTTP Event Collector и скопируйте token.
3. Укажите индекс Splunk для хранения логов, например logs.

Splunk destination doesn’t support pod labels for indexes. Consider exporting necessary labels with the extraLabels option.

destination не поддерживает метки пода для индексирования. Рассмотрите возможность добавления нужных меток с помощью опции extraLabels.

Simple Logstash example

Простой пример Logstash

To send logs to Logstash, the tcp input should be configured on the Logstash instance side, and its codec should be set to json.

Чтобы отправлять логи в Logstash, на стороне Logstash должен быть настроен входящий поток tcp и его кодек должен быть json.

An example of the minimal Logstash configuration:

Пример минимальной конфигурации Logstash:

An example of the ClusterLogDestination manifest:

Пример манифеста ClusterLogDestination:

The following examples sets severity for the syslog messages and uses the socket destination:

Следующий пример показывает, как отправлять сообщения через сокет по протоколу TCP в формате syslog:

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: rsyslog spec: type: Socket socket: mode: TCP address: 192.168.0.1:3000 encoding: codec: Syslog extraLabels: syslog.severity: “alert” the request_id field should be present in the log message syslog.message_id: “{{ request_id }}”

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLogDestination metadata: name: rsyslog spec: type: Socket socket: mode: TCP address: 192.168.0.1:3000 encoding: codec: Syslog extraLabels: syslog.severity: “alert” поле request_id должно присутствовать в сообщении syslog.message_id: “{{ request_id }}”

Logs in CEF Format

Логи в CEF формате

There is a way to format logs in CEF format using codec: CEF, with overriding cef.name and cef.severity based on values from the message field (application log) in JSON format.

Существует способ формировать логи в формате CEF, используя codec: CEF, с переопределением cef.name и cef.severity по значениям из поля message (лога приложения) в формате JSON.

In the example below, app and log_level are keys containing values for overriding:

В примере ниже app и log_level это ключи содержащие значения для переопределения:

You can also manually set your own values:

Так же можно вручную задать свои значения:

Collect Kubernetes Events

Сбор событий Kubernetes

Kubernetes Events can be collected by log-shipper if events-exporter is enabled in the extended-monitoring module configuration.

События Kubernetes могут быть собраны log-shipper’ом, если events-exporter включен в настройках модуля extended-monitoring.

Enable events-exporter by adjusting extended-monitoring settings:

Включите events-exporter, изменив параметры модуля extended-monitoring:

Apply the following ClusterLoggingConfig to collect logs from the events-exporter Pod:

Выложите в кластер следующий ClusterLoggingConfig, чтобы собирать сообщения с пода events-exporter:

Log filters

Фильтрация логов

Users can filter logs by applying two filters:

Пользователи могут фильтровать логи, используя следующие фильтры:

• labelFilter — applies to the top-level metadata, e.g., container, namespace, or Pod name.
• logFilter — applies to fields of a message if it is in JSON format.

• labelFilter — применяется к метаданным, например имени контейнера (container), пространству имен (namespace) или имени пода (pod_name);
• logFilter — применяется к полям самого сообщения, если оно в JSON-формате.

Collect only logs of the nginx container

Сборка логов только для контейнера nginx

Collect logs without strings GET /status" 200

Сборка логов без строки, содержащей GET /status" 200

Audit of kubelet actions

Аудит событий kubelet’а

Deckhouse system logs

Системные логи Deckhouse

If you need logs from only one or from a small group of a Pods, try to use the kubernetesPods settings to reduce the number of reading filed. Do not use highly grained filters to read logs from a single pod.

Если вам нужны только логи одного пода или малой группы подов, постарайтесь использовать настройки kubernetesPods, чтобы сузить количество читаемых файлов. Фильтры необходимы только для высокогранулярной настройки.

Collect logs from production namespaces using the namespace label selector option

Настройка сборки логов с продуктовых namespace’ов, используя опцию namespace label selector

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLoggingConfig metadata: name: production-logs spec: type: KubernetesPods kubernetesPods: namespaceSelector: labelSelector: matchLabels: environment: production destinationRefs:

• loki-storage

yaml apiVersion: deckhouse.io/v1alpha1 kind: ClusterLoggingConfig metadata: name: production-logs spec: type: KubernetesPods kubernetesPods: namespaceSelector: labelSelector: matchNames: environment: production destinationRefs:

• loki-storage

Exclude Pods or namespaces with a label

Исключение подов и пространств имён, используя label

There is a preconfigured label to exclude particular namespaces or Pods: log-shipper.deckhouse.io/exclude=true. It can help to stop collecting logs from a namespace or Pod without changing global configurations.

Существует преднастроенный label для исключения определенных подов и пространств имён: log-shipper.deckhouse.io/exclude=true. Он помогает остановить сбор логов с подов и пространств имён без изменения глобальной конфигурации.

Enable Buffering

Включение буферизации

The log buffering configuration is essential for improving the reliability and performance of the log collection system. Buffering can be useful in the following cases:

Настройка буферизации логов необходима для улучшения надежности и производительности системы сбора логов. Буферизация может быть полезна в следующих случаях:

1. Temporary connectivity disruptions. If there are temporary disruptions or instability in the connection to the log storage system (such as Elasticsearch), a buffer allows logs to be temporarily stored and sent when the connection is restored.

1. Временные перебои с подключением. Если есть временные перебои или нестабильность соединения с системой хранения логов (например, с Elasticsearch), буфер позволяет временно сохранять логи и отправить их, когда соединение восстановится.

1. Smoothing out load peaks. During sudden spikes in log volume, a buffer helps smooth out peak loads on the log storage system, preventing it from becoming overloaded and potentially losing data.

1. Сглаживание пиков нагрузки. При внезапных всплесках объема логов буфер позволяет сгладить пиковую нагрузку на систему хранения логов, предотвращая её перегрузку и потенциальную потерю данных.

1. Performance optimization. Buffering helps optimize the performance of the log collection system by accumulating logs and sending them in batches, which reduces the number of network requests and improves overall throughput.

1. Оптимизация производительности. Буферизация помогает оптимизировать производительность системы сбора логов за счёт накопления логов и отправки их группами, что снижает количество сетевых запросов и улучшает общую пропускную способность.

Example of enabling in-memory buffering

Пример включения буферизации в оперативной памяти

Example of enabling disk buffering

Пример включения буферизации на диске

Example of defining behavior when the buffer is full

Пример определения поведения при переполнении буфера

More detailed description of the parameters is available in the ClusterLogDestination resource.

Более подробное описание параметров доступно в ресурсе ClusterLogDestination.