Диагностика неисправностей

Okmeter поставляется вместе с набором дашбодов, графиков и алертов для встроенного в Deckhouse модуля мониторинга. Ниже приведен список алертов, ошибок и способа их диагностики, и исправления.

Alerts

MimirIngesterRestarts

Во-первых, проверьте, относится ли алерт к одному ingester или к нескольким. Даже если алерт касается только одного ingester’а, лучше всего подстраховаться, запуская kubectl get pods –namespace=<prod/staging/etc.> каждые несколько минут. Другой вариант — последить за запросом rate(kube_pod_container_status_restarts_total{container="ingester"}[30m]) > 0 и убедиться, что за ним не скрывается серьезная проблема, вызывающая множественные перезапуски.

Далее проверьте вывод команды kubectl get events с флагом --namespace и без него. Это позволит обнаружить перезапуски узлов или другие связанные проблемы. Отфильтровать вывод поможет команда grep или другие похожим инструментом.

Наиболее распространенной причиной этого алерта является разовый перезапуск ноды в кластере, в результате чего ingester с этого узла перезжает на другую ноду.

В списке event’ов на это будут указывать сообщения следующего вида:

57m Normal NodeControllerEviction Pod Marking for deletion Pod ingester-01 from Node worker--node-01
37m Normal SuccessfulDelete ReplicaSet (combined from similar events): Deleted pod: ingester-01
32m         Normal    NodeNotReady              Node   Node worker-node-01 status is now: NodeNotReady
28m         Normal    DeletingAllPods           Node   Node worker-node-01 event: Deleting all Pods from Node worker-node-01.

Если установить причину на основании event’ов не удается, проверьте, нет ли повышенной нагрузки:

Если выросло количество активных серий, а выделенной памяти недостаточно, необходимо увеличить количество реплик для ingester, чтобы на каждый ingester приходилось такое же число серий, как и раньше.
Входящий трафик может увеличиться из-за сбоя с последующим возвращением Mimir к работе (или) из-за отстающего remote-write Prometheus на стороне клиентов, из-за чего семплы начинают отправляться с более высокой частотой (опять же, увеличение трафика, но вызванное ростом числа образцов). В этом случае также необходимо увеличить количество реплик ingester.

MimirRequestLatency

Этот алерт срабатывает, когда некоторый маршрут Mimir испытывает высокую задержку. Сообщение алерта включает в себя как сервис Mimir, так и проблемный маршрут. С его помощью определите, относится ли алерт к read- или write-пути.

Write latency

Выясняем, в чем проблема:

Проверьте панель мониторинга Mimir / Writes
- Она должна показать, в каком сервисе Mimir возникала высокая задержка
- Панели на панели мониторинга вертикально отсортированы по сетевому пути (например, gateway -> distributer -> ingester).
Определите проблемное место в стеке.
- gateway
  - Задержка может быть обусловлена временем, которое требуется gateway для получения всего запроса от клиента. Это может произойти по множеству причин, поэтому может потребоваться общение с пользователем. Например:
    - Сетевые проблемы, например, потеря пакетов между клиентом и gateway.
    - Низкая производительность промежуточных сетевых узлов, таких как балансировщики нагрузки или HTTP-прокси.
    - Недостаток CPU-ресурсов у клиентского процесса.
  - Возможно, потребуется увеличить количество реплик gateway.
- Возможна проблема с аутентификацией (например, компонент аутентификации работает медленно);
- distributer
  - Как правило, 99-й процентиль (p99) задержки на distributer находится в диапазоне 50-100 мс. Если задержка выше этого значения, увеличить количество реплик для distributer.
- ingester
  - Как правило, 99-й процентиль задержки ingester’а находится в диапазоне 5-50 мс. Если фактическая задержка превышает этот показатель, необходимо выяснить причину проблемы, прежде чем масштабировать число ingester’ов.
  - Для этого проверьте, не сработали ли следующие алерты, после чего устраните причину их срабатывания:
    - MimirProvisioningTooManyActiveSeries
    - MimirProvisioningTooManyWrites

Read latency

Производительность запросов - известная проблема. Запрос может быть медленным из-за высокой кардинальности, большого временного диапазона и/или из-за неиспользования кэша (например, запрос к данным серии, которые еще не кэшированы). При анализе этого алерта следует проверить, вызван ли он несколькими медленными запросами, или существует проблема с работой/конфигурацией, которую необходимо устранить.

Выясняем, в чем проблема:

Проверьте панель мониторинга Mimir / Reads
- Она должна показать, в каком сервисе Mimir возникала высокая задержка
- Панели в панели мониторинга упорядочены по вертикали по сетевому пути (например, gateway -> query-frontend -> querier -> store-gateway).
Проверьте панель мониторинга Mimir / Slow Queries на наличие медленных запросов;
Определите проблемное место в стеке.
- gateway
  - Возможно, потребуется увеличить количество реплик gateway.
  - Возможна проблема с аутентификацией (например, компонент аутентификации работает медленно);
- query-frontend
  - Возможно, необходимо увеличить количество реплик для query-frontend.
- querier
  - Изучите trace’ы медленных запросов, чтобы понять, где именно они тормозят.
  - Как правило, медлительность связана либо с работой движка PromQL (innerEval), либо с получением чанков (chunks) из ingester’ов и/или store-gateway’ев.
  - Если медлительность вызвана работой движка PromQL, обычно мало что можно сделать. Масштабирование querier’ов может помочь только в том случае, если querier-узлы перегружены.
  - Если медлительность связана с получением чанков из ingester’ов и/или store-gateway’ев, необходимо глубже изучить первопричину. Частые причины:
    - Высокая загрузка процессоров в ingester’ах
      - Увеличьте количество реплик для ingester
    - Низкий коэффициент попадания в кэш в store-gateway
      - Проверьте панель мониторинга Memcached Overview
      - Если частота вытеснений memcached высока, следует увеличить число реплик memcached.
      - Если частота вытеснения memcached равна нулю или очень низка, причиной могут быть первичные (first-time) запросы;
    - Таймауты запросов к кэшу
      - В логах store-gateway поищите предупреждения о таймауте запросов Memcached (пример запроса: {namespace="okmeter-mimir", name=~"store-gateway.*"} |= "level=warn" |= "memcached" |= "timeout")
      - Если в них действительно много сообщений о таймаутах Memcached-запросов, попробуйте изменить настройки таймаута Memcached в store-gateway (-blocks-storage.bucket-store.chunks-cache.memcached.timeout).

