Комментарии 4
Запрос container_cpu_usage_seconds_total{pod='my-app-...'} за последний час должен возвращать только те поды, которые жили в этот час. Поды от вчерашнего деплоя в ответ попадать не должны
Разве вчерашний под, который уже не существует, шлёт какие-то метрики?
Нет, но он ещё хранится для истории.
Запрос композитный: сначала индекс отвечает "адресом" метрики, и только если запросить по нему данные метрики, мы поймём, что запись на самом деле прекратилась.
Поэтому появилась возможность не делать такие холостые запросы. Без неё срабатывал предохранитель, чтобы одним широким запросом нельзя было ухудшить общую производительность системы.
Спасибо за подробную статью. Правильно ли я понял, что RangeBitmap имеет смысл в первую очередь для широких запросов, а если после поиска по лейблам осталось всего несколько тысяч метрик, то обычный линейный проход может оказаться быстрее? Как вы в продакшене выбираете между этими двумя вариантами?
Всё верно. Roaring Btimap состоит из контейнеров, каждый из которых может содержать 65_536 значений. Количество контейнеров получаем через рефлексию. Каждый блок индекса соответствует одному из контейнеров контекста. В отличие от контекста блок состоит из ⌈log₂(max_IndexedValue)⌉ слайсов, т.е. даже если в контейнере установлен всего один бит, то работу придётся делать для всех слайсов. В этом случае амортизации не получается, это слишком дорого. В последней версии стоимостной модели мы вывели эвристику, что для нашего составного предиката 5 и более контейнеров в контексте достаточно для амортизации работы, и начиная с этого порога мы перестаём использовать обычный обход.
Индексируем диапазоны с помощью битовых масок, чтобы k8s не ломал индекс