Логи
Модуль централизованного хранения логов (OpenSearch)
Модуль централизованного хранения логов использует в качестве основы OpenSearch.
Если в Комплексе и клиентском кластере установлен, включен и работает "Модуль локального сбора логов (Vector)", пользователи, имеющие в наборах доступа права в OpenSearch, могут авторизоваться в OpenSearch для просмотра логов.
Логи вашего кластера доступны из дашборда кластера по нажатию на кнопку Логи.
Для авторизации нужно открыть ссылку в том же окне браузера, в котором открыт Комплекс, затем нажать кнопку log in with single sign-on. В аккаунте будут доступны логи безопасности, инфраструктурные логи и логи приложений всех кластеров Комплекса, в которых установлен модуль сбора системных логов.
В случае необходимости можно увеличить дисковое пространство для хранения логов OpenSearch, а также настроить оповещение о заполненности дискового пространства. Подробнее см. на страницах увеличения объема хранилища OpenSearch, VictoriaMetrics .
Можно перейти в п. Анализ состояния в Комплексе "Анализ состояния в РОСА Кубис", чтобы ознакомиться с совместной работой модулей, обеспечивающих логирование в Комплексе.
В текущем релизе используется OpenSearch версии 2.15.0 и OpenSearch Operator версии 2.6.1.
Просмотр логов
При первом переходе в интерфейсе необходимо определить tenants. Для этого в модальном окне "Select your tenant" нужно выбрать блок "Private".
В интерфейсе OpenSearch следует перейти в левом меню в раздел "Management → Dashboards Management → Index patterns". И нажать кнопку Create index pattern.
Затем ввести префикс имени кластера и "_тип_лога", в конце указав "-*":
- для клиентского кластера следует использовать в виде префикса имя клиентского кластера;
- для кластера управления (Комплекса) следует использовать имя кластера, указанное при установке кластера управления.
Для просмотра имени кластера управления нужно перейти в раздел "Платформа → Установленные сервисы", найти "Модуль локального сбора логов", нажать Управлять, в блоке "Спецификация" найти значение поля "logstashPrefix" ‒ это название вашего кластера управления. Следует использовать его в качестве префикса имени кластера.
В результате должно получиться myclustername_тип_лога-*. Индексы включают следующие типы логов:
auditd‒ системные логи аудита;journald‒ логи контейнеров, kubelet, shturvald;logs‒ логи контейнеров;user-logs‒ логи приложений пользовательской нагрузки;events‒ логи событий всех объектов кластера;kaudit‒ kube-audit-логи (тип доступен, если установлены расширенные настройки безопасности в кластере; подробнее см. в разделе "Настройка подключения kube-audit логов" (п. Настройка подключения kube-audit-логов)).
Чтобы вывести данные по всем логам и датам для индекса, нужно указать * вместо "тип_лога", например myclustername_*.
Далее требуется нажать Next step, в поле "Time field" выбрать @timestamp и нажать Create index pattern.
Такой Index pattern необходимо создать для каждого кластера.
Затем следует перейти в левом меню на вкладку "OpenSearch Dashboards → Discover", в перечне индексов выбрать Index pattern в соответствии с названием созданного индекса для вашего кластера.
В некоторых случаях при инициализации Dashboards, когда кластер OpenSearch еще не полностью готов, создается битый индекс .kibana_1, в котором хранятся в том числе Index pattern.
Решение:
- удалить индекс .kibana_1;
- перезагрузить под ресурса Deployment "shturval-logs-dashboards".
Настройка подключения kube-audit-логов
Для кластера, в котором установлены расширенные настройки безопасности, есть возможность настройки audit_policy и просмотра логов в OpenSearch.
Для этого в интерфейсе OpenSearch нужно перейти в левом меню в раздел "Management → Dashboards Management → Index patterns" и нажать кнопку Create index pattern:
- Для кластера управления в названии ввести префикс имени вашего кластера управления, затем добавить
_kaudit-*, что позволит выводить данные по всем датам для этого индекса. Должно получиться так:mgmtclustername_kaudit-*. - Для клиентского кластера в названии ввести префикс имени вашего кластера, затем добавить
_kaudit-*, что позволит выводить данные по всем датам для этого индекса. Должно получиться так:myclustername_kaudit-*.
Уточнить название индекса можно в разделе "Management → Index Management → Indexes".
Далее следует нажать Next step, в поле "Time field" выбрать @timestamp и завершить создание, нажав на кнопку Create index pattern.
Затем нужно перейти в левом меню на вкладку "OpenSearch Dashboards → Discover", в перечне индексов выбрать Index pattern в соответствии с названием созданного индекса для вашего кластера.
Для настройки обнаружения аномалий следует использовать инструкцию в п. Обнаружение аномалий.
Перенаправление логов
Для управления сбором логов в кластерах Комплекса используется Vector. См. подробнее в п. Модуль локального сбора логов (Vector) о настройке этого сервиса.
Для настройки перенаправления логов необходимо выполнить следующие действия:
- в кластере, где нужно сделать перенаправление логов, в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти и открыть "Модуль локального сбора логов" (shturval-log-collector);
- в разделе "Спецификация сервиса" добавить конфигурацию shturval и указать:
- тип логов, которые необходимо перенаправить: auditd, journald, k8s_audit, k8s_events, k8s_logs. В блоке shturval должны быть перечислены все типы логов, для которых требуется перенаправление;
- получателей логов в sinks и их данные для аутентификации, URL-адрес подключения, настройки TLS-соединения и буфера хранения логов до отправки;
- при необходимости преобразования логов перед отправкой конфигурацию в параметре transforms.
Пример customvalues (описание параметров ‒ в таблице 37):
shturval:
k8s_logs: # Тип логов для перенаправления
enable: true # Включает отправку логов elasticsearch
transforms: {} # Преобразование логов
sinks: # Конечные точки для отправки данных
elastic_bank: # Имя получателя данных
type: <ваше значение параметра>
auth: # Настройки аутентификации для подключения к elasticsearch
user: <ваше значение параметра>
password: <ваше значение параметра>
strategy: <ваше значение параметра>
endpoints: # URL-адрес для подключения
‒ <ваше значение параметра>
tls: # Настройки TLS-соединения
verify_certificate: true
api_version: <ваше значение параметра>
buffer: # Настройка буфера для хранения логов перед отправкой
max_size: <ваше значение параметра>
type: <ваше значение параметра>
- если необходимо отключить отправку логов в Opensearch, следует переопределить значение sink c именем platform-opensearch в shturval для одного или всех типов логов, как приведено в примере customvalues:
shturval:
k8s_logs:
enable: true
sinks:
platform-opensearch: {}
Следует обратить внимание, что, если для kube-audit (k8s_audit) логов отключить направление в Opensearch, то они не будут доступны для просмотра на вкладке "События безопасности" дашбордов в графическом интерфейсе Комплекса.
- для перенаправления логов в syslog добавить в спецификацию сервиса блок shturval с требуемыми параметрами.
Пример перенаправления в syslog (описание параметров ‒ в таблице 38):
shturval:
k8s_audit:
enable: true
sinks:
syslog:
type: socket
inputs:
‒ <ваше значение параметра>
address: <ваше значение параметра>
mode: <ваше значение параметра>
В примере выше приведена настройка с использованием socket. С другими способами конфигурации параметров для перенаправления логов на syslog-сервер можно ознакомиться в официальной документации.
- когда настройка спецификации модуля завершена, сохранить внесенные изменения. Потребуется некоторое время для применения изменений.
Ротация логов
По умолчанию логи в кластере хранятся два дня. Для изменения этого периода можно поменять параметры модуля централизованного хранения логов (shturval-logs-operator) или настроить правило ротации в OpenSearch.
Ротация по времени
- в кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы";
- найти модуль централизованного хранения логов (shturval-logs-operator), открыть карточку модуля и в блоке "Спецификация сервиса" указать количество дней ротации логов, используя параметры "inactiveAge" и "deleteAge".
Пример customvalues (описание параметров ‒ в таблице 39):
cluster:
ismpolicy:
inactiveAge: <ваше значение параметра>
deleteAge: <ваше значение параметра>
Следует обратить внимание, что срок хранения индексов не может превышать количество дней, через которое индексы будут удалены.
- cохранить внесенные изменения для модуля.
Настройка ротации в OpenSearch выполняется следующими действиями:
- после завершения установки авторизоваться в интерфейсе Комплекса https://front.
, таким образом будет присвоен токен для авторизации в OpenSearch; - авторизоваться, нажав на кнопку
log in with single sign-on; - в модальном окне выбрать "explore on my own";
- создать правило для всех вновь созданных индексов, для чего внизу левого меню найти "dev tools" и в левой части консоли прописать политику:
PUT _plugins/_ism/policies/remove_old_indexes
{
"policy": {
"description": "Removes old indexes",
"default_state": "active",
"states": [
{
"name": "active",
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "2d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
],
"ism_template": {
"index_patterns": [
"*"
],
"priority": 1000
}
}
}
- значение параметра "min_index_age" определяет время жизни старых индексов. Чем дольше хранится индекс, тем больше места на диске он занимает;
- запустить применение манифеста, нажав на кнопку выполнения; просмотреть созданную политику можно в левом меню в разделе "State Management Policy";
- перейти в разделе "Index Management" на страницу "Indices";
- слева от названия индекса выбрать все неслужебные индексы (индексы, которые в начале названия не имеют точку), в выпадающем списке "Actions" выбрать "apply policy";
- среди доступных политик выбрать remove_old_indexes и нажать
Apply.
Ротация логов по размеру
Комплекс предоставляет возможность настроить ротацию индексов по размеру. Для этого необходимо в кластере управления настроить параметры Opensearch:
- Роли доступа к индексам
Нужно создать новую роль и привязку этой роли к существующему служебному пользователю clustername-vector для записи в алиасы индексов.
OpenSearchRole:
apiVersion: opensearch.opster.io/v1
kind: OpensearchRole
metadata:
labels:
opensearch.org/cluster: logs
shturval.tech/cluster: clustername
name: clustername-vector-rollover
namespace: shturval-logging
spec:
indexPermissions:
‒ allowedActions:
‒ crud
indexPatterns:
‒ clustername_logs
‒ clustername_auditd
‒ clustername_journald
‒ clustername_user-logs
‒ clustername_events
‒ clustername_kaudit
opensearchCluster:
name: logs
OpenSearchRoleBinding:
apiVersion: opensearch.opster.io/v1
kind: OpensearchUserRoleBinding
metadata:
labels:
opensearch.org/cluster: logs
shturval.tech/cluster: clustername
name: clustername-vector-rollover
namespace: shturval-logging
spec:
opensearchCluster:
name: logs
roles:
‒ clustername-vector-rollover
users:
‒ clustername-vector
- Политики ротации индексов
Пример кастомного ресурса для индекса кластера clustername_kaudit при достижении 1000МБ.
clustername-kaudit-rollover:
apiVersion: opensearch.opster.io/v1
kind: OpenSearchISMPolicy
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-kaudit-rollover
namespace: shturval-logging
spec:
defaultState: rollover
description: "Rollover kube-audit-clustername indexes on 1000mb"
ismTemplate:
indexPatterns:
‒ 'clustername_kaudit-*'
priority: 3000
opensearchCluster:
name: logs
policyId: clustername_kaudit-rollover
states:
‒ actions:
‒ rollover:
minPrimaryShardSize: 1000mb
name: rollover
transitions:
‒ conditions:
minSize: 1000mb
stateName: delete
‒ actions:
‒ delete: {}
name: delete
- Шаблоны индекса
clustername-kaudit:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-kaudit
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_kaudit-*'
name: clustername_kaudit
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_kaudit"
clustername-journald:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-journald
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_journald-*'
name: clustername_journald
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_journald"
clustername-auditd:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-auditd
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_auditd-*'
name: clustername_auditd
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_auditd"
clustername-logs:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-logs
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_logs-*'
name: clustername_logs
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_logs"
clustername-user-logs:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-user-logs
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_user-logs-*'
name: clustername_user-logs
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_user-logs"
clustername-events:
apiVersion: opensearch.opster.io/v1
kind: OpensearchIndexTemplate
metadata:
labels:
opensearch.org/cluster: logs
name: clustername-events
namespace: shturval-logging
spec:
composedOf:
‒ index_codec
indexPatterns:
‒ 'clustername_events-*'
name: clustername_events
opensearchCluster:
name: logs
priority: 3000
template:
settings:
plugins.index_state_management.rollover_alias: "clustername_events"
- Первичные индексы
Первичные индексы необходимо создать в интерфейсе командной строки или Curl-запросом.
Пример запроса на создание clustername_kaudit:
PUT clustername_kaudit-000001
{
"aliases": {
"clustername_kaudit": {
"is_write_index": true
}
}
}
- Индекс-паттерны
- в главном меню перейти в раздел "Management → Dashboards Management";
- в левом меню перейти в подраздел "Index pattern";
- нажать кнопку
Create index pattern; - на первом шаге в строке поиска ввести имя "alias" и нажать кнопку
Next step; - на втором шаге из выпадающего списка нужно выбрать пункт со значением @timestamp;
- при успешном создании индекс-паттерна будет отображена таблица с списком всех полей этого индекса.
Такую последовательность действий нужно произвести для следующих индексов кластера:
- clustername_auditd;
- clustername_journald;
- clustername_logs;
- clustername_user-logs;
- clustername_events;
- clustername_kaudit.
- Настройка Vector
Нужно внести изменение в "Модуль локального сбора логов" (SSC shturval-log-collector) для каждого типа логов, удалив "-%Y.%m.%d" в index, как приведено в примере сustomvalues:
shturval:
k8s_audit:
enable: true
sources: {}
transforms: {}
sinks:
platform-opensearch:
bulk:
index: "{{ .Values.CLUSTER_NAME }}_kaudit"
Внешнее хранилище данных
По умолчанию хранение данных OpenSearch организовано на локальных дисках. При необходимости можно подключить внешнее сетевое хранилище данных для OpenSearch. Это может быть полезным, когда предъявляются высокие требования к отказоустойчивости системы хранения или когда место под хранение на локальных дисках ограничено.
Требования к внешнему Storage описаны в таблице 40.
Операции чтения, их количество и объем данных могут превышать операции записи из-за механизмов индексации и реплицирования.
Для оптимизации доступа к внешнему хранилищу следует использовать рекомендации по настройке для скорости индексации из официальной документации:
- Установление количества реплик на
0(index.number_of_replicas). Каждая реплика дублирует процесс индексирования, поэтому в результате отключения реплик повышается производительность кластера. - Увеличение интервала обновления индексов. По умолчанию OpenSearch обновляет каждую секунду индексы, к которым был запрос за последние 30 секунд. При увеличении интервала обновления к API осуществляется меньше запросов.
- Увеличение размера translog (index.translog.flush_threshold_size). По умолчанию очистка translog выполняется, когда translog достигает 512 МБ. При увеличении значения параметра очистка будет проходить реже.
Включение внешнего Storage после установки кластера управления
Можно подключить и использовать внешний Storage сразу после установки кластера управления Комплекса, для чего нужно:
- При установке кластера управления отключить "Модуль централизованного хранения логов" (shturval-logs-operator), для чего запустить команду установки (
stc install management), в которую подставить свои значения параметров и указать shturval-logs-operator в--disabled-system-services.
Пример команды установки:
./stc-2.10.0 install management \
--license="ВВЕДИТЕ-ВАШУ-ЛИЦЕНЗИЮ" \
--cluster-name=ВВЕДИТЕ-НАЗВАНИЕ-КЛАСТЕРА \
--ssh-user=ИМЯ-СОЗДАННОГО-ПОЛЬЗОВАТЕЛЯ \
--ssh-private-key=ВВЕДИТЕ-ПУТЬ-ДО-ПРИВАТНОГО-КЛЮЧА \
--api-endpoint=ВВЕДИТЕ-IP-ДЛЯ-API-СЕРВЕРА \
--master-nodes=ВВЕДИТЕ-IP-ХОСТОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛОВ \
--worker-nodes=ВВЕДИТЕ-IP-ХОСТОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛОВ \
--timezone=Europe/Moscow \
--ingress-vip=ВВЕДИТЕ-IP-АДРЕС-ДЛЯ-INGRESS \
--skip-check \
--ntp-servers=ВВЕДИТЕ-АДРЕСА-NTP-СЕРВЕРОВ-ЧЕРЕЗ-ЗАПЯТУЮ-БЕЗ-ПРОБЕЛА \
--disabled-system-services=shturval-logs-operator \
Подробнее об установки см. п. Установка.
- В кластере управления создать Storage Class с провижинером, совместимым с Kubernetes. В графическом интерфейсе Комплекса:
- перейти на страницу "StorageClasses" раздела "Хранилище", нажать
+ Добавить StorageClassи на странице добавления указать:- имя;
- в спецификации требуемый "Provisioner Type";
- значения параметров;
- добавить в кластер Storage Class, нажав
Сохранить.
- перейти на страницу "StorageClasses" раздела "Хранилище", нажать
- После того как Storage Class добавлен, открыть страницу "Установленные сервисы" раздела "Сервисы и репозитории", найти "Модуль централизованного хранения логов" и перейти к управлению. В блоке "Спецификация сервиса" добавить необходимые параметры в **customvalues **(описание параметров ‒ в таблице 41):
Пример customvalues:
customvalues:
ADMIN_PASSWORD: <ваше значение параметра>
ADMIN_USERNAME: <ваше значение параметра>
BACKEND_PASSWORD: <ваше значение параметра>
CLUSTER_NAME: <ваше значение параметра>
DASHBOARDS_PASSWORD: <ваше значение параметра>
FLUENTBIT_PASSWORD: <ваше значение параметра>
OPENID_CLIENT_ID: <ваше значение параметра>
OPENID_CLIENT_SECRET: <ваше значение параметра>
OPENID_HOST_PREFIX: <ваше значение параметра>
OPENID_REDIRECT_URL: <ваше значение параметра>
cluster:
nodePoolsMaster:
persistence:
pvc:
storageClass: <ваше значение параметра>
general:
monitoring:
tlsConfig:
insecureSkipVerify: true
ismpolicy:
deleteAge: <ваше значение параметра>
enabled: true
inactiveAge: <ваше значение параметра>
security:
configFiles:
internal_users.yml:
_meta:
config_version: 2
type: internalusers
kibanaserver:
description: OpenSearch Dashboards user
hash: <ваше значение параметра>
reserved: true
operator-admin:
backend_roles:
‒ admin
description: OpenSearch Admin user
hash: <ваше значение параметра>
reserved: true
serviceMonitor:
enable: false
getcert:
enable: false
ingress:
cluster:
annotations:
cert-manager.io/cluster-issuer: <ваше значение параметра>
hosts:
‒ <ваше значение параметра>
tls:
‒ hosts:
‒ <ваше значение параметра>
secretName: <ваше значение параметра>
dashboards:
annotations:
cert-manager.io/cluster-issuer: <ваше значение параметра>
hosts:
‒ <ваше значение параметра>
tls:
‒ hosts:
‒ <ваше значение параметра>
secretName: <ваше значение параметра>
Если в установленных сервисах модуль отсутствует, нужно перейти на страницу "Доступные чарты" раздела "Сервисы и репозитории", на вкладке "shturval" выбрать чарт shturval-logs-operator и нажать Установить.
Далее следует выбрать необходимую версию чарта, а также неймспейс shturval-logging. После выбора версии чарта в правой части экрана отобразятся "Доступные параметры конфигурации для сервиса (values)". В блоке "Спецификация сервиса" добавить параметры в customvalues, как в примере далее (описание параметров ‒ в таблице 42):
Пример customvalues:
```yaml
customvalues:
ADMIN_PASSWORD: <ваше значение параметра>
ADMIN_USERNAME: <ваше значение параметра>
BACKEND_PASSWORD: <ваше значение параметра>
CLUSTER_NAME: <ваше значение параметра>
DASHBOARDS_PASSWORD: <ваше значение параметра>
FLUENTBIT_PASSWORD: <ваше значение параметра>
OPENID_CLIENT_ID: <ваше значение параметра>
OPENID_CLIENT_SECRET: <ваше значение параметра>
OPENID_HOST_PREFIX: <ваше значение параметра>
OPENID_REDIRECT_URL: <ваше значение параметра>
cluster:
nodePoolsMaster:
persistence:
pvc:
storageClass: <ваше значение параметра>
general:
monitoring:
tlsConfig:
insecureSkipVerify: true
ismpolicy:
deleteAge: <ваше значение параметра>
enabled: true
inactiveAge: <ваше значение параметра>
security:
configFiles:
internal_users.yml:
_meta:
config_version: 2
type: internalusers
kibanaserver:
description: OpenSearch Dashboards user
hash: <ваше значение параметра>
reserved: true
operator-admin:
backend_roles:
‒ admin
description: OpenSearch Admin user
hash: <ваше значение параметра>
reserved: true
serviceMonitor:
enable: false
getcert:
enable: false
ingress:
cluster:
annotations:
cert-manager.io/cluster-issuer: <ваше значение параметра>
hosts:
‒ <ваше значение параметра>
tls:
‒ hosts:
‒ <ваше значение параметра>
secretName: <ваше значение параметра>
dashboards:
annotations:
cert-manager.io/cluster-issuer: <ваше значение параметра>
hosts:
‒ <ваше значение параметра>
tls:
‒ hosts:
‒ <ваше значение параметра>
secretName: <ваше значение параметра>
Следует обратить внимание, что для работы модуля должен быть включен "Компонент модуля централизованного хранения логов (shturval-logs-operator-crds)".
- Включить модуль в автоматическом режиме управления и нажать
Сохранить.
Переключение с локального хранилища на внешний Storage в кластере
Если требуется подключение внешнего Storage в развернутом кластере управления с работающим OpenSearch, необходимо выполнить действия:
- В кластере управления создать Storage Class с провижинером, совместимым с Kubernetes. В графическом интерфейсе Комплекса":
- перейти на страницу "StorageClasses" раздела "Хранилище", нажать
+ Добавить StorageClassи на странице добавления указать:- имя;
- в спецификации "Provisioner Type";
- значения параметров.
- Добавить в кластер Storage Class, нажав
Сохранить.
- Когда Storage Class добавлен, перейти в раздел "Сервисы и репозитории" на страницу "Установленные сервисы", найти "Модуль централизованного хранения логов" и нажать переключатель, чтобы отключить сервис.
Важно ‒ Миграция данных с локальных дисков платформы виртуализации в сетевое хранилище невозможна. После остановки модуля данные будут потеряны. При необходимости перед отключением "Модуля централизованного хранения логов" необходимо выгрузить критичные данные.
- Выполнить шаги инструкции по вводу OpenSearch в эксплуатацию после отключения (п. Восстановление работоспособности OpenSearch) и перед включением модуля в блоке "Спецификация сервиса" добавить параметр storageClass в customvalues, как в примере далее (описание параметров ‒ в таблице 43):
Пример customvalues:
customvalues:
cluster:
nodePoolsMaster:
persistence:
pvc:
storageClass: <ваше значение параметра>
Модуль локального сбора логов (Vector)
Модуль локального сбора логов собирает, агрегирует и передает логи.
Vector является инструментом для обработки и передачи данных с открытым исходным кодом, написанном на Rust. В основе архитектуры Vector три основных компонента:
- Sources (Источники) ‒ компоненты, которые получают или собирают данные;
- Transforms (Преобразования) ‒ компоненты, которые изменяют или фильтруют данные;
- Sinks (Получатели) ‒ компоненты, которые отправляют данные во внешние системы.
Установка модуля и базовая конфигурация
По умолчанию модуль устанавливается в клиентские кластеры и кластер управления во включенном состоянии.
Для настройки конфигурации нужно:
- перейти в графический интерфейс кластера, в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы";
- найти "Модуль локального сбора логов" и нажать
Управлять; - если в кластере модуль отсутствует, в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Доступные чарты"; на вкладке "shturval" выбрать чарт shturval-log-collector и нажать
Установить; - выбрать необходимую версию чарта, а также неймспейс logging;
- после выбора версии чарта в правой части экрана отобразятся "Доступные параметры конфигурации для сервиса (values)". Следует прописать в блоке "Спецификация сервиса" необходимые параметры в качестве customvalues (таблица 44).
Важно ‒ Для работы модуля должен быть включен CRD для модуля сбора логов (shturval-log-collector-crds).
Для настройки модуля локального сбора логов (Vector) используется Vector Operator.
Базовая настройка модуля включает кастомные ресурсы ClusterVectorPipeline и Vector, определяющие его конфигурацию. Просмотреть ClusterVectorPipeline и Vector можно в графическом интерфейсе Комплекса. Для этого в вашем кластере нужно открыть страницу "Кастомные ресурсы" раздела "Администрирование", найти и раскрыть API-группу observability.kaasops.io, выбрать CRD ClusterVectorPipeline или Vector, на странице со списком кастомных ресурсов перейти к манифесту объекта.
Следует обратить внимание, что изменение базовой настройки может привести к ошибкам сбора, агрегации и анализа логов. При необходимости можно задать конфигурацию с помощью создания нового ClusterVectorPipeline.
В текущем релизе используется Vector версии 0.44.0, Vector Operator версии 0.1.2.
ClusterVectorPipeline в Комплексе
Модуль локального сбора логов осуществляет сбор записей журналов из стандартного потока вывода stdout системных сервисов кластера.
Преднастроенные кастомные ресурсы ClusterVectorPipeline собирают и агрегируют логи кластера в соответствии с их типами (таблица 45).
Источники сбора логов
Взаимодействие компонентов Комплекса при сборе логов показано на рисунке 412. Описание компонентов приведено в таблице 46.
Рисунок 412 ‒ Взаимодействие компонентов
Сбор и обработка логов
Для конфигурации сбора и обработки логов можно настроить ClusterVectorPipeline. Спецификация (spec) ClusterVectorPipeline содержит блоки:
- sources ‒ определяет источники данных;
- transforms- определяет преобразования данных;
- sinks ‒ определяет конечные точки для отправки данных.
Пример конфигурации для обработки логов Kubernetes:
apiVersion: observability.kaasops.io/v1alpha1
kind: ClusterVectorPipeline
metadata:
name: k8s-logs
namespace: monitoring
spec:
Источник данных ‒ логи Kubernetes
sources:
kubernetes_logs:
type: kubernetes_logs
Цепочка трансформаций
transforms:
Преобразование временной метки
remap_timestamp:
type: remap
inputs: [kubernetes_logs]
source: |
parsed_time = parse_timestamp!(.timestamp, format: "%+")
if is_timestamp(parsed_time) {
."@timestamp" = parsed_time
del(.timestamp)
}
Замена точек на подчеркивания в именах полях
dedot_fields:
type: remap
inputs: [remap_timestamp]
source: |
. = map_keys(., recursive: true) -> |key| { replace(key, ".", "_") }
Фильтрация системных пространств имен
filter_system_namespaces:
type: filter
inputs: [dedot_fields]
condition: |
exists(.kubernetes.namespace_labels."shturval_tech/system-namespace")
Фильтрация пользовательских пространств имен
filter_user_namespaces:
type: filter
inputs: [dedot_fields]
condition: |
!exists(.kubernetes.namespace_labels."shturval_tech/system-namespace")
Особенности обработки логов:
- использует встроенный источник kubernetes_logs;
- remap_timestamp ‒ парсинг и преобразование временных меток;
- dedot_fields ‒ замена точек на подчеркивания в именах полей;
- filter_system_namespaces и filter_user_namespaces ‒ разделение логов по типу пространств имен.
Важно ‒ Для применения изменений конфигурации необходимо перевести "Модуль локального сбора логов" (shturval-log-collector) в ручной режим управления (Manual), при выборе управления в автоматическом режиме (Auto) применяется базовая конфигурация.
Рекомендации при конфигурации
- Использовать понятные имена для pipelines;
- Использовать единый стиль именования компонентов;
- Выстраивать логичную цепочку преобразований;
- Использовать входы (inputs) для определения последовательности;
- Фильтровать ненужные данные как можно раньше;
- Использовать четкие условия фильтрации;
- Минимизировать количество трансформаций;
- Избегать дублирования обработки данных.
Интеграция с SIEM
Для интеграции с системой управления информационной безопасностью и событиями безопасности SIEM в кластере должен быть включен "Модуль локального сбора логов" (Vector).
Примечание ‒ При настроенной интеграции с SIEM логи продолжат маршрутизироваться в "Модуль централизованного хранения логов" (OpenSearch) (п. Модуль централизованного хранения логов (OpenSearch)), если в кластере управления он включен.
Чтобы настроить интеграцию, необходимо внести изменения в спецификацию (ssc) "Модуля локального сбора логов":
- В графическом интерфейсе кластера в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль локального сбора логов" (shturval-log-collector), открыть карточку модуля и в блоке "Спецификация сервиса" добавить customvalues, как в приведенном примере ниже (описание параметров ‒ в таблице 47):
shturval:
k8s_audit:
enable: true
sinks:
siem:
type: socket
inputs:
‒ dedot_specific_fields
address: <ваше значение параметра>
mode: <ваше значение параметра>
encoding:
codec: json
journald:
sinks:
siem:
type: socket
inputs:
‒ journald
address: <ваше значение параметра>
mode: <ваше значение параметра>
encoding:
codec: json
k8s_logs:
transforms:
filter_backend:
condition: |
.kubernetes.pod_namespace == "shturval-backend" &&
((.kubernetes.container_name == "opa" && starts_with(string!(.kubernetes.pod_name), "shturval-backend-")) || (.kubernetes.container_name == "authn" &starts_with(string!(.kubernetes.pod_name), "authn-")))
inputs:
‒ filter_system_namespaces
type: filter
sinks:
siem:
type: socket
inputs:
‒ filter_backend
address: <ваше значение параметра>
mode: <ваше значение параметра>
encoding:
codec: json
В приведенной спецификации в SIEM будут направлены логи: k8s_logs, journald и k8s_audit. Можно переопределить перечень направляемых логов. Для этого в блоке shturval следует удалить ненужный блок с логами.
- Сохранить внесенные изменения.
Vector имеет систему подтверждения доставки данных, выполняет повторную отправку данных при некорректной доставке. Это позволяет нивелировать особенности UDP-протокола.
Восстановление работоспособности OpenSearch
Во время эксплуатации Opensearch могут возникать следующие проблемы:
- Закончилось место.
- OpenSearch не может собраться из-за перезагрузки инстансов, установки или обновления.
- OpenSearch необходимо ввести эксплуатацию после отключения сервиса.
- Решение данных проблем рассмотрено в пунктах ниже.
Закончилось место
При переполнении PVC войти в графический интерфейс Opensearch не получится, так как при авторизации происходит запись о входе в служебный индекс, но он в этот момент заблокирован на запись. Существует два пути решения данной проблемы:
- увеличить объем (п. Увеличение объема хранилища OpenSearch), выделенный для PVC;
- освободить место, удалив существующие индексы.
Для удаления индексов в интерфейсе командной строки следует применять команды:
- подключиться к индексам, используя учетные данные служебного администратора Opensearch из секрета logs-admin-password неймспейса shturval-logging кластера управления:
read -s OPENSEARCH_USER
read -s OPENSEARCH_PASSWORD
- удалить все индексы кластера управления:
curl -k -u "$OPENSEARCH_USER:$OPENSEARCH_PASSWORD" -X DELETE "https://logs.apps.ip-10-0-0-1.shturval.link/management-*"
- удалить все индексы по маске за 2024 год:
curl -k -u "$OPENSEARCH_USER:$OPENSEARCH_PASSWORD" -X DELETE "https://logs.apps.ip-10-0-0-1.shturval.link/*-2024.*"
OpenSearch не может собраться из-за перезагрузки инстансов, установки или обновления
Из-за особенностей эксплуатации Opensearch в составе Комплекса при одновременном перезапуске всех подов, возможно, ситуация, когда поток логов не даст кластеру Opensearch собраться. В этом случае для восстановления работоспособности необходимо снять нагрузку с кластера, остановив отправку логов.
Один из наиболее простых способов ‒ это временно вывести из работы Ingress в модуле централизованного хранения логов (shturval-logs-operator), чтобы внешние логи не попадали в Opensearch. Для этого в кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль централизованного хранения логов". В блоке "Спецификация сервиса" внести изменения в параметры hosts, добавив "-bad" после префикса "logs".
Пример customvalues (описание параметров ‒ в таблице 48):
ingress:
cluster:
hosts:
‒ <ваше значение параметра>
tls:
‒ hosts:
‒ <ваше значение параметра>
В кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль локального сбора логов" (shturval-log-collector). В блоке "Спецификация сервиса" внести изменения в параметр PLATFORM_OPENSEARCH_ENDPOINTS, добавив "-bad" после префикса "logs-master".
Пример customvalues (описание параметров ‒ в таблице 49):
PLATFORM_OPENSEARCH_ENDPOINTS: <ваше значение параметра>
После сохранения изменений в течение нескольких минут кластер Opensearch соберется. После этого необходимо вернуть значение параметра hosts модуля централизованного хранения логов (shturval-logs-operator) и параметра "PLATFORM_OPENSEARCH_ENDPOINTS" модуля локального сбора логов (shturval-log-collector) в исходное состояние.
Ввод OpenSearch в эксплуатацию после отключения сервиса
Если "Модуль централизованного хранения логов" (shturval-logs-operator) был отключен (установлен "mode: absent"), для его введения в эксплуатацию требуется полная переустановка и повторная ручная инициализация кастомных ресурсов:
- Выгрузить локально манифесты кастомных ресурсов из кластера управления:
- OpensearchUser;
- OpensearchRole;
- OpensearchUserRoleBinding;
- OpensearchTenant.
Важно ‒ Рекомендуется выполнить резервное копирование всех secrets с постфиксом "-fluentbit-password" неймспейса shturval-logging.
- Очистить выгруженные манифесты от служебных данных. Для очистки выгруженных манифестов от служебных данных настоятельно рекомендуется использовать плагин kubectl-neat:
OpensearchUser
kubectl get OpensearchUser -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchuser.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchUser -n shturval-logging % -o yaml | kubectl neat > opensearchUser_%.yaml';
OpensearchRole
kubectl get OpensearchRole -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchrole.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchRole -n shturval-logging % -o yaml | kubectl neat > opensearchRole_%.yaml';
OpensearchUserRoleBinding
kubectl get OpensearchUserRoleBinding -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchuserrolebinding.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchUserRoleBinding -n shturval-logging % -o yaml | kubectl neat > OpensearchUserRoleBinding_%.yaml';
OpensearchTenant
kubectl get OpensearchTenant -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchtenant.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchTenant -n shturval-logging % -o yaml | kubectl neat > opensearchTenant_%.yaml';
- Убедиться, что "Модуль централизованного хранения логов" (shturval-logs-operator) был отключен (установлен "mode: absent"), дождать удаления всех подов в неймспейсе shturval-logging кластера управления.
- Удалить PVC с префиксом "data-logs-" в неймспейсе shturval-logging кластера управления.
- Удалить кастомные ресурсы с зачисткой финалайзеров, используя команды:
OpensearchUser
find . -name "OpensearchUser_*.yaml" | xargs -P32 -i{} kubectl delete --force -f {}
kubectl get OpensearchUser -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchuser.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchUser -n shturval-logging % -o json | jq '.metadata.finalizers = null' | kubectl apply -f -';
OpensearchRole
find . -name "OpensearchRole_*.yaml" | xargs -P32 -i{} kubectl delete --force -f {}
kubectl get OpensearchRole -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchrole.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchRole -n shturval-logging % -o json | jq '.metadata.finalizers = null' | kubectl apply -f -';
OpensearchUserRoleBinding
find . -name "OpensearchUserRoleBinding_*.yaml" | xargs -P32 -i{} kubectl delete --force -f {}
kubectl get OpensearchUserRoleBinding -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchuserrolebinding.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchUserRoleBinding -n shturval-logging % -o json | jq '.metadata.finalizers = null' | kubectl apply -f -';
OpensearchTenant
find . -name "OpensearchTenant_*.yaml" | xargs -P32 -i{} kubectl delete -f {}
kubectl get OpensearchTenant -n shturval-logging -o name -l app.kubernetes.io/managed-by!=Helm | sed -e 's/opensearchtenant.opensearch.opster.io\///g' | xargs -I % sh -c 'echo %; kubectl get OpensearchTenant -n shturval-logging % -o json | jq '.metadata.finalizers = null' | kubectl apply -f -';
- Включить "Модуль централизованного хранения логов" (shturval-logs-operator), выбрать автоматический режим управления сервисом и дождаться полной инициализации кластера Opensearch.
- Загрузить выгруженные локально манифесты кастомных ресурсов в кластер управления, используя команды:
OpensearchUser
find . -name "opensearchUser_*.yaml" | xargs -i{} kubectl create -f {}
OpensearchRole
find . -name "opensearchRole_*.yaml" | xargs -i{} kubectl create -f {}
OpensearchUserRoleBinding
find . -name "OpensearchUserRoleBinding_*.yaml" | xargs -i{} kubectl create -f {}
OpensearchTenant
find . -name "opensearchTenant_*.yaml" | xargs -i{} kubectl create -f {}
- Проверить успешность загрузки ресурсов можно с помощью команды, которая выведет список имен всех неуспешно загруженных ресурсов:
OpensearchUser
for name in $(k get -n shturval-logging OpensearchUser -o=jsonpath='{$.items[?(@.status.state!="CREATED")].metadata.name}'); do echo $name; done
OpensearchRole
for name in $(k get -n shturval-logging OpensearchRole -o=jsonpath='{$.items[?(@.status.state!="CREATED")].metadata.name}'); do echo $name; done
OpensearchUserRoleBinding
for name in $(k get -n shturval-logging OpensearchUserRoleBinding -o=jsonpath='{$.items[?(@.status.state!="CREATED")].metadata.name}'); do echo $name; done
OpensearchTenant
for name in $(k get -n shturval-logging OpensearchTenant -o=jsonpath='{$.items[?(@.status.state!="CREATED")].metadata.name}'); do echo $name; done
После полной реконсиляции восстановленных ресурсов кластер Opensearch будет готов к работе.
Увеличение объема хранилища OpenSearch
Для модуля централизованного хранения логов (shturval-logs-operator) может потребоваться увеличение объема дискового пространства. При необходимости можно изменить объем диска из графического интерфейса Комплекса путем внесения изменений в спецификацию модуля.
Все действия по увеличению дискового пространства для модуля выполняются в кластере управления.
Увеличение дискового пространства shturval-logs-operator
- В кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль централизованного хранения логов" (shturval-logs-operator) (рисунок 413).
Рисунок 413 ‒ Модуль централизованного хранения логов
- Открыть карточку модуля и в блоке "Спецификация сервиса" указать желаемый объем дискового пространства, используя параметр конфигурации diskSize, например (описание параметров ‒ в таблице 50):
cluster:
nodePoolsMaster:
diskSize: <ваше значение параметра>
- Сохранить внесенные изменения для модуля.
Объем дискового пространства для модуля централизованного хранения логов будет изменен согласно указанным значениям в diskSize.
Добавление дашборда в Opensearch
Кастомный дашборд в интерфейсе Opensearch можно создать с помощью редактирования объектов в интерфейсе Комплекса и правки конфигураций в интерфейсе OpenSearch.
Дашборд Ingress
- В кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль управления внешними подключениями" (shturval-ingress-controller) и нажать
Управлять. В блоке "Спецификация сервиса" в секцию "controller" добавить "config", например (описание параметров ‒ в таблице 51):
controller:
config:
log-format-escape-json: 'true'
log-format-upstream: <ваше значение параметра>
Далее необходимо сохранить изменения.
- В кластере управления в боковом меню открыть раздел "Сервисы и репозитории" и перейти на страницу "Установленные сервисы", найти "Модуль локального сбора логов" (shturval-log-collector) и нажать
Управлять. В блоке "Спецификация сервиса" добавить секцию "shturval" логов k8s_logs. В параметре "transforms" задать parse_ingress_logs и переопределить inputs для filter_system_namespaces, например:
shturval:
k8s_logs:
transforms:
parse_ingress_logs:
type: remap
inputs: [dedot_fields]
source: |
if .kubernetes.pod_namespace == "ingress" && .stream == "stdout" {
parsed = parse_json!(.message)
. = merge!(., parsed)
del(.message)
}
filter_system_namespaces:
type: filter
inputs: [parse_ingress_logs]
condition: |
.kubernetes.namespace_labels."shturval_tech/type" == "system"
- В кластере управления нажать кнопку
Логии авторизоваться в интерфейсе OpenSearch (рисунок 414).
Рисунок 414 ‒ Авторизация в интерфейсе OpenSearch
- Создать Index Pattern для кластера, в котором необходимо сделать дашборд. В случае если Index Pattern уже создан, перейти к следующему пункту.
- В интерфейсе OpenSearch перейти в раздел "Dashboards Management" на страницу "Saved Objects".
- На открывшейся странице нажать
Importи загрузить файл с дашбордом и связанными визуализациями в формате NDJSON (рисунок 415).
Рисунок 415 ‒ Страница импорта
- Выбрать Index Pattern, к которому необходимо применить конфигурацию (рисунок 416).
Рисунок 416 ‒ Выбор Index Pattern
Отобразится список дашбордов, которые будут загружены (рисунок 417):
Рисунок 417 ‒ Список загруженных дашбордов
- Сохранить конфигурацию.
- Перейти на страницу "Dashboards". На странице будет доступен дашборд "Ingress" (рисунок 418).
Рисунок 418 ‒ Дашборд "Ingress"
Дашборд Kube-API
Для доступа к дашборду Kube-API необходимо:
- Нажать кнопку
Логии авторизоваться в интерфейсе OpenSearch. - Создать Index Pattern для индекса с префиксом
*_kaudit-*. Это приведет к созданию единого Index Pattern для kube-audit индексов всех кластеров. - В интерфейсе OpenSearch перейти в раздел "Dashboards Management" на страницу "Saved Objects".
- На открывшейся странице нажать
Importи загрузить файл kube-api.ndjson в формате NDJSON. - Выбрать IndexPattern, к которому необходимо применить конфигурацию (рисунок 419).
Рисунок 419 ‒ Выбор IndexPattern
- Сохранить конфигурацию.
- Перейти на страницу "Dashboards". На странице будет доступен дашборд "Kubernetes API Audit" (рисунок 420).
Рисунок 420 ‒ Дашборд "Kubernetes API Audit"