MimirRequestErrors

Этот алерт срабатывает, когда количество 5xx ошибок для определенного маршрута превышает 1% в течение некоторого времени.

Этот алерт обычно используется как крайнее средство для обнаружения проблем / сбоев. Предполагается, что SLO-алерты сработают раньше: если SLO-алерт сработал для того же пути чтения/записи, можно проигнорировать этот алерт и сосредоточиться на алерте SLO (при этом процедура анализа обычно остается неизменной).

Выясняем, в чем проблема:

Установите, для какого пути сработал алерт (см. маршруты Mimir и соответствующие пути);
- Write-путь: откройте панель Mimir / Writes;
- Reda-путь: откройте панель Mimir / Reads;
На панели должно быть видно, в каком сервисе Mimir возникла ошибка;
Панели на панели мониторинга упорядочены по вертикали по сетевому пути (например, для write-пути: gateway -> distributer -> ingester).
- Если сбой сервиса вызван недостатком памяти (OOM): отмасштабируйте его или увеличьте память.
Если сбойный сервис аварийно завершает/не может продолжать работу: найдите трассировку стека в логах и исследуйте ее;
- Если сбойным сервисом является query-frontend, querier или store-gateway, и включена функция “activity tracker”, поищите в логе информацию о незавершенных операциях в предыдущем сообщении о запуске и в последующих сообщениях об операциях. Это поможет узнать, какие именно запросы привели к сбою.
Если Memberlist используется как KV-хранилище для хеш-колец, убедитесь, что он работает правильно. См. инструкции к алерту MimirGossipMembersMismatch.

MimirIngesterUnhealthy

Этот алерт срабатывает, когда один или несколько ingester’ов помечены как unhealthy. Проверьте страницу c hash ring, чтобы узнать, какие из них помечены как unhealthy. После этого можно в логах поискать информацию, связанную с задействованными ingester’ами, например, с помощь команды kubectl logs -f ingester-01 --namespace=prod. Возможно, для решения проблемы будет достаточно нажать на кнопку “Forget” (“Забыть”) на странице с hash ring, особенно если Pod больше не существует. Это может быть связано с тем, что Pod работал на узле, который был отключен. Проверьте логи на наличие информации об узле на котором есть/был Pod, например: kubectl get events --namespace=prod | grep worker-node.

MimirCompactorHasNotSuccessfullyCleanedUpBlocks

Этот алерт срабатывает, когда компактор Mimir долгое время не может успешно удалить блоки, помеченные для удаления.

Выясняем, в чем проблема:

Убедитесь, что компактор не “падает” во время работы (например, из-за OOM)
Проверьте логи компактора на ошибки (например, ошибки типа bucket Delete API)

MimirCompactorHasNotSuccessfullyCleanedUpBlocksSinceStart

То же, что и для MimirCompactorHasNotSuccessfullyCleanedUpBlocks.

MimirCompactorHasNotUploadedBlocks

Этот алерт срабатывает, когда компактор Mimir долгое время не загружает сжатые блоки в хранилище.

Выясняем, в чем проблема:

Если параллельно с этим алертом сработал MimirCompactorHasNotSuccessfullyRunCompaction, сначала изучите его.
Если параллельно с этим алертом сработали MimirIngesterHasNotShippedBlocks или MimirIngesterHasNotShippedBlocksSinceStart, сначала попытайтесь установить причину их возникновения.
Убедитесь, что ingester’ы успешно отправляют блоки в хранилище.
Проверьте логи компактора на наличие соответствующих ошибок;

MimirCompactorHasNotSuccessfullyRunCompaction

Этот алерт срабатывает, если компактор не в состоянии компактировать все обнаруженные уплотняемые блоки (у всех тенантов).

Появление этого алерта означает, что по какой-то причине уплотнение некоторых блоков не может быть завершено, при этом compactor может вполне успешно уплотнять остальные блоки. Обычно это связано с попытками уплотнить поврежденный блок для одного из тенантов. В этом случае уплотнение блоков для других тенантов продолжает работать, в то время как для пострадавшего тенанта уплотнение блокируется поврежденным блоком.

Выясняем, в чем проблема:

Проверьте логи компактора на наличие соответствующих ошибок;
- Corruption: not healthy index found
- Invalid result block:
  - Как обнаружить: в логах компактора ищите сообщение invalid result block.
  - Что это значит: Компактор успешно проверил исходные блоки. Но валидация конечного блока после уплотнения не удалась. Он не был загружен, и задание уплотнения будет повторено.
  - Out-of-order chunks:
    - Как обнаружить: в логах компактора ищите сообщения invalid result block и out-of-order chunks.
    - Это вызвано ошибкой в ingester’е — см. mimir#1537. Ingester’ы загружают блоки, в которых MinT и MaxT некоторых chunk’ов не совпадают с первым и последним образцами в chunk’е. Если MinT и MaxT дефектных chunk’ов пересекаются с другими chunk’ами, компактор объединяет их. Поскольку MinT и MaxT одного chunk’а неверны, слияние может произойти неправильно, что приведет к тому, что сэмплы будут идти не по порядку.
  - Как устранить проблему: Пометьте поврежденные блоки, чтобы избежать их уплотнения в будущем:
    - Найдите все пострадавшие группы уплотнения в логах компактора. Узнать их можно из сообщений invalid result block /data/compact/<группа_уплотнения>/<result_block>.
    - Для каждого сбойного задания уплотнения:
      - Выберите один итоговый блок (неважно, какой);
      - Найдите исходные блоки для задания уплотнения: ищите msg="compact blocks" и упоминание ID итогового блока.
      - Пометьте исходные блоки как не подлежащие уплотнению (в данном примере бэкендом объектного хранилища является GCS): ./tools/markblocks/markblocks -backend s3 -s3.bucket_name <bucket> -s3.endpoint <endpoint> -s3.region <region> -s3.secret_access_key <secret_access_key> -s3.access_key_id <access_key_id> -mark no-compact -tenant <tenant-id> -details "Leading to out-of-order chunks when compacting with other blocks" <block-1> <block-2>...

MimirCompactorSkippedBlocksWithOutOfOrderChunks

Этот алерт срабатывает, когда compactor пытается уплотнить блок, но обнаруживает, что в данном блоке есть неупорядоченные chunk’и. Это указывает на ошибку в библиотеке Prometheus TSDB и требует изучения.

