Изменение размера дискового пространства и предельного срока хранения логов Loki

При работе системы может потребоваться изменение размера дискового пространства и предельного срока хранения логов Loki: например, если логи коллекторов и конвейеров не отображаются из-за исчерпания дискового пространства, доступного для Loki.

Чтобы изменить данные параметры, выполните следующие действия:

Ознакомьтесь с нижеприведенными инструкциями и измените конфигурацию Loki и MinIO в соответствии с параметрами вашей инсталляции:
- Увеличение доступного дискового пространства для Loki и MinIO
- Настройка размера квот для MinIO
Скорректируйте параметры ротации логов в соответствии с доступными вам ресурсами.
По завершении настройки проверьте статус компонентов Loki.

Увеличение доступного дискового пространства для Loki и MinIO

Способ увеличения дискового пространства, доступного для Loki и MinIO, зависит от используемого вами провайдера хранилища.

Чтобы определить, какой провайдер используется в вашей инсталляции:

Подключитесь к терминалу кластера.
Дальнейшие действия будут осуществляться с объектами в пространстве имен kube-prometheus-stack. Создайте переменную NS, которая будет хранить его название:
```
NS=kube-prometheus-stack
```

Получите название провайдера хранилища:

SC=$(kubectl get pvc loki-minio -n "$NS" -o jsonpath='{.spec.storageClassName}')
kubectl get sc "$SC" -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner,EXPAND:.allowVolumeExpansion

Пример вывода команды:

NAME         PROVISIONER                            EXPAND
local-path   cluster.local/local-path-provisioner   true

Дальнейшие действия различаются для провайдера local-path-provisioner и провайдера с CSI-плагином, такого как Piraeus с Linstor:

local-path-provisioner
Провайдер с CSI-плагином

Увеличивать размер PVC для Loki и MinIO при использовании local-path-provisioner не следует. Параметр allowVolumeExpansion для local-path-provisioner не работает, поэтому увеличение размера PVC не приведет к фактическому увеличению дискового пространства, доступного для Loki и MinIO.

Вместо изменения размера PVC следует очистить дисковое пространство на worker-узле, где находится под loki-minio. Это можно сделать следующим образом:

Определите, на каком worker-узле находится под loki-minio:

kubectl get pod -n "$NS" -l app=minio,release=loki -o wide

Пример вывода команды:

NAME                         READY   STATUS    RESTARTS   AGE    IP            NODE      NOMINATED NODE   READINESS GATES
loki-minio-95c766b6b-jcq46   1/1     Running   0          163d   10.244.1.58   evo-w01   <none>           <none>

В данном примере под loki-minio находится на worker-узле evo-w01.

Определите, в каком каталоге или каталогах хранятся данные local-path-provisioner:
```
kubectl get cm local-path-config -n local-path-provisioner -o jsonpath='{.data.config\.json}'
```
Пример вывода команды:
```
{
  "nodePathMap": [
    {
      "node": "DEFAULT_PATH_FOR_NON_LISTED_NODES",
      "paths": [
        "/opt/local-path-provisioner"
      ]
    }
  ]
}
```
В примере данные local-path-provisioner хранятся в каталоге /opt/local-path-provisioner.

Каталогов может быть несколько, если в кластере настроено несколько объектов StorageClass для local-path-provisioner.
Подключитесь к worker-узлу, на котором находится под loki-minio.
Определите процент свободного дискового пространства, доступного local-path-provisioner. Это можно сделать, выполнив следующую команду для каждого из каталогов, полученных на предыдущем шаге:
```
df -h <path_to_dir>
```
Здесь:
- <path_to_dir> — путь к каталогу данных local-path-provisioner.

Если свободно менее 10% дискового пространства, очистите диск worker-узла от невостребованных данных.

Квоты MinIO рекомендуется увеличивать, только если:

они существуют в системе;
есть достаточный объем свободного дискового пространства.

