Предположим, я использую том для хранения данных Prometheus, мне интересно, могу ли я иметь более одного его экземпляра для обеспечения высокой доступности.
Я считаю, что только один экземпляр Prometheus должен отвечать за запись в серию tsdb, а наличие более одного экземпляра может вызвать состояние гонки и повредить данные (и я думаю, что причина, по которой его tsdb имеет файл блокировки, должна быть в этом).
Итак, вопрос в том, могу ли я запустить несколько экземпляров Prometheus, и оба они будут указывать на одни и те же данные и использовать их в качестве варианта высокой доступности? Или есть другой способ сохранить доступность Prometheus во время непрерывного перезапуска, вызванного изменениями конфигурации?
Ответ на ваш вопрос о наличии нескольких экземпляров Prometheus, которые указывают на одни и те же данные и используют их, не является вариантом высокой доступности. Во время перезапуска модуля / узла данные недоступны для других экземпляров, что бесполезно. Если вы планируете создать несколько экземпляров Prometheus и сделать их HA. Советую использовать федерацию Прометея. Это также решение для простого масштабирования, когда один главный сервер собирает метрики с разных серверов в разных центрах обработки данных.
Настроить эту архитектуру довольно просто. Главный сервер развертывается с «целями», которые содержат список URL-адресов подчиненных серверов Prometheus, например:
scrape_configs:
- job_name: federated_prometheus
honor_labels: true
metrics_path: /federate
params:
match[]:
- '{job="the-prom-job"}'
static_configs:
- targets:
- prometheus-slave1:9090
- prometheus-slave2:9090
Параметр match [] в конфигурации указывает Prometheus накапливать и хранить все ведомые метрики для определенного задания. Вы также можете установить его как регулярное выражение: {__name__=~”^job:.*”}. Это соберет метрики из нескольких разных заданий, которые соответствуют определению выражения.
Подчиненные устройства Prometheus должны иметь следующую конфигурацию:
global:
external_labels:
slave: 1
relabel_configs:
- source_labels: [_prometheus_slave]
action: keep
regex: slave1
Когда размер данных постоянно увеличивается, драйверы хранилища должны быть способны справляться с ростом, чтобы предоставлять надежные исторические данные. Простым решением для этого является использование сервисов облачного эластичного хранилища, таких как AWS S3 или Google Storage, в качестве серверных частей хранилища. Эти службы обеспечивают неограниченную емкость для серверов Prometheus, которым необходимо поддерживать большие объемы данных, например серверов, подключенных к большому кластеру Kubernetes или нескольким кластерам с одной конечной точкой мониторинга.
Сам Prometheus предоставляет решение для расширенного управления хранилищем - масштабируемость хранилища с помощью моментальных снимков. Создавая моментальные снимки данных Prometheus и удаляя данные с помощью конфигурации хранения в хранилище, пользователи могут иметь данные старше X дней или месяцев или больше определенного размера, доступные в режиме реального времени. Затем они также могут хранить старые данные на отдельном диске и предоставлять их по запросу.
Взгляни, пожалуйста: Промет-федерация, Kubernetes-Scaling-Prometheus.