Compactor сбоит из-за того, что найден поврежденный индекс

Уплотнение блоков может провалиться из-за поврежденного индекса блока в одном из исходных блоков:

level=error ts=2020-07-12T17:35:05.516823471Z caller=compactor.go:339 component=compactor msg="failed to compact user blocks" user=REDACTED-TENANT err="compaction: group 0@6672437747845546250: block with not healthy index found /data/compact/0@6672437747845546250/REDACTED-BLOCK; Compaction level 1; Labels: map[__org_id__:REDACTED]: 1/1183085 series have an average of 1.000 out-of-order chunks: 0.000 of these are exact duplicates (in terms of data and time range)"z

Если это произошло, необходимо:

Переименуйте блок, добавив к нему префикс corrupted-, чтобы компактор и querier’ы пропускали его. Имейте в виду, что при этом блок станет невидимым и для querier’ов, поэтому его серии/выборки не будут запрашиваться. Если повреждения затрагивают только 1 блок с уровнем уплотнения, равным 1 (информация хранится внутри его meta.json), Mimir гарантирует сохранность данных, поскольку они реплицируются в другие блоки. Во всех остальных случаях возможна некоторая потеря данных после переименования блока и прекращения запросов к нему.
Убедитесь, что компактор восстановился
Исследуйте первопричину в офлайн-режиме (например, скачайте поврежденный блок и проведите его анализ).

Переименовать блок можно с помощью следующей команды Minio Client:

mc mv s3://BUCKET/TENANT/BLOCK s3://BUCKET/TENANT/corrupted-BLOCK

Где:

BUCKET — имя бакета gcs, которое использует компактор. Имя бакета для кластера указывается в конфигурации кластера (blocks_storage_bucket_name);
TENANT — идентификатор тенанта, указанный в приведенном выше сообщении об ошибке как REDACTED-TENANT;
BLOCK — последняя часть пути к файлу, о которой сообщается как REDACTED-BLOCK в примере сообщения об ошибке выше

MimirBucketIndexNotUpdated

Этот алерт срабатывает, когда индекс бакета для данного тенанта не обновлялся в течение длительного времени. Ожидается, что индекс бакета будет периодически обновляться компактором и использоваться querier’ами и store-gateway’ми для получения почти обновленного представления о хранилище.

Выясняем, в чем проблема:

Убедитесь, что компактор работает;
Проверьте логи компактора на наличие соответствующих ошибок;

MimirTenantHasPartialBlocks

Этот алерт срабатывает, когда Mimir находит partial block для данного тенанта. partial block — это блок, в котором отсутствует meta.json; обычно такое происходит в двух случаях:

Загрузка блока была прервана, не очищена и не повторена;
Удаление блока было прервано, и deletion-mark.json был удален раньше meta.json.

Выясняем, в чем проблема:

Проведите поиск на наличие неполных блоков в логах. Пример запроса Loki: {cluster="",namespace="",container="compactor"} |= "skipped partial block"
Выберите блок и запишите его ID (поле block в записи в логе) и ID тенанта (org_id в записи в логе).
Найдите бакет, используемый кластером Mimir, например, можно посмотреть заданный параметр blocks_storage_bucket_name, если используется Jsonnet.
Выясните, какой компонент Mimir работал с блоком последним (например, загружался он ingester/compactor или удалялся compactor).
Определите, когда был загружен неполный блок: mc ls -l s3://${BUCKET}/${TENANT_ID}/${BLOCK_ID}. Также можно использовать команду ulidtime из каталога инструментов Mimir (ulidtime ${BLOCK_ID}), чтобы узнать время создания блока.
По времени найдите в логах запись о создании блока компактором (ищите в логе сообщение с “compacted blocks”).
В найденной записи скопируйте ID задания из поля groupKey, например, 0@9748515562602778029-merge--1645711200000-1645718400000
Затем проведите в логах поиск по ID задания и найдите запись с сообщением “compaction job failed”. Это укажет на то, что компактор не смог загрузить блок.
Если на предыдущем шаге была обнаружена соответствующая запись, попробуйте найти сообщение с “compaction job succeeded” для такого же ID. Это означает, что повторная попытка выполнения задания компактирования прошла успешно.
Примечание: при этом должен получиться ID блока, отличный от ID блока, для которого загрузка не удалась.
.
Установите, была ли это частичная загрузка или частичное удаление.
Если это было частичное удаление или неудачная загрузка компактором, вы можете смело пометить блок на удаление, и компактор удалит его. Для этого можно воспользоваться командой markblocks из каталога инструментов Mimir: markblocks -mark deletion -allow-partial -tenant с правильными настройками бэкенда.
Если это была неудачная загрузка ingester, которая не была повторена (ожидается, что ingester будут пытаться загрузить блок до тех пор, пока не добьются успеха), необходимо дополнительное изучение.
Предотвратите повторное возникновение ingester можно, включив автоматическую очистку неполных блоков. Это можно сделать с помощью флага -compactor.partial-block-deletion-delay. В качестве аргумента следует указать период времени. Если неполный блок сохраняется дольше указанного периода времени, компактор автоматически удалит его. Отслеживать автоматическую очистку частичных блоков можно с помощью счетчика cortex_compactor_blocks_marked_for_deletion_total{reason="partial"}.

MimirProvisioningTooManyActiveSeries

Этот алерт срабатывает, если среднее количество in-memory-серий на один ingester превышает целевой показатель (1,5M).

Как это исправить:

Отмасштабируйте ingester’ы
- Найти кластеры Mimir, требующие масштабирования ingester (и прикинуть нужное количество реплик) можно с помощью следующего запроса: ceil(sum by(cluster, namespace) (cortex_ingester_memory_series) / 1.5e6) > count by(cluster, namespace) (cortex_ingester_memory_series)
После увеличения масштаба число in-memory-серий должно снизиться при следующем компактировании head-блока TSDB (происходит каждые 2 часа).

MimirProvisioningTooManyWrites

Этот алерт срабатывает, если среднее количество обработанных сэмплов в секунду в ingester выше целевого значения.

Как это исправить:

Отмасштабируйте ingester’ы
- Чтобы вычислить необходимое количество ingester для удовлетворения средней скорости выборки, можно выполнить следующий запрос, заменив анализируемое пространство имен и целевое количество выборок/сек на ingester (текущее целевое значения можно взять из порогового значения для алерта): sum(rate(cortex_ingester_ingested_samples_total{namespace="<namespace>"}[$__rate_interval])) / (<target> * 0.9)