Получите запрашиваемый и фактически доступный размер хранилища loki-minio:
```
kubectl get pvc loki-minio -n "$NS" -o jsonpath='spec={.spec.resources.requests.storage} capacity={.status.capacity.storage}'
```
Пример вывода команды:
```
spec=10Gi capacity=10Gi
```
Увеличьте запрашиваемый размер хранилища:
```
NEW_SIZE=<new_size>
kubectl patch pvc loki-minio -n "$NS" --type=merge \
  -p "{\"spec\":{\"resources\":{\"requests\":{\"storage\":\"${NEW_SIZE}\"}}}}"
```
Здесь:
- <new_size> — новый запрашиваемый размер хранилища в ГиБ. Должен быть строго больше предыдущего. Например, 20Gi.
Дождитесь, когда фактически доступный размер хранилища станет равным размеру, запрошенному на предыдущем шаге. Вы можете наблюдать за состоянием PVC, выполнив следующую команду:
```
kubectl get pvc loki-minio -n "$NS" -w
```
Доступный размер хранилища отображается в столбце CAPACITY, например:
```
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
loki-minio   Bound    pvc-c247c5f9-4264-419c-8737-738d00efd0da   20Gi       RWO            local-path     198d
```
Чтобы прекратить наблюдение за состоянием PVC, нажмите на сочетание клавиш CTRL+C.

Настройка размера квот для MinIO

Чтобы получить сведения о существующих в системе квотах для MinIO и при необходимости изменить их, выполните следующие действия:

Получите сведения о занятом дисковом пространстве и квотах MinIO:
1. Получите имя образа MinIO Client (MC), выполнив следующую команду:
  helm get hooks loki -n "$NS" | grep -E 'image:.*mc' | head -1
  Если команда выполнена успешно, то имя образа находится в строке с префиксом image, например:
  image: "minio/mc:RELEASE.2025-08-13T08-35-41Z-cpuv1"
  В таком случае искомое имя образа — minio/mc:RELEASE.2025-08-13T08-35-41Z-cpuv1.
  Если выполнение команды завершилось с ошибкой Error: release: not found, получите реестр, имя и тег образа из секрета evo.infra.global, выполнив следующие команды:
  
  kubectl -n <namespace> get secret evo.infra.global -o jsonpath='{.data.IMAGE_REGISTRY}' | base64 -d kubectl -n <namespace> get secret evo.infra.global -o jsonpath='{.data.IMAGE_MC}' | base64 -d kubectl -n <namespace> get secret evo.infra.global -o jsonpath='{.data.IMAGE_TAG}' | base64 -d
  
  Здесь:
  
  <namespace> — название пространства имен, в котором установлена система.
  
  Вы можете получить название пространства имен, в котором установлена система, с помощью утилиты evoctl.
  Имя образа имеет следующий формат:
  <image_registry>/<image_mc>:<image_tag>
  Здесь:
  - <image_registry> — значение ключа IMAGE_REGISTRY в секрете evo.infra.global, например: minio.
  - <image_mc> — значение ключа IMAGE_MC в секрете evo.infra.global, например: mc.
  - <image_tag> — значение ключа IMAGE_TAG в секрете evo.infra.global, например: RELEASE.2025-08-13T08-35-41Z-cpuv1.
2. Удалите задачу (job) loki-minio-mc:
  kubectl delete job -n "$NS" loki-minio-mc --ignore-not-found
