Prometheus читает метрики из оффлайн узлов

Я настроил Prometheus для мониторинга различных приложений весенней загрузки. Эти приложения могут иметь несколько экземпляров, развернутых на пяти разных серверах. Некоторые приложения развернуты на каждом узле, другие - нет. Невозможно определить, находится ли applicationOne на nodeOne (это отвечает Portainer), поэтому я настроил список Prometheus в качестве целевого для всех возможных IP-адресов, на которых может быть развернуто приложение.

  - job_name: 'production-diagnostic'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    static_configs:
    - targets: ['1.1.1.1:9003', '1.1.1.2:9003', '1.1.1.3:9003', '1.1.1.4:9003', '1.1.1.5:9003']

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

Пример:

jvm_memory_used_bytes {application = "localization_vehicles_diagnostic", area = "heap", id = "G1 Eden Space", instance = "1.1.1.1:9003", job = "production-diagnostics"} 299892736 jvm_memory_used_bytes {application = "localization_vehicles_diagnostic", область = "куча", id = "G1 Eden Space", instance = "1.1.1.2:9003", job = "production-diagnostics"} 296747008 jvm_memory_used_bytes {application = "localization_vehicles_diagnostic", area = "heap", id = "G1 Eden Space ", instance =" 1.1.1.3:9003 ", job =" production-diagnostics "} 294649856 jvm_memory_used_bytes {application =" localization_vehicles_diagnostic ", area =" heap ", id =" G1 Eden Space ", instance =" 1.1. 1.4: 9003 ", job =" production-diagnostics "} 295698432

Что-то не так в моей конфигурации? Нужно ли мне добавить какой-нибудь другой параметр? Или, может быть, есть какие-то проблемы с Прометеем и Портайнером?


spring-boot-actuator prometheus portainer
person Stefania    schedule 24.07.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Так работает Прометей. Вы устанавливаете список целей в scrape_config. Prometheus будет пытаться получить метрики от этих целей на /actuator/prometheus конечной точке с заданным интервалом, независимо от того, существуют они или нет.

Вы можете использовать автоматически сгенерированную метрику с именем up, чтобы изолировать свои необходимые метрики от других. Вы можете легко определить, какие источники метрик отключены от up метрики.

up {job = "", instance = ""}: 1, если экземпляр исправен, т.е. доступен, или 0, если очистка не удалась.

person Kamol Hasan    schedule 24.07.2019
comment
Я не понимаю, что приложение никогда не меняло узел развертывания, поэтому я ожидал увидеть только одно полученное значение. Как вы думаете, какими могут быть эти другие ценности? Что касается вашей работы, можно ли ее использовать для передачи данных в Grafana? - person Stefania; 25.07.2019

arrow_upward
1
arrow_downward

Поиск целевых объектов для очистки - это все, что нужно для обнаружения службы: внеполосная информация используется для определения того, где запущены службы. В вашем случае вы настраиваете статическую конфигурацию, что означает, что все предоставленные цели запускают службы.

Если у вас нет доступной системы обнаружения сервисов, вы можете подделать ее, используя обнаружение сервисов на основе файлов.

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

  - job_name: 'production-diagnostic'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    static_configs:
    file_sd_configs:
    - files:
      - 'discovered.json'

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

[ {  "targets": [ "1.1.1.1:9003"  ]  }]

ПРИМЕЧАНИЕ: prometheus действительно является реактивным, и если ваши скрипты занимают слишком много времени на запись файла, у него будут временные ошибки, потому что он читает незавершенный файл. Я решил это, записав во временный файл, а затем скопировав его в цель f, которую я позволил.

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

person Michael Doubez    schedule 31.07.2019