MimirAllocatingTooMuchMemory

Этот алерт срабатывает, когда использование памяти для ingester приближается к лимиту.

Как это работает:

ingesters Mimir — stateful-сервисы;
Завершение работы двух или более ингесторов из-за OOM (OOMKilled) может привести к сбою кластера;
Базовое использование памяти ingester преимущественно складывается из памяти, занимаемой процессом (в основном heap-память Go) и mmap-файлами (используются TSDB-базой);
Кратковременные скачки в использовании памяти ingester в основном вызваны запросами и компактированием head-блока TSDB в новые блоки (происходит каждые 2 часа);
Прекращение работы Pod’а из-за OOMKilled случается, когда объем занимаемой его рабочими нагрузками памяти достигает заданного лимита, поэтому важно следить за тем, чтобы использование памяти ingester не приближалось к лимиту (необходим запас как минимум в 30% из-за скачков в употреблении памяти, вызванных запросами).

Как это исправить:

Проверьте, возникает ли проблема только у нескольких ingester. Если это так:
- Перезапустите затронутые ингридиенты по одному (переходите к следующему после перезапуска предыдущего и его готовности). kubectl -n <namespace> delete pod ingester-XXX
- Перезапуск ingester обычно приводит к уменьшению памяти, занимаемой mmap-файлами. После перезапуска ingester со времене может опять занять эту память, но это обеспечит вам необходимый запас времени для поиска более надежного/долгосрочного решения.
Проверьте, не превышает ли количество серий на один ingester целевое значение (1.5M) (дашборд Mimir / Writes Resources). Если это так:
- Увеличьте количество реплик для ingester; определить их необходимое количество можно, например, с помощью дашборда Mimir / Scaling (следует учитывать, что каждый ingester должен обрабатывать ~1,5 миллиона серий, а серии будут дублироваться по трем инстансам).
- Предполагается, что память будет освобождена при следующем компактировании head-блока TSDB (происходит каждые 2 часа).

EtcdAllocatingTooMuchMemory

Этот алерт срабатывает, если в etcd слишком много ключей, связанных с HA-дедупликацией. Например, этот алерт сработал, когда на одном из наших кластеров число тенантов, использующих конфиг для хранения данных о HA-дедупликации, превысило 20 тыс. Поднимите лимиты etcd:

  etcd+: {
    spec+: {
      pod+: {
        resources+: {
          limits: {
            memory: '2Gi',
          },
        },
      },
    },
  },

MimirRolloutStuck

Этот алерт срабатывает, когда выкат сервиса Mimir по какой-то причине не произошел, то есть количество обновленных реплик не совпадает с ожидаемым и прогресс в развертывании отсутствует. Алерт отслеживает сервисы, развертываемые как StatefulSet’ы и Deployment’ы.

Выясняем, в чем проблема:

Получите список работающих Pod’ов: kubectl -n <namespace> get pods -l name=<statefulset|deployment>;
Убедитесь, что отсутствуют Pod’ы в нерабочем состоянии (например, Error, OOMKilled, CrashLoopBackOff);
Убедитесь, что нет Pod’в в состоянии NotReady (число ready-контейнеров должно соответствовать общему количеству контейнеров, например, 1/1 или 2/2);
Выполните команду kubectl -n <namespace> describe statefulset <name> или kubectl -n <namespace> describe deployment <name> и изучите колонки “Pod Status” и “Events” в поисках дополнительной информации.

MimirKVStoreFailure

Этот алерт срабатывает, если инстанс Mimir не может выполнить какую-либо операцию с KV-хранилищем. При использовании Memberlist в качестве KV-хранилища для hash ring, все операции чтения и обновления работают с локальной копией hash ring (то есть для них этот алерт неактуален).

Как это работает:

Etcd обычно используется трекером HA (distributer) для хранения информации для дедупликации сэмплов.
Если инстанс терпит неудачу при выполнении операций на hash ring, то либо инстанс не может послать heartbeat-сигнал (показывает, что инстанс в порядке и работает нормально) в кольцо, либо не получает обновления из кольца.
Если инстансу не удается выполнить операции на бэкенде трекера HA, это означает, что инстанс либо не может обновить авторитетную реплику, либо не получает обновления.

Выясняем, в чем проблема:

Убедитесь, что etcd запущен и работает.
Изучите логи затронутого инстанса в поисках ошибки, связанной с etcd.

Справочник ошибок

У Mimir есть кодированные идентификаторы ошибок, которые можно встретить в ответах HTTP или логах. Используя эти идентификаторы, можно найти соответствующую ошибку и ее описание (см. ниже).

err-mimir-missing-metric-name

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию без имени метрики. У каждой серии должно быть имя метрики. Иногда это не так, что может указывать на ошибку в клиенте отправителя.

Примечание: Недопустимые серии пропускаются при ингестировании; допустимые серии в том же запросе ингестируются.

err-mimir-metric-name-invalid

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию с недопустимым именем метрики. Имя метрики может содержать только символы, соответствующие формату Prometheus для названий метрик и лейблов.

err-mimir-max-label-names-per-series

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию с количеством лейблов, превышающим настроенный лимит. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы настроить лимит для каждого тенанта, используйте параметр -validation.max-label-names-per-series.

err-mimir-label-invalid

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию с недопустимым именем лейбла. Имя лейбла может содержать только символы, соответствующие формату Prometheus для названий метрик и лейблов.

err-mimir-label-name-too-long

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию с именем лейбла, длина которого превышает настроенный лимит. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы настроить лимит для каждого тенанта, используйте параметр -validation.max-length-label-name option.

err-mimir-label-value-too-long

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию со значением лейбла, длина которого превышает настроенный лимит. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы настроить лимит для каждого тенанта, используйте параметр -validation.max-length-label-value.

err-mimir-duplicate-label-names

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий серию с именем лейбла, которое встречается два или более раз. Серия, содержащая дубликат имени лейбла, является недопустимой и пропускается при загрузке.

err-mimir-labels-not-sorted

Эта ошибка возникает, когда Mimir получает запрос на запись, содержащий серию, имена лейблов которой не отсортированы по алфавиту. Однако Mimir внутренне сортирует лейблы для получаемых серий, поэтому на практике эта ошибка не должна встречаться. Если вы столкнулись с этой ошибкой, откройте issue в репозитории Mimir.