3. Создайте задачу повторно, выполнив следующую команду:
  cat <<'YAML' | kubectl apply -f - apiVersion: batch/v1 kind: Job metadata: name: loki-minio-mc namespace: kube-prometheus-stack spec: ttlSecondsAfterFinished: 600 backoffLimit: 1 template: spec: restartPolicy: Never volumes: - name: etc-path emptyDir: {} - name: tmp emptyDir: {} - name: minio-configuration projected: sources: - configMap: name: loki-minio - secret: name: loki-minio containers: - name: mc image: <mc_image_name> command: ["/bin/sh", "-c"] args: - | set -e MC="/usr/bin/mc --insecure --config-dir /etc/minio/mc/" ACCESS=$(cat /config/rootUser) SECRET=$(cat /config/rootPassword) $MC alias set myminio http://loki-minio:9000 "$ACCESS" "$SECRET" echo "===== admin info =====" $MC admin info myminio echo "===== quota =====" $MC quota info myminio/chunks || true $MC quota info myminio/ruler || true $MC quota info myminio/admin || true echo "===== du =====" $MC du myminio/chunks || true echo "===== ilm =====" $MC ilm rule ls myminio/chunks || true volumeMounts: - name: etc-path mountPath: /etc/minio/mc - name: tmp mountPath: /tmp - name: minio-configuration mountPath: /config resources: requests: cpu: 50m memory: 64Mi YAML
  Здесь:
  - <mc_image_name> — имя образа MinIO MC, полученное ранее, например: minio/mc:RELEASE.2025-08-13T08-35-41Z-cpuv1.
4. Включите ожидание выполнения задачи:
  kubectl wait --for=condition=complete job/loki-minio-mc -n "$NS" --timeout=120s
5. Откройте логи задачи:
  kubectl logs job/loki-minio-mc -n "$NS"
6. Проанализируйте логи задачи:
  - Если в логах присутствует строка вида Bucket chunks has hard quota of N GiB, значит, квоты для MinIO настроены. Следует обновить их значения по нижеприведенной инструкции.
  - Если выполнение задачи завершилось с ошибкой или квоты в логах не упоминаются, значит, квоты для MinIO отсутствуют. Настраивать их вручную не следует. Перейдите к настройке ротации и периода хранения логов.
Проверьте размер PVC Loki:
```
kubectl get pvc loki-minio -n "$NS" -o jsonpath='.status.capacity.storage'
```
Пример вывода команды:
```
10Gi
```

Определите размер квот для бакетов MinIO chunks, ruler и admin в следующем соотношении:

chunks — 80% от размера PVC, выделенного для Loki;
ruler — 10% от размера PVC, выделенного для Loki;
admin — 10% от размера PVC, выделенного для Loki.

Например:

Размер PVC Loki Размер chunks Размер ruler Размер admin

Размер PVC Loki	Размер `chunks`	Размер `ruler`	Размер `admin`
`10Gi`	`8Gi`	`1Gi`	`1Gi`
`15Gi`	`12Gi`	`1.5Gi`	`1.5Gi`
`20Gi`	`16Gi`	`2Gi`	`2Gi`

10Gi

8Gi

1Gi

15Gi

12Gi

1.5Gi

20Gi

16Gi

2Gi

Если в вашей инсталляции используется провайдер хранилища local-path-provisioner, перед увеличением квот убедитесь, что на диске, выделенном для данных local-path-provisioner, есть свободное дисковое пространство в объеме не менее двух размеров PVC Loki. Это позволит обеспечить запас пространства даже при исчерпании новой квоты.

Проверить объем свободного дискового пространства можно по инструкции для local-path-provisioner из предыдущего раздела. При необходимости освободите дополнительное пространство.

Установите новый размер квот с помощью задачи:

Удалите задачу loki-minio-mc:

kubectl delete job -n "$NS" loki-minio-mc --ignore-not-found

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

cat <<'YAML' | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: loki-minio-mc
  namespace: kube-prometheus-stack
