Вокруг да около Prometheus: Подготовка и установка

Решил тоже написать о своем (пока не законченном) опыте настройки мониторинга 1С-ландшафта, с использованием Prometheus.

На это меня побудили некоторые статьи, где все описано в радужных цветах. Типа: "Все уже сделано! Бери, настраивай и радуйся!". Но на деле все сопровождается какими-то нюансами разной степени тяжести.

Всего планируется три статьи:

• Подготовка (эта статья)
• Мониторинг кластера 1С
• Инструментирование конфигураций

Цель статей - описать, с чем и почему мне пришлось дополнительно разбираться в своих около-Prometheus-работах.

Литература

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

• Mastering Prometheus

Автор William Hegedus. Издательство Packt Publishing.

С этой книги началось мое погружение в мир observability, docker и проч. Начал ее читать на песочке Пицунды, в 2024.

Книга оставила великолепные впечатления. Технические аспекты Prometheus расписаны подробно и нескучно. Но на около-литературном английском! Пол-книги пришлось со словарем читать.

• Kubernetes изнутри

Авторы Вьяс Дж., Лав К.  Издательство DMK Press.

Теоретические знания о Prometheus появились, пришло время переходить к его развертыванию. С windows и установками на хост решил не связываться, пришло время использовать контейнеры.

В предыдущей книге (по Prometheus) все примеры по развертыванию и конфигурированию описаны с использованием кластера Kubernetes. "Автор плохого не порекомендует" - подумал я. Значит тоже буду поднимать кубер (понимающие улыбнулись;). Прочитав четверть книги, понял, что пусть этим kubernetes занимаются специально обученные люди.

Сама книга, думаю, неплохая. Даже начал немного понимать проблематику статей о kubernetes. Побаловался с k8n и helm, узнал про Штурвал.

• Docker Compose для разработчика

Автор Гадзурас Э. Издательство ДМК Пресс.

От kubernetes я отказался, иду в сторону docker compose.

Книга "Docker Compose для разработчика" для меня оказалась слишком подробной и глубокой... Часть примеров/упражнений у меня не заработала. Тем не менее, основы Compose я получил и (неожиданно;) понял, что нужно бы и про сам Docker почитать.

• Continious Delivery with Docker and Jenkins

Автор Rafal Leszko. Издательство Packt Publishing. На английском.

Эта книга мне показалась более поверхностной что ли. Кроме самого Docker, описываются и другие темы (например, Compose и Swarm).

Знаний из этой книги мне хватило, чтобы начать читать и писать docker-файлы. Например, написал файл для образа Jenkins-клиента со встроенным OScript.

Эксперименты с Docker compose

Перед установкой Prometheus, решил потренироваться на другом ПО. И, в принципе, не прогадал, хоть это и отодвигало основную цель. Поскольку был выбран путь инсталляций с использованием Docker Compose, то и пробовал разворачивать запуская docker-compose.yml.

• GitLab-ce

Решено, что GitLab придет на замену текущей Gitea.
Откуда у меня взялся docker-compose-файл - уже и не помню. Может с официального сайта, может нашел готовый и допилил.

Изначально в docker-compose был только запуск самого GitLab (без Runner). В gitlab.rb были какие-то минимальные правки.

Затем вместо использования self-signed сертификата настроил корпоративный.

Затем (уже намного позже) решил, что нужен и GitLab Runner. В следующей статье напишу, зачем. docker-compose немного усложнился.

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

В официальной документации процесс переключения на внешний Prometheus описан достаточно подробно. Главное, не забыть открыть нужные порты экспортеров в docker-compose (секция ports описания сервиса), иначе GitLab не запустится.

Но это так и осталось экспериментом. Решил вернуться к использованию bundle.

services:
  gitlab:
    image: gitlab/gitlab-ce:18.7.1-ce.0
    #image: gitlab/gitlab-ce:18.5.5-ce.0
    #image: gitlab/gitlab-ce:18.2.6-ce.0
    #image: gitlab/gitlab-ce:18.0.3-ce.0
    container_name: gitlab
    restart: always
    hostname: 'GitLab'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # Add any other gitlab.rb configuration here, each on its own line
        external_url 'my-site'
        gitlab_rails['gitlab_shell_ssh_port'] = 2424
    ports:
      - '80:80'
      - '443:443'
      - '2424:22'