err-mimir-too-far-in-future

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий семпл, временная метка которого находится в будущем по сравнению с текущим “реальным” временем. Mimir принимает временные метки, которые находятся немного в будущем, например, из-за отклонения часов. Однако он отклоняет временные метки, которые находятся слишком далеко в будущем; период, после которого метка будет считаться “слишком опережающей”, можно задать с помощью -validation.create-grace-period. Для каждого тенанта можно точно настроить допустимое значение, настроив параметр -validation.max-length-label-value.

Примечание: Серии с недопустимыми семплами пропускаются при ингестировании; серии с допустимыми семплами в том же запросе ингестируются.

err-mimir-exemplar-labels-missing

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

Примечание: Недопустимые образцы пропускаются при ингестировании; допустимые образцы в том же запросе ингестируются.

err-mimir-exemplar-labels-too-long

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий образец, в котором суммарный размер набора лейблов превышает лимит. Лимит обеспечивает стабильность системы и защищает ее от возможных злоупотреблений или ошибок; его нельзя настроить.

err-mimir-exemplar-timestamp-invalid

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий образец без временной метки. Образец должен иметь действительную временную метку, иначе его не получится соотнести с каким-либо моментом времени.

err-mimir-metadata-missing-metric-name

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий метаданные метрики без имени метрики. У каждых метаданных метрики должно быть имя метрики. Иногда это не так, что может указывать на ошибку в клиенте отправителя.

Примечание: Недопустимые метаданные метрики пропускаются при ингестировании; допустимые метаданные в том же запросе ингестируются.

err-mimir-metric-name-too-long

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий метаданные метрики и именем метрики, длина которого превышает заданный лимит. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы настроить лимит для каждого тенанта, используйте параметр -validation.max-metadata-length.

err-mimir-unit-too-long

Эта некритическая ошибка возникает, когда Mimir получает запрос на запись, содержащий метаданные метрики с названием единицы измерения, длина которого превышает заданный лимит. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы настроить лимит для каждого тенанта, используйте параметр -validation.max-metadata-length.

err-mimir-distributor-max-ingestion-rate

Эта критическая ошибка возникает, когда число поступающих сэмплов, образцов и метаданных в секунду превышает лимит, заданные в distributer. distributer реализует ограничение на количество записываемых семплов в секунду; оно защищает distributer от перегрузки в случае наплыва трафика. Этот лимит применяется ко всем сэмплам, образцам и всем метаданным, которые получает инстанс. Кроме того, лимит распространяется на всех тенантов в рамках каждого distributer.

Как это исправить:

Увеличьте количество реплик для distributer.
Увеличьте лимит с помощью параметра -distributor.instance-limits.max-ingestion-rate.

err-mimir-distributor-max-inflight-push-requests

Эта ошибка возникает, когда distributer отклоняет запрос на запись, потому что максимальный лимит запросов “в процессе выполнения” был достигнут.

Как это работает:

distributer имеет ограничение на количество активных (т.е. инициированных, но не завершенных) запросов на запись (push) для каждого инстанса. Лимит применяется ко всем таким запросам на запись по всем тенантам, и защищает distributer от перегрузки в случае большого трафика. Настроить лимит можно с помощью параметра -distributor.instance-limits.max-inflight-push-requests.

Как это исправить:

Увеличьте лимит с помощью параметра -distributor.instance-limits.max-inflight-push-requests.
Проверьте задержку запросов на запись в дашборде Mimir / Writes и попробуйте выяснить причину высокой задержки (чем выше задержка, тем выше количество активных запросов на запись).
Рассмотрите возможность увеличения количества реплик для distributer.

err-mimir-distributor-max-inflight-push-requests-bytes

Эта ошибка возникает, когда distributer отклоняет запрос на запись, потому что максимальный размер в байтах активных (в процессе выполнения) запросов был достигнут.

Как это работает:

У distributer есть ограничение на общий размер в байтах всех активных запросов на запись (push) для каждого инстанса.
Лимит применяется ко всем активным запросам на запись по всем тенантам, и защищает distributer от нехватки памяти в случае большого трафика или высокой задержки на write-пути.
Настроить лимит можно с помощью параметра -distributor.instance-limits.max-inflight-push-requests-bytes.

Как это исправить:

Увеличьте лимит с помощью параметра -distributor.instance-limits.max-inflight-push-requests-bytes.
Проверьте задержку запросов на запись в дашборде Mimir / Writes и попробуйте выяснить причину увеличенного размера запросов или повышенной задержки (чем выше задержка, тем выше количество активных запросов на запись и больше их совокупный размер).
Рассмотрите возможность увеличения количества реплик для distributer.

err-mimir-ingester-max-ingestion-rate

Эта критическая ошибка возникает, когда число поступающих сэмплов в секунду превышает лимит, заданный в ingester. ingester реализует ограничение на количество ингестируемых семплов в секунду; оно защищает ingester от перегрузки в случае наплыва трафика. Этот лимит, задаваемый для каждого инстанса, применяется ко всем семплам, которые тот получает. Кроме того, лимит распространяется на всех тенантов в рамках каждого ingester.

Как это исправить:

Отмасштабируйте число ingester.
Увеличьте лимит с помощью -ingester.instance-limits.max-ingestion-rate (или max_ingestion_rate в конфигурации среды исполнения).

err-mimir-ingester-max-tenants

Эта критическая ошибка возникает, когда ingester получает запрос на запись для нового тенанта (тенанта, для которого еще не было сохранено ни одной серии), однако ingester не может принять его, поскольку было достигнуто максимальное количество разрешенных тенантов на ingester.

Как это исправить:

Увеличьте лимит с помощью -ingester.instance-limits.max-tenants (или max_tenants в конфигурации среды исполнения).
Рассмотрите возможность включение shuffle-шардинга для ingester, чтобы уменьшить количество тенантов, приходящихся на ingester.

err-mimir-ingester-max-series

Эта критическая ошибка возникает, когда ingester отклоняет запрос на запись, поскольку достигнуто максимальное количество серий в памяти.

Как это работает:

ingester хранит в памяти самые недавние серии данных.
У ingester есть ограничение на количество серий в памяти на инстанс. Оно защищает ingester от перегрузок в случае наплыва трафика.
Когда предел количества серий в памяти достигнут, новые серии отбрасываются, в то время как сэмплы по-прежнему могут добавляться к существующим сериям.
Настроить лимит можно с помощью -ingester.instance-limits.max-series (или max_series в конфигурации среды исполнения).