spec:
  ttlSecondsAfterFinished: 600
  backoffLimit: 1
  template:
    spec:
      restartPolicy: Never
      volumes:
        - name: etc-path
          emptyDir: {}
        - name: tmp
          emptyDir: {}
        - name: minio-configuration
          projected:
            sources:
              - configMap:
                  name: loki-minio
              - secret:
                  name: loki-minio
      containers:
        - name: mc
          image: <mc_image_name>
          command: ["/bin/sh", "-c"]
          args:
            - |
              set -e
              MC="/usr/bin/mc --insecure --config-dir /etc/minio/mc/"
              ACCESS=$(cat /config/rootUser)
              SECRET=$(cat /config/rootPassword)
              $MC alias set myminio http://loki-minio:9000 "$ACCESS" "$SECRET"

              $MC quota set myminio/chunks --size <chunks_size>
              $MC quota set myminio/ruler --size <ruler_size>
              $MC quota set myminio/admin --size <admin_size>
              $MC quota info myminio/chunks
          volumeMounts:
            - name: etc-path
              mountPath: /etc/minio/mc
            - name: tmp
              mountPath: /tmp
            - name: minio-configuration
              mountPath: /config
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
YAML

Здесь:

<mc_image_name> — имя образа MinIO MC, полученное ранее, например: minio/mc:RELEASE.2025-08-13T08-35-41Z-cpuv1.
<chunks_size> — новый размер квоты для бакета chunks, например: 12Gi.
<ruler_size> — новый размер квоты для бакета ruler, например: 1.5Gi.
<admin_size> — новый размер квоты для бакета admin, например: 1.5Gi.

Включите ожидание выполнения задачи:

kubectl wait --for=condition=complete job/loki-minio-mc -n "$NS" --timeout=120s

Откройте логи задачи:
```
kubectl logs job/loki-minio-mc -n "$NS"
```
Убедитесь, что в логах присутствуют строки Successfully set bucket quota для каждого из бакетов, например:
```
Successfully set bucket quota of 12Gi on chunks
Successfully set bucket quota of 1.5Gi on ruler
Successfully set bucket quota of 1.5Gi on admin
```

При обновлении Loki (например, во время обновления системы) значения квот могут сброситься до указанных в helm-чарте. После обновления системы рекомендуется проверить актуальные значения квот и при необходимости повторно изменить их.

Настройка ротации и периода хранения логов

Включите ротацию и настройте период хранения логов в Loki. Для этого:

Создайте резервную копию ConfigMap loki:
```
kubectl get cm loki -n "$NS" -o yaml > loki-cm.backup.yaml
```
Откройте ConfigMap для редактирования:
```
kubectl edit cm loki -n "$NS"
```

Измените следующие параметры в блоке data.config.yaml:

Чтобы включить ротацию логов, в блоке compactor установите для параметра retention_enabled значение true:
```
compactor:
  retention_enabled: true
```

В блоке limits_config установите значения следующих параметров:

retention_period — время ротации логов, хранимых в Loki. Измеряется в часах, например: 168h.
reject_old_samples — должны ли устаревшие логи с временными метками раньше, чем reject_old_samples_max_age, отбрасываться Loki. Рекомендуется установить значение true.

reject_old_samples_max_age — максимальный возраст логов, которые будут приняты Loki. Логи с временными метками раньше, чем reject_old_samples_max_age, будут отброшены. Измеряется в часах.

Значение reject_old_samples_max_age не должно превышать retention_period.

Рекомендуется устанавливать для reject_old_samples_max_age значение от 24h до 72h. Слишком малое значение может привести к отсечению логов, которые не были своевременно записаны в Loki из-за сбоя, что может привести к невозможности установить причину сбоя.

Пример заполнения блока limits_config:

limits_config:
  retention_period: 168h
  reject_old_samples: true
  reject_old_samples_max_age: 48h

Одноименные параметры, такие как retention_period, могут присутствовать в блоке table_manager. Их значения изменять не следует.

Получите названия контроллеров StatefulSet и Deployment, которые потребуется перезапустить:

kubectl get sts,deploy -n "$NS" | grep -iE 'loki|minio'

Пример вывода команды:

statefulset.apps/loki-backend     1/1     198d
statefulset.apps/loki-write       1/1     197d
deployment.apps/loki-gateway      1/1     1            1           128d
deployment.apps/loki-minio        1/1     1            1           197d
deployment.apps/loki-read         1/1     1            1           128d