#      - "9101:9101" # node_exporter
#      - "9229:9229" # gitlab_workhorse
    volumes:
      - '/srv/gitlab/config:/etc/gitlab'
      - '/srv/gitlab/logs:/var/log/gitlab'
      - '/srv/gitlab/data:/var/opt/gitlab'
      - './certs/my-cert.crt:/var/opt/gitlab/nginx/conf/energos.crt'
      - './certs/my-cert.key:/var/opt/gitlab/nginx/conf/energos.key'
    shm_size: '256m'
    networks:
      - runner-network
      
  gitlab-runner:
    image: gitlab/gitlab-runner:v18.7.1
    container_name: gitlab-runner
    restart: always
    depends_on:
      - gitlab
    volumes:
      - './gitlab-runner/config:/etc/gitlab-runner'
      - '/var/run/docker.sock:/var/run/docker.sock'
    networks:
      - runner-network

networks:
  runner-network:
    driver: bridge

SonarQube, Jenkins

В принципе, ничего особо интересного. Для SQ прописан сервис Postgres, для хранения данных SQ.

Текущий Jenkins решено было оставить без изменений. Разве что, попробовал собрать образ Jenkins-клиента, со встроенным OScript и gitsync. Может когда-нибудь и пригодится.

FROM jenkins/ssh-agent:jdk21

COPY onescript-engine_1.9.3_all.deb /tmp/oscript.deb