Как это исправить:

См. руководство по MimirIngesterReachingSeriesLimit.

err-mimir-ingester-max-inflight-push-requests

Эта ошибка возникает, когда ingester отклоняет запрос на запись, потому что максимальный лимит запросов “в процессе выполнения” был достигнут.

Как это работает:

У ingester есть ограничение на количество активных (т.е. инициированных, но не завершенных) запросов на запись (push) для каждого инстанса. Лимит применяется ко всем таким запросам на запись по всем тенантам, и защищает ingester от перегрузки в случае большого трафика. Настроить лимит можно с помощью -ingester.instance-limits.max-inflight-push-requests (или max_inflight_push_requests в конфигурации среды исполнения).

Как это исправить:

Увеличьте лимит с помощью -ingester.instance-limits.max-inflight-push-requests (или max_inflight_push_requests в конфигурации среды исполнения).
Проверьте задержку запросов на запись в дашборде Mimir / Writes и попробуйте выяснить причину высокой задержки (чем выше задержка, тем выше количество активных запросов на запись).
Рассмотрите возможность масштабирования ingester.

err-mimir-max-series-per-user

Эта ошибка возникает, когда количество серий в памяти для данного тенанта превышает настроенный лимит. Лимит защищает ingester от перегрузки в случае, если тенант пишет большое количество серий и обеспечивает стабильность всей системы, оберегая ее от возможных злоупотреблений или ошибок. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -ingester.max-global-series-per-user (или max_global_series_per_user в конфигурации среды исполнения).

Как это исправить:

Убедитесь, что фактическое количество серий для затронутого тенанта верное.
Рассмотрите возможность увеличения лимита в расчете на тенанта с помощью опции -ingester.max-global-series-per-user (или max_global_series_per_user в конфигурации среды исполнения).

err-mimir-max-series-per-metric

Эта ошибка возникает, когда количество серий в памяти для данного тенанта и имя метрики превышает настроенный лимит. Лимит преимущественно предназначен для защиты тенанта от возможных ошибок при снятии метрик. Например, если инструментированное приложение публикует метрику со значением лейбла, включающим динамичные данные (например, временную метку), ингестирование этой метрики быстро приведет к превышению лимита серий на тенанта, в результате и другие метрики будут отклонены. Этот лимит вводит ограничение на максимальное количество серий для каждого имени метрики; превышающие серии отбрасываются только для данного имени метрики, прежде чем будет достигнут лимит серий в расчете на тенанта. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -ingester.max-global-series-per-metric (или max_global_series_per_metric в конфигурации среды исполнения).

Как это исправить:

Изучите сообщение об ошибке и выясните, какое имя метрики затронуто.
Проверьте, правильно ли задано количество серий, экспортируемых для данного имени метрики.
Рассмотрите возможность снижения кардинальности затронутой метрики, настроив или удалив некоторые из ее лейблов.
Рассмотрите возможность увеличения лимита в расчете на каждого тенанта с помощью параметра -ingester.max-global-series-per-metric.
Рассмотрите возможность исключения конкретных имен метрик из проверки для данного лимита с помощью опции -ingester.ignore-series-limit-for-metric-names (или max_global_series_per_metric в конфигурации среды исполнения).

err-mimir-max-metadata-per-user

Эта некритическая ошибка возникает, когда количество метрик in-memory с метаданными для данного тенанта превышает настроенный лимит. Метаданные метрики — набор сведений, прикрепленных к имени метрики, таких как ее единица измерения (например, счетчик) и описание. Метаданные метрики могут быть включены отправителем в запрос на запись, и они возвращаются при запросе на API-endpoint /api/v1/metadata. Метаданные метрики хранятся в памяти ingester, поэтому чем больше метаданных метрики хранится, тем выше загрузка памяти. Mimir имеет ограничение на количество имен метрик, к которым прикреплены метаданные, для каждого тенанта. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы задать лимиты в расчете на каждого тенанта, воспользуйтесь параметром -ingester.max-global-series-per-user (или max_global_metadata_per_user в конфигурации среды исполнения).

Как это исправить:

Проверьте текущее число имен метрик для затронутого тенанта, выполнив моментальный запрос count(count by(__name__) ({__name__=~".+"})). Также можно получить кардинальность метки __name__, вызвав API-endpoint /api/v1/cardinality/label_names.
Рассмотрите возможность увеличения лимита в расчете на каждого тенанта до значения, превышающего количество уникальных имен метрик, возвращенных предыдущим запросом.

err-mimir-max-metadata-per-metric

Эта некритическая ошибка возникает, когда количество различных метаданных для данного имени метрики превышает настроенный лимит.

Метаданные метрики — набор сведений, прикрепленных к имени метрики, таких как ее единица измерения (например, счетчик) и описание. Как правило, для каждого имени метрики существует только один набор метаданных (например, одно и то же имя метрики, экспортируемой разными приложениями, имеет один и тот же счетчик и описание). Однако возможны граничные случаи, когда одно и то же имя метрики имеет разное значение в разных приложениях или одинаковое значение, но слегка отличающееся описание. В таких граничных случаях разные приложения будут экспортировать разные метаданные для одного и того же имени метрики.

Этот предел обеспечивает стабильность всей системы, защищая ее от возможных злоупотреблений или ошибок, например, в случае неограниченного роста числа вариантов метаданных для данного имени метрики. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -ingester.max-global-series-per-metric (или max_global_metadata_per_metric в конфигурации среды исполнения).

Как это исправить:

Проверьте метаданные для затронутого имени метрики, запросив API-endpoint /api/v1/metadata?metric=<name> (замените на имя метрики).
Если метаданные отличаются от ожидаемых, рассмотрите возможность устранения расхождения в инструментированных приложениях.
- Если метаданные соответствуют ожиданиям, рассмотрите возможность увеличения лимита в расчете на каждого тенанта с помощью опции -ingester.max-global-series-per-metric (или max_global_metadata_per_metric в конфигурации среды исполнения).

err-mimir-max-chunks-per-query

Эта ошибка возникает, когда при выполнении запроса превышается ограничение на количество получаемых чанков серии. Этот лимит обеспечивает стабильность системы и защищает ее от возможных злоупотреблений или ошибок, когда выполняется запрос, извлекающий огромное количество данных. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -querier.max-fetched-chunks-per-query (или max_fetched_chunks_per_query в конфигурации среды исполнения).

