---

Работа с обновлениями

Обновление агента

Поставщик оповещает клиентов о выходе новых версий агента, предоставляет ссылку на скачивание бинарных версий агента.

Для выполнения обновления агентов на серверах необходимо:

• разместить файл с агентом в S3-bucket по пути agent/<version>/<os>/<arch>/okagent, например, agent/0.86.3/linux/amd64/okagent

Масштабирование

Среди всех компонентов сервиса, как правило, в масштабировании нуждаются только collector и mimir.

Collector

На одну тысячу клиентских подключений коллектору требуется 1 ядро CPU и приблизительно 6 GiB RAM. Рекомендуется иметь не менее двух реплик компонента collector. В случае необходимости, масштабирование прозводится увеличением количества реплик (поле replicas) values-файла компонента.

Mimir

ingester

Для приема 1М активных серий при рекомендуемом факторе репликации 3 требуется 1 ядро CPU и 14 GiB RAM. Минимальное количество реплик ingester - 3. В зависимости от объема активных серий количество ingester-ов может быть увеличено изменением поля ingester.replicas values-файла компонента mimir. Также, ingester можно масштабировать горизонтально, выделив ему больше памяти в секции ingester.resources, при этом, во избежание застревания подов ingester в состоянии pending нужно учитывать наличие свободных ресурсов на нодах.

Дополнительные сведения можно получить в официальной документации

compactor

Тенаты mimir (проект в терминологии okmeter) равномеро распределяются по имеющимся компакторам. Каждый компактор выполняет задачи по слиянию блоков для своей группы тенантов. Таким образом compactor имеет смысл масштабировать горизонтально только при наличии множества тенантов (проектов в okmeter). Вертикальное масштабирование не имеет смысла, поскольку одна реплика компактора не может использовать более 1 ядра процессора и единиц гигабайт памяти.

В случае, если один тенант генерирует слишком большое количество метрик и цикл компакта не успевает выполится в заданное время - можно применить шардирование компакторов, как описано в официальной документации

store-gateway

Данный компонент хранит на диске заголовки индексных файлов prometheus-блоков. Размер этих данных составляет единицы процентов от общего размера блока, таким образом, общее потребление дискового пространства компонентом зависит от количества метрик и глубины их хранения.

Потребление памяти компонентом зависит от “сложности” запроса: временного диапазона и количество одновременно извлекаемых серий метрик.

При увеличении количество реплик компонента потребление дискового пространства и памяти снижается пропорционально.

Дополнительные сведения можно получить в официальной документации

querier

Так же как и у store-gateway, потребление памяти querier зависит от количества извлекаемых серий и ширины временного диапазона запроса.

Компонент может масштабироваться горизонтально - путём увеличения количества реплик. В определенных случаях, при выполнении запроса, извлекающего большое количество серий, компоненту может не хватать ресурсов указанных в querier.resources. При обнаружении перезапусков пода по причине OOM необходимо увеличить querier.resources.requests.memory и querier.resources.requests.memory, либо нарастить количество реплик компонента, дабы снизить число одновременных запросов на каждой реплике, либо снизить config.limits.max_fetched_series_per_query

Дополнительные сведения можно получить в официальной документации

Хранилище S3

Хранилище на основе ceph является предпочтительным вариантом в виду высокой гибкости и надежности решения.

Minio

Увеличение объема хранилища на базе Minio производится путем добавления дополнительного пула серверов в кластер. Минимальный размер пула - 4 сервера, каждый из серверов должен содержать минимум 2 диска. Рекомендуется добавлять пул такой же конфигурации (количество серверов, дисков, их размер) как и первоначальный.

Добавление пула производится изменением custom resource оператора minio Tenant: spec.pools

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

Ceph

Увеличение объема хранилища на базе Ceph осуществляется:

• добавлением дополнительных дисков в существующие узлы ceph
• добавлением дополнительных узлов ceph в соответствующую NodeGroup

Необходимо убедится, что имена устройств дисков подпадают под регулярное выражение в spec.storage.deviceFilter custom resource CephCluster.

После добавления дисков или узлов необходимо перезапустить под с rook ceph operator:

kubectl -n okmeter-operator-rook-ceph delete po -l app=rook-ceph-operator

После чего в namespace rook-ceph-cluster должны появится поды новых OSD. За процессом ребаланса кластера можно наблюдать выполняя соответствующие команды из пода rook-ceph-tools:

kubectl -n rook-ceph-cluster exec -it deploy/rook-ceph-tools bash
ceph -s

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