RUN apt-get update && apt-get install -y \
    "/tmp/oscript.deb" \
    && rm -rf /var/lib/apt/lists/* \
    && rm -f /tmp/oscript.deb
    
RUN opm install gitsync \
  && gitsync plugins init \
  && gitsync plugins enable --all \
  && gitsync plugins disable edtExport

Установка Prometheus 

Установка Prometheus прошла достаточно буднично - все восторги по поводу контейнеризации уже поулеглись. Главное, нужно было найти хороший docker-compose файл. 

Нужные файлы найдены тут (потом дорабатывались по необходимости). Помимо самого Prometheus, также поднимаются Grafana и экспортеры. 

Hot reload

Конечно же, мне захотелось перезапускать Prometheus при изменениях его конфигурации (которая в prometheus.yml). Читал, что можно настроить такую возможность - чтобы запуском curl можно было применить какие-то новые изменения. А то ведь делал docker compose down/up.

Да, нужно было установить нужный флаг запуска (--web.enable-lifecycle):

services:
...
  prometheus:
    ...
    command:
      ....
      - '--web.enable-lifecycle'

Но еще нужно было указать basic-аутентификацию:

curl -X POST http://user:password@prom-server:9090/-/reload

До этого не сразу додумался. Причем, ни гугл-поиск, ни ИИ-бот мне не подсказали, почему не работала перезагрузка конфигурации.

Remote write

Как мы знаем, Prometheus - это ПО для мониторинга другого ПО. Отсюда следующие идеологические выводы:

1. Должна мониториться именно информационная система, без ухода в мелкие детали. Предполагается, что для мелких деталей должны быть предназначены logs and traces.
2. Мониторинг - это что-то достаточно краткосрочное, чтобы своевременно выявить какие-то непредусмотренные/нежелательные режимы работы. Предполагается, что хранить глубокую историю данных система мониторинга хранить не будет.

Собственно, таким путем Prometheus и идет: 

• Нежелательно работать с метриками высокой кардинальности;
• Нежелательно хранить данные (метрики) на большую глубину.

Но в реалиях мы можем захотеть высокую кардинальность. Или просто вынуждены иметь ее, т.к. нужный нам экспортер выдает только детальные метрики.

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

Для этого в Prometheus можно использовать remote write - транслировать метрики в какое-то другое хранилище. Чаще всего упоминается трансляция в VictoriaMetrics (иногда далее, VM).

Настроить remote write, в простейшем случае, очень просто.

1. Поднять хранилище (VM).
2. Настроить конфиг Prometheus для трансляции метрик во внешнее хранилище.

Поднять хранилище можно примерно так:

...........
services:

  prometheus:
    ..................
    networks:
      - monitor-net
    ....
    depends_on:
      - victoriametrics
    ..................
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.134.0
#    image: victoriametrics/victoria-metrics:v1.128.0
    container_name: victoriametrics-rw
    expose:
      - 8428
    volumes:
      - ./victoria-metrics-data:/victoria-metrics-data
    networks:
      - monitor-net
    ports:
      - 8428:8428
    command:
      - '-storageDataPath=victoria-metrics-data'
      - '-httpListenAddr=:8428'
      - '-retentionPeriod=26w'
    labels:
      org.label-schema.group: "monitoring"
    restart: unless-stopped

 Чтобы включить remote write, можно это прописать в default-настройки prometheus.yml:

global:
  scrape_interval:     15s
  evaluation_interval: 15s
  scrape_native_histograms: true # Для Prom 3.9 и выше

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'docker-host-alpha'

# Настройки remote write "по умолчанию"
remote_write:
  - url: http://victoriametrics:8428/api/v1/write
    # Передача Native histograms все равно не работает... Отключаю.
    send_native_histograms: false

Можно даже настроить Prometheus, чтобы он только как агент remote write работал (см. --enable-feature=agent). При этом отключается часть сервисов и задействуются оптимизации WAL.
Я не пробовал этот режим.

Также, remote write можно более точно настроить под крейсерскую нагрузку. Об этом читал в Mastering Prometheus. Когда наконец организую у себя устойчивую конфигурацию источников, то займусь этим.

Понятно, что дополнительное ПО и трансляция добавляют свой оверхед по расходованию ресурсов. В том же Mastering Prometheus говориться о повышении расходования ресурсов на 10-15%. Но у меня получилась немного другая картина.

Если смотреть на CPU, то получилось примерно так.

Возьмем начальные расходования CPU за x. Добавилось 0.4x в контейнере Prometheus (накладные расходы на remote write). И добавилось 0.9x на контейнер VictoriaMetrics.
Т.е., было x, стало 2.3x.

Но все это меркнет на фоне расходов GitLab:))

Native histograms

Вот, в Prometheus есть такой тип метрик. Это гистограмма с динамическими бакетами. Потенциально, это более точный вид метрик для агрегации показателей. Также, Native histograms можно снабжать экземплярами (exemplars) - это какое-то конкретное значение показателя с детальными метками. Выгружаются не в текстовом формате, а в Protobuf (т.е., метрики так просто не сгенерировать конкатенацией строк).

Вообще, экспортеров, которые выводят такой вид метрик, очень мало. Но один из интересных мне экспортеров таки выдает гистограммы этого вида.

До версии Prometheus 3.8, использование таких гистограмм было "экспериментальной" опцией и включалось специальным feature-флагом --enable-feature=native-histograms . Также, в prometheus.yml нужно указать, что используется чтение Native histograms - например, в разделе настроек по умолчанию указать scrape_native_histograms: true .  

Для меня стало определенной проблемой, что такие гистограммы не передаются по remote write в VictoriaMetrics... Для передачи native histograms по remote write, в конфигурации remote_write предусмотрена настройка: нужно указать send_native_histograms: true. Но у меня так трансляция не заработала. VM считывать такие гистограммы из экспортеров не умеет - у нее есть свой подобный вид гистограмм, но попроще.

В общем, только из-за Native histograms я остался на Prometheus - а так, можно было бы только на VM построить мониторинг.

Альтернативы Prometheus

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

Что можно рассмотреть.

1. VictoriaMetrics, без лишнего звена в виде Prometheus (упоминал выше).
   VM может сама делать scrape по тем же конфигурационным файлам, что использует Prometheus. Есть и свой AlertManager.
   Синтаксис MetricsQL на 100% совместим с PromQL (но где-то на 75% по сходимости результатов). Для дашбордов Grafana просто указываем VM, как источник данных типа Prometheus. 
2. Deckhouse Prom++. Это российский форк Prometheus, с оптимизациями (хабр). С оф.сайта: 
   "Open Source-система мониторинга: Prometheus, переписанный на С++
   Потребляет до 10 раз меньше памяти, чем обычный Prometheus
   До 3 раз эффективней, чем VictoriaMetrics".
   Кто знает, может придется на него уехать - зарегистрирован в реестре российского ПО.

Промежуточные итоги

На предоставленной мне виртуальной машине (Debian) в контейнерах работает следующее ПО:

• Gitlab-ce
• SonarQube
• Пара Postgree
• Prometheus
• Экспортеры
• VictoriaMetrics

Можно уже переходить к настройке экспортеров для наблюдения за нашими ИС. Об этом в следующей статье.