Как это исправить:

Рассмотрите возможность сокращения временного диапазона и/или кардинальности запроса. Чтобы уменьшить кардинальность запроса, вы можете добавить в запрос больше сопоставляющих лейблов, ограничив тем самым количество подходящих серий.
Рассмотрите возможность увеличения лимита в расчете на тенанта с помощью опции -querier.max-fetched-chunks-per-query (или max_fetched_chunks_per_query в конфигурации среды исполнения).

err-mimir-max-series-per-query

Эта ошибка возникает, когда при выполнении запроса превышается ограничение на максимальное число серий. Этот лимит обеспечивает стабильность системы и защищает ее от возможных злоупотреблений или ошибок, когда выполняется запрос, извлекающий огромное количество данных. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -querier.max-fetched-series-per-query (или max_fetched_series_per_query в конфигурации среды исполнения).

Как это исправить:

Рассмотрите возможность сокращения временного диапазона и/или кардинальности запроса. Чтобы уменьшить кардинальность запроса, вы можете добавить в запрос больше сопоставляющих лейблов, ограничив тем самым количество подходящих серий.
Рассмотрите возможность увеличения лимита в расчете на тенанта с помощью опции -querier.max-fetched-series-per-query (или max_fetched_series_per_query в конфигурации среды исполнения).

err-mimir-max-chunks-bytes-per-query

Эта ошибка возникает, когда при выполнении запроса превышается ограничение на суммарный размер (в байтах) получаемых чанков. Этот лимит обеспечивает стабильность системы и защищает ее от возможных злоупотреблений или ошибок, когда выполняется запрос, извлекающий огромное количество данных. Чтобы задать лимиты по тенантам, воспользуйтесь параметром -querier.max-fetched-chunk-bytes-per-query (или max_fetched_chunk_bytes_per_query в конфигурации среды исполнения).

Как это исправить:

Рассмотрите возможность сокращения временного диапазона и/или кардинальности запроса. Чтобы уменьшить кардинальность запроса, вы можете добавить в запрос больше сопоставляющих лейблов, ограничив тем самым количество подходящих серий.
Рассмотрите возможность увеличения лимита в расчете на тенанта с помощью опции -querier.max-fetched-chunk-bytes-per-query (или max_fetched_chunk_bytes_per_query в конфигурации среды исполнения).

err-mimir-max-query-length

Эта ошибка возникает, когда временной диапазон частичного (после возможного разделения, чередования query-фронтэндом) запроса превышает настроенную максимальную длину. Ограничение общей длины запроса см. в разделе ### err-mimir-max-total-query-length.

Как моментальные, так и диапазонные запросы PromQL могут получать данные метрик за определенный период времени. Для диапазонного запроса требуется начальная и конечная метка времени, поэтому разница между конечной и начальной метками является длиной временного диапазона запроса. Для моментального запроса требуется параметр времени; запрос выполняется, получая сэмплы в этот момент времени. Однако даже моментальный запрос может получить данные метрики за определенный период времени с помощью селекторов вектора диапазона. Например, моментальный запрос sum(rate(http_requests_total{job=“prometheus”}[1h])) собирает метрики за период в 1 час. Этот период времени в Grafana Mimir называется “длиной временного диапазона запроса” (или длиной запроса).

У Mimir есть ограничение на длину запроса. Этот лимит применяется к частичным запросам, после того как они были разделены (по времени) query-фронтэндом. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы задать лимиты в расчете на каждого тенанта, воспользуйтесь параметром -store.max-query-length (или max_query_length в конфигурации среды исполнения).

err-mimir-max-total-query-length

Эта ошибка возникает, когда временной диапазон запроса превышает заданную максимальную длину. О лимите на длину частичного запроса (после разбиения запроса на интервалы и/или шардинга) см. в разделе ### err-mimir-max-query-length. Диапазонные запросы PromQL могут получать данные метрик за определенный период времени. Для диапазонного запроса требуется начальная и конечная метка времени, поэтому разница между конечной и начальной метками является длиной временного диапазона запроса. У Mimir есть ограничение на длину запроса. Этот лимит применяется к диапазонным запросам до того, как они будут разделены (по времени) или шардированы query-фронтэндом. Этот лимит обеспечивает стабильность системы, защищая ее от возможных злоупотреблений или ошибок. Чтобы задать лимиты в расчете на каждого тенанта, воспользуйтесь параметром -query-frontend.max-total-query-length (или max_total_query_length в конфигурации среды исполнения). Если данный лимит установлен в 0, он берет свое значение из -store.max-query-length.

err-mimir-tenant-max-request-rate

Эта ошибка возникает, когда для данного тенанта превышена частота запросов на запись в секунду.

Как это работает:

Существует ограничение на количество запросов на запись в секунду для каждого тенанта, и оно применяется ко всем distributer для данного тенанта.
Лимит реализован с использованием токен-бакетов.

Как это исправить:

Увеличьте лимит на каждого тенанта с помощью -distributor.request-rate-limit (количество запросов в секунду) и -distributor.request-burst-size (число запросов) (или request_rate и request_burst_size в конфигурации среды исполнения). Настраиваемый параметр форсирования (burst) определяет, возможное временное превышение числа запросов в случае коротких всплесков трафика. Настроенный параметр форсирования должен быть больше или равен настроенному лимиту.

err-mimir-tenant-max-ingestion-rate

Эта ошибка возникает, когда для данного тенанта превышена частота получения сэмплов, образцов и метаданных в секунду.

Как это работает:

Для каждого тенанта существует ограничение на количество сэмплов, образцов и метаданных, которые могут быть получены в секунду, и оно применяется ко всем distributer для данного тенанта.
Лимит реализован с использованием токен-бакетов.

Как это исправить:

Увеличьте лимит в расчете на каждого тенанта с помощью -distributor.ingestion-rate-limit (количество сэмплов в секунду) и -distributor.ingestion-burst-size (число сэмплов) (или ingestion_rate и ingestion_burst_size в конфигурации среды исполнения). Настраиваемый параметр форсирования (burst) определяет, какое количество сэмплов, образцов и метаданных может временно превысить лимит в случае краткосрочных всплесков трафика. Настроенный параметр форсирования должен быть больше или равен настроенному лимиту.

err-mimir-tenant-too-many-ha-clusters

Эта ошибка возникает, когда distributer отклоняет запрос на запись, потому что количество кластеров высокой доступности (HA) достигло настроенного лимита для данного тенанта.