Перезапустите контроллеры StatefulSet и Deployment, указанные в списке. Команда для примера выше:

kubectl rollout restart statefulset.apps/loki-backend statefulset.apps/loki-write deployment.apps/loki-gateway deployment.apps/loki-minio deployment.apps/loki-read -n "$NS"

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

kubectl rollout status <controller_name> -n "$NS" --timeout=180s

Здесь:

<controller_name> — имя контроллера, например: statefulset/loki-backend.

Команды для примера выше:

kubectl rollout status statefulset/loki-backend -n "$NS" --timeout=180s
kubectl rollout status statefulset/loki-write -n "$NS" --timeout=180s
kubectl rollout status deployment/loki-gateway -n "$NS" --timeout=180s
kubectl rollout status deployment/loki-minio -n "$NS" --timeout=180s
kubectl rollout status deployment/loki-read -n "$NS" --timeout=180s

Дождитесь применения обновленных параметров Loki. Например, для версии 3.4.2 применение занимает порядка 15 минут.

Убедитесь, что Loki использует новые значения параметров:

kubectl exec -n "$NS" loki-backend-0 -c loki -- wget -qO- http://127.0.0.1:3100/config \
  | grep -E 'retention_period|reject_old_samples_max_age|retention_enabled|apply_retention|retention_delete_delay'

Удалите резервную копию ConfigMap loki:
```
rm loki-cm.backup.yaml
```

При обновлении Loki (например, во время обновления системы) значения параметров могут сброситься до указанных в helm-чарте. После обновления системы рекомендуется проверить актуальные значения параметров и при необходимости изменить их.

Проверка статуса компонентов Loki

По завершении настройки убедитесь, что система Loki готова к приему логов:

Убедитесь, что компоненты loki-write и loki-backend имеют статус ready:
```
kubectl exec -n "$NS" loki-write-0 -c loki -- wget -qO- http://127.0.0.1:3100/ready
kubectl exec -n "$NS" loki-backend-0 -c loki -- wget -qO- http://127.0.0.1:3100/ready
```
В результате выполнения обеих команд должно отобразиться сообщение ready.
Убедитесь, что в логах компонента loki-write нет ошибок:
```
kubectl logs -n "$NS" loki-write-0 -c loki --tail=100 | grep -iE 'error|quota|no space|429' || true
```
В результате выполнения команды должно отобразиться сообщение true.
Убедитесь, что в логах контроллера Deployment r-space.vector-aggregator нет ошибок:
kubectl logs -n <namespace> deploy/r-space.vector-aggregator --tail=80 | grep -iE 'error|loki|timeout|429' || true
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
В результате выполнения команды должно отобразиться сообщение true.

Убедитесь, что контроллер Deployment loki-read готов к работе:

kubectl exec -n "$NS" deploy/loki-read -c loki -- wget -qO- http://127.0.0.1:3100/loki/api/v1/labels | jq .

В результате выполнения команды должен содержаться параметр "status":"success", например:

{
  "status": "success",
  "data": [
    "app",
    "app_kubernetes_io_instance",
    "app_kubernetes_io_name",
    "component",
    "container",
    "container_image",
    "evo_r_huc_component",
    "evo_space_component",
    "evo_space_module_name",
    "evo_space_space_id",
    "evo_space_workload_id",
    "evo_space_workload_name",
    "evo_space_workload_type",
    "extra_selector_label",
    "filename",
    "global_extra_selector_label",
    "global_pod_label",
    "host",
    "instance",
    "job",
    "kind",
    "level",
    "module_path",
    "namespace",
    "node_name",
    "pod",
    "pod_label",
    "pod_name",
    "pod_node_name",
    "pod_template_hash",
    "service_name",
    "stream",
    "target"
  ]
}

Была ли полезна эта страница?

Обратная связь