Как это работает:

distributer реализует верхнее ограничение на количество кластеров для тенанта, которые будет отслеживать HA-трекер.
Он срабатывает, когда запрос на запись приводит к добавлению нового кластера, в то время как количество кластеров, имеющихся у тенанта в данный момент, уже равно лимиту.
Для настройки лимита воспользуйтесь параметром -distributor.ha-tracker.max-clusters (или ha_max_clusters в конфигурации среды исполнения).

Как это исправить:

Увеличьте лимит на каждого тенанта с помощью опции -distributor.ha-tracker.max-clusters (или ha_max_clusters в конфигурации среды исполнения).

err-mimir-sample-timestamp-too-old

Эта ошибка возникает, когда ingester отклоняет сэмпл, поскольку его временная метка слишком старая по сравнению с самой последней временной меткой, полученной для того же тенанта по всем его временным сериям.

Как это работает:

Если входящая временная метка более чем на 1 час старше самой свежей временной метки, полученной для тенанта, сэмпл будет отклонен.

Примечание: Если включена функция ингестирования сэмплов не по порядку, эта ошибка аналогична приведенной ниже ### err-mimir-sample-out-of-order с той разницей, что сэмпл старше, чем временное out-of-order-окно, поскольку оно относится к самоме свежему сэмплу для данного временного ряда или TSDB.

err-mimir-sample-out-of-order

Эта ошибка возникает, когда ingester отклоняет сэмпл, поскольку другой сэмпл с более недавней временной меткой уже был ингестирован.

Как это работает:

В настоящее время сэмплы по могу ингестироваться не по порядку для определенной серии.

Частые причины:

В коде есть target, который экспортирует один и тот же временной ряд несколько раз, или несколько target’ов с одинаковыми лейблами.
Системное время инстанса Prometheus было сдвинуто назад. Если это произошло из-за ошибки, исправьте системное время на нормальное. В противном случае дождитесь, пока системное время догонит момент изменения.
Используется несколько инстансов Prometheus для отправки одних и тех же метрик, а трекер высокой доступности не настроен должным образом на дедупликацию.
В Prometheus настроена перемаркировка (relabelling), и это приводит к конфликту серий после перемаркировки. Проверьте сообщение об ошибке на наличие информации о том, какая серия получила сэмпл не по порядку.
Инстанс Prometheus был перезапущен, и при перезапуске все данные из его Write-Ahead Log’а были отправлены на удаленную запись, при этом часть данных уже были отправлены и ингестированы. Это нормально и может быть проигнорировано.

Примечание: Дополнительную информацию о сэмплах не по порядку в Prometheus можно найти в статье “Что делать с сэмплами не по порядку”.

err-mimir-sample-duplicate-timestamp

Эта ошибка возникает, когда ingester отклоняет сэмпл, поскольку тот является дубликатом ранее полученного сэмпла с той же временной меткой, но другим значением в том же временном ряду.

Частые причины:

Несколько endpoint’ов экспортируют одну и ту же метрику, или несколько инстансов Prometheus собирают разные метрики с одинаковыми лейблами.
В Prometheus настроена перемаркировка (relabelling), и это приводит к конфликту серий после перемаркировки. Проверьте сообщение об ошибке на наличие информации о том, какая серия получила дублирующий сэмпл.

err-mimir-exemplar-series-missing

Эта ошибка возникает, когда ingester отклоняет образец, потому что связанная с ним серия еще не была ингестрирована.

Как это работает:

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

err-mimir-store-consistency-check-failed

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

Как это работает:

Mimir разработан таким образом, чтобы гарантировать корректность результатов запроса и никогда не возвращать неполные результаты запроса. Либо запрос проходит успешно, возвращая полностью консистентные результаты, либо завершается неудачно.
Querier’ы и ruler’ы, работающие в режиме “внутренней” оценки, выполняют проверку согласованности, чтобы убедиться, что все ожидаемые блоки были запрошены из долговременного хранилища через store-gateway’и.
Если какой-либо ожидаемый блок не был запрошен через store-gateway’и, запрос завершится неудачей с этой ошибкой.
Подробнее см. в разделе Анатомия запроса.

Как это исправить:

Убедитесь, что все store-gateway’и работают нормально.
Убедитесь, что все store-gateway’и успешно синхронизируют принадлежащие блоки (см. MimirStoreGatewayHasNotSyncTheBucket).

err-mimir-bucket-index-too-old

Эта ошибка возникает, когда запрос завершается неудачей из-за того, что индекс бакета слишком старый.

Как это работает:

Компакторы периодически записывают в объектное хранилище файл для каждого тенанта, называемый “бакет-индексом”. Бакет-индекс содержит все известные блоки для данного тенанта и обновляется через промежуток времени, заданный параметром -compactor.cleanup-interval.
При выполнении запроса querier’ы и ruler’ы, работающие в режиме “внутренней” оценки, просматривают бакет-индекс, чтобы определить, какие блоки должны быть запрошены через store-gateway’и.
Чтобы обеспечить опрос всех необходимых блоков, querier’ы и ruler’ы определяют возраст бакет-индекса на основе времени его последнего обновления компактором.
Если его возраст превышает максимальный период устаревания, который настраивается с помощью параметра -blocks-storage.bucket-store.bucket-index.max-stale-period, запрос не выполняется.
Такой защитный механизм гарантирует, что querier’ы и ruler’ы не вернут неполные результаты запроса из-за неактуального представления долгосрочного хранилища.

Как это исправить:

Убедитесь, что компактор работает нормально (т.е. не сбоит, у него достаточно памяти).
Убедитесь, что каждая реплика компактора успешно обновила бакет-индекс каждого принадлежащего тенанта в течение двойного интервала -compactor.cleanup-interval (запрос ниже предполагает, что интервал очистки установлен на 15 минут): time() - cortex_compactor_block_cleanup_last_successful_run_timestamp_seconds > 2 * (15 * 60)

err-mimir-distributor-max-write-message-size

Эта ошибка возникает, когда distributer отклоняет запрос на запись, поскольку размер сообщения превышает допустимый лимит.

Как это работает:

distributer реализует верхнее ограничение на размер сообщения входящих запросов на запись.
Настроить лимит можно с помощью -distributor.max-recv-msg-size.

Как это исправить:

Увеличьте допустимый лимит, используя параметр -distributor.max-recv-msg-size.