Долгосрочное хранение метрик всегда было одной из слабых сторон Prometheus. Изначально он был спроектирован для оперативного мониторинга, не подразумевающего хранение истории метрик на срок более двух недель. Сохранить в нём тренды месячных или годовых интервалов было отдельной задачей с привлечением внешних хранилищ и инструментов.
Весной Grafana анонсировала своё решение под названием Grafana Mimir, которое способно максимально просто, быстро и дёшево решить вопрос с долгосрочным хранением метрик в том числе с помощью S3 совместимого хранилища. В самом простом варианте может на файловую систему складывать данные. Одним из основных преимуществ указывается возможность быстро и просто настроить горизонтально масштабируемый high availability кластер хранения.
Настроить всё это дело реально очень просто.
1️⃣ Поднимаете в Docker сервер Mimir, указав в его конфиге бэкенд для хранения данных. В самом простом случае это может быть локальная директория.
2️⃣ Указываете в Prometheus в качестве remote_write сервер с Mimir.
3️⃣ В веб панели Grafana добавляете сервер Mimir в качестве Prometheus data source.
Авторы Mimir называют её самой производительной TSDB для долговременного хранения метрик Prometheus. Насколько это правда, трудно судить. Вот пример их нагрузочных тестов. Авторы конкурирующего хранилища из VictoriaMetrics собрали свои стенды с обоими продуктами и протестировали их производительность. В результате оказалось, что Mimir более требовательна к памяти, больше нагружает процессор и больше расходует места хранилища, но имеет ниже задержку в 50-м перцентиле и выше в 99-м. По результатам теста почти по всем параметрам Mimir хуже, причем с кратной разницей, что немного странно.
Ниже ссылка на get started, где в самом начале представлено наглядное видео по настройке связки Prometheus + Grafana + Mimir + MinIO.
Сайт - https://grafana.com/oss/mimir/
Исходники - https://github.com/grafana/mimir
Get started - https://grafana.com/docs/mimir/v2.3.x/operators-guide/get-started/
#prometheus #grafana #devops #мониторинг
Весной Grafana анонсировала своё решение под названием Grafana Mimir, которое способно максимально просто, быстро и дёшево решить вопрос с долгосрочным хранением метрик в том числе с помощью S3 совместимого хранилища. В самом простом варианте может на файловую систему складывать данные. Одним из основных преимуществ указывается возможность быстро и просто настроить горизонтально масштабируемый high availability кластер хранения.
Настроить всё это дело реально очень просто.
1️⃣ Поднимаете в Docker сервер Mimir, указав в его конфиге бэкенд для хранения данных. В самом простом случае это может быть локальная директория.
2️⃣ Указываете в Prometheus в качестве remote_write сервер с Mimir.
3️⃣ В веб панели Grafana добавляете сервер Mimir в качестве Prometheus data source.
Авторы Mimir называют её самой производительной TSDB для долговременного хранения метрик Prometheus. Насколько это правда, трудно судить. Вот пример их нагрузочных тестов. Авторы конкурирующего хранилища из VictoriaMetrics собрали свои стенды с обоими продуктами и протестировали их производительность. В результате оказалось, что Mimir более требовательна к памяти, больше нагружает процессор и больше расходует места хранилища, но имеет ниже задержку в 50-м перцентиле и выше в 99-м. По результатам теста почти по всем параметрам Mimir хуже, причем с кратной разницей, что немного странно.
Ниже ссылка на get started, где в самом начале представлено наглядное видео по настройке связки Prometheus + Grafana + Mimir + MinIO.
Сайт - https://grafana.com/oss/mimir/
Исходники - https://github.com/grafana/mimir
Get started - https://grafana.com/docs/mimir/v2.3.x/operators-guide/get-started/
#prometheus #grafana #devops #мониторинг
👍30👎1
Я вчера рассказал, как собрать Nginx с модулем статистики vts. Расскажу теперь, как его настроить и собрать метрики в систему мониторинга Prometheus.
Для настройки статистики вам достаточно добавить в основной файл конфигурации
И в любой виртуальных хост ещё один location. Я обычно в default добавляю:
Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.
Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
Идём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.
Теперь ставим Grafana, можно на этот же хост с Prometheus:
Идём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.
Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.
Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.
На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.
#nginx #мониторинг #prometheus #grafana
Для настройки статистики вам достаточно добавить в основной файл конфигурации
nginx.conf в секцию http:vhost_traffic_status_zone;И в любой виртуальных хост ещё один location. Я обычно в default добавляю:
server { listen 80; server_name localhost;.........................location /status { vhost_traffic_status_display; vhost_traffic_status_display_format html;}..................Теперь можно сходить по ip адресу сервера и посмотреть статистику прямо в браузере - http://10.20.1.56/status/. Сразу покажу ещё два важных и полезных урла: /status/format/json и /status/format/prometheus. По ним вы заберёте метрики в формате json или prometheus. Последняя ссылка нам будет нужна далее. Я покажу настройку мониторинга Nginx на примере Prometheus, так как это самый быстрый вариант. Имея все метрики в json формате, нетрудно и в Zabbix всё это закинуть через предобработку с помощью jsonpath, но времени побольше уйдёт.
Устанавливаем Prometheus. Нам нужен будет любой хост с Docker. Готовим конфиг, куда сразу добавим сервер с Nginx:
# mkdir prom_data && cd prom_data && touch prometheus.yamlglobal: scrape_interval: 5s evaluation_interval: 5srule_files:scrape_configs: - job_name: prometheus static_configs: - targets: ['localhost:9090'] - job_name: nginx_vts metrics_path: '/status/format/prometheus' static_configs: - targets: ['10.20.1.56:80']Это по сути стандартный конфиг, куда я добавил ещё один target nginx_vts. Запускаем Prometheus:
# docker run -p 9090:9090 -d --name=prom \-v ~/prom_data/prometheus.yaml:/etc/prometheus/prometheus.yml \ prom/prometheusИдём на ip адрес хоста и порт 9090, где запущен Prometheus. Убеждаемся, что он работает, а в разделе Status -> Targets наш Endpoint nginx_vts доступен. Можете взять метрики со страницы /status/format/prometheus и подёргать их в Prometheus. Разбирать работу с ним не буду, так как это отдельная история.
Теперь ставим Grafana, можно на этот же хост с Prometheus:
# docker run -p 3000:3000 -d --name=grafana grafana/grafanaИдём на ip адрес и порт 3000, видим интерфейс Графаны. Учётка по умолчанию admin / admin. Идём в раздел Administration -> Data sources и добавляем новый типа Prometheus. Из необходимых настроек достаточно указать только URL прома. В моём случае http://172.27.60.187:9090.
Теперь нам надо добавить готовый Dashboard для Nginx VTS. Их представлено штук 10 на сайте Grafana, но реально актуальный и работающий без доработки только один - https://grafana.com/grafana/dashboards/14824-nginx-vts-stats/. Соответственно, в разделе Dashboards Графаны нажимаем Import и указываем URL приведённого выше дашборда. Все основные метрики вы увидите на нём. Если надо добавить что-то ещё, то идёте на /status/format/prometheus, смотрите метрику и добавляете запрос с ней в Grafana.
Если с Prometheus не работали ранее, то подобное описание возможно не очень подробное, но в рамках заметки тему не раскрыть. Зато когда разберётесь и научитесь, настройка такого мониторинга будет занимать минут 10. Даже если в готовом дашборде что-то не будет работать, нетрудно подредактировать. Как Grafana, так и VTS модуль активно развиваются, поэтому старые дашборды в основном нерабочие. Но тут метрик не так много, так что не критично. Можно либо поправить, либо самому всё сделать.
На картинке всё не уместилось. Ниже ещё статистика по бэкендам будет. Примеры можно посмотреть в описании дашборда на сайте Grafana.
#nginx #мониторинг #prometheus #grafana
👍68👎1
Предлагаю вашему вниманию любопытный проект по мониторингу одиночного хоста с Docker - domolo. Сразу скажу, что это продукт уровня курсовой работы с каких-нибудь курсов по DevOps на тему мониторинга. Он представляет из себя преднастроенный набор контейнеров на современном стеке.
Domolo состоит из:
◽Prometheus вместе с Pushgateway, AlertManager и Promtail
◽Grafana с набором дашбордов
◽Loki для сбора логов с хоста и контейнеров
◽NodeExporter - для сбора метрик хоста
◽cAdvisor - для сбора метрик контейнеров
◽Caddy - реверс прокси для prometheus и alertmanager
Сначала подумал, что это какая-та ерунда. Не думал, что заработает без напильника. Но, на моё удивление, это не так. Всё заработало вообще сразу:
Идём в Grafana по адресу http://ip-хоста:3000, учётка admin / changeme. Здесь мы можем наблюдать уже настроенные дашборды на все случаи жизни. Там есть буквально всё, что надо и не надо. Loki и сбор логов тоже работает сразу же без напильника. Идём в Explore, выбираем Datasource Loki и смотрим логи.
Если вам нужно мониторить одиночный хост с контейнерами, то это прям полностью готовое решение. Запускаете и наслаждаетесь. Репозиторий domolo удобен и для того, чтобы научиться всё это дело настраивать. Все конфиги и docker-compose файлы присутствуют. На мой взгляд для обучения это удобнее, чем какая-нибудь статья или обучающее видео. Здесь всё в одном месте и гарантированно работает.
Можно разобраться, настроить под себя и, к примеру, добавить туда поддержку внешних хостов. Надо будет добавить новые внешние Datasources и какие-то метки внедрить, чтобы различать хосты и делать общие дашборды. Получится ещё одна курсовая работа.
Сам проект не развивается и не обновляется. Так что ждать от него чего-то сверх того, что там есть, не имеет смысла.
#мониторинг #grafana #docker #prometheus
Domolo состоит из:
◽Prometheus вместе с Pushgateway, AlertManager и Promtail
◽Grafana с набором дашбордов
◽Loki для сбора логов с хоста и контейнеров
◽NodeExporter - для сбора метрик хоста
◽cAdvisor - для сбора метрик контейнеров
◽Caddy - реверс прокси для prometheus и alertmanager
Сначала подумал, что это какая-та ерунда. Не думал, что заработает без напильника. Но, на моё удивление, это не так. Всё заработало вообще сразу:
# git clone https://github.com/ductnn/domolo.git# cd domolo# docker-compose up -dИдём в Grafana по адресу http://ip-хоста:3000, учётка admin / changeme. Здесь мы можем наблюдать уже настроенные дашборды на все случаи жизни. Там есть буквально всё, что надо и не надо. Loki и сбор логов тоже работает сразу же без напильника. Идём в Explore, выбираем Datasource Loki и смотрим логи.
Если вам нужно мониторить одиночный хост с контейнерами, то это прям полностью готовое решение. Запускаете и наслаждаетесь. Репозиторий domolo удобен и для того, чтобы научиться всё это дело настраивать. Все конфиги и docker-compose файлы присутствуют. На мой взгляд для обучения это удобнее, чем какая-нибудь статья или обучающее видео. Здесь всё в одном месте и гарантированно работает.
Можно разобраться, настроить под себя и, к примеру, добавить туда поддержку внешних хостов. Надо будет добавить новые внешние Datasources и какие-то метки внедрить, чтобы различать хосты и делать общие дашборды. Получится ещё одна курсовая работа.
Сам проект не развивается и не обновляется. Так что ждать от него чего-то сверх того, что там есть, не имеет смысла.
#мониторинг #grafana #docker #prometheus
👍77👎7
Наиболее популярным и простым в настройке мониторингом сейчас является Prometheus. Простым не в плане возможностей, а в плане начальной настройки. Так как для него очень много всего автоматизировано, начать сбор метрик можно в несколько простых действий. Мониторинг сразу заработает и дальше с ним можно разбираться и настраивать.
Напишу краткую шпаргалку по запуску связки Prometheus + Grafana, чтобы её можно было сохранить и использовать по мере надобности. Я установлю их в Docker, сразу буду мониторить сам Prometheus и локальных хост Linux. Подключу для примера ещё один внешний Linux сервер.
Ставим Docker:
Готовим файл
Содержимое файла:
И рядом кладём конфиг
Запускаем весь стек:
Если будут ошибки, прогоните весь yaml через какой-нибудь валидатор. При копировании он часто ломается.
Ждём, когда всё поднимется, и идём по IP адресу сервера на порт 3000. Логинимся в Grafana под учёткой admin / admin. Заходим в Connections ⇨ Data sources и добавляем источник prometheus. В качестве параметра Prometheus server URL указываем http://prometheus:9090. Сохраняем.
Идём в Dashboards, нажимаем New ⇨ Import. Вводим ID дашборда для Node Exporter - 1860. Сохраняем и идём смотреть дашборд. Увидите все доступные графики и метрики хоста Linux, на котором всё запущено.
Идём на удалённый Linux хост и запускаем там любым подходящим способом node-exporter. Например, через Docker напрямую:
Проверяем, что сервис запущен на порту 9100:
Возвращаемся на сервер с prometheus и добавляем в его конфиг еще одну job с этим сервером:
Перезапускаем стек:
Идём в Dashboard в Grafana и выбираем сверху в выпадающем списке job от этого нового сервера - node-remote.
На всю настройку уйдёт минут 10. Потом ещё 10 на настройку базовых уведомлений. У меня уже места не хватило их добавить сюда. Наглядно видна простота и скорость настройки, о которых я сказал в начале.
❗️В проде не забывайте ограничивать доступ ко всем открытым портам хостов с помощью файрвола.
#мониторинг #prometheus #devops
Напишу краткую шпаргалку по запуску связки Prometheus + Grafana, чтобы её можно было сохранить и использовать по мере надобности. Я установлю их в Docker, сразу буду мониторить сам Prometheus и локальных хост Linux. Подключу для примера ещё один внешний Linux сервер.
Ставим Docker:
# curl https://get.docker.com | bash -Готовим файл
docker-compose.yml:# mkdir ~/prometheus && cd ~/prometheus# touch docker-compose.ymlСодержимое файла:
version: '3.9'networks: monitoring: driver: bridgevolumes: prometheus_data: {}services: prometheus: image: prom/prometheus:latest volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prometheus_data:/prometheus container_name: prometheus hostname: prometheus command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' expose: - 9090 restart: unless-stopped environment: TZ: "Europe/Moscow" networks: - monitoring node-exporter: image: prom/node-exporter volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro container_name: exporter hostname: exporter command: - '--path.procfs=/host/proc' - '--path.rootfs=/rootfs' - '--path.sysfs=/host/sys' - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)' expose: - 9100 restart: unless-stopped environment: TZ: "Europe/Moscow" networks: - monitoring grafana: image: grafana/grafana user: root depends_on: - prometheus ports: - 3000:3000 volumes: - ./grafana:/var/lib/grafana - ./grafana/provisioning/:/etc/grafana/provisioning/ container_name: grafana hostname: grafana restart: unless-stopped environment: TZ: "Europe/Moscow" networks: - monitoringИ рядом кладём конфиг
prometheus.yml:scrape_configs: - job_name: 'prometheus' scrape_interval: 5s scrape_timeout: 5s static_configs: - targets: ['localhost:9090'] - job_name: 'node-local' scrape_interval: 5s static_configs: - targets: ['node-exporter:9100']Запускаем весь стек:
# docker-compose up -dЕсли будут ошибки, прогоните весь yaml через какой-нибудь валидатор. При копировании он часто ломается.
Ждём, когда всё поднимется, и идём по IP адресу сервера на порт 3000. Логинимся в Grafana под учёткой admin / admin. Заходим в Connections ⇨ Data sources и добавляем источник prometheus. В качестве параметра Prometheus server URL указываем http://prometheus:9090. Сохраняем.
Идём в Dashboards, нажимаем New ⇨ Import. Вводим ID дашборда для Node Exporter - 1860. Сохраняем и идём смотреть дашборд. Увидите все доступные графики и метрики хоста Linux, на котором всё запущено.
Идём на удалённый Linux хост и запускаем там любым подходящим способом node-exporter. Например, через Docker напрямую:
# docker run -d --net="host" --pid="host" -v "/:/host:ro,rslave" prom/node-exporter:latest --path.rootfs=/hostПроверяем, что сервис запущен на порту 9100:
# ss -tulnp | grep 9100Возвращаемся на сервер с prometheus и добавляем в его конфиг еще одну job с этим сервером:
- job_name: 'node-remote' scrape_interval: 5s static_configs: - targets: ['10.20.1.56:9100']Перезапускаем стек:
# docker compose restartИдём в Dashboard в Grafana и выбираем сверху в выпадающем списке job от этого нового сервера - node-remote.
На всю настройку уйдёт минут 10. Потом ещё 10 на настройку базовых уведомлений. У меня уже места не хватило их добавить сюда. Наглядно видна простота и скорость настройки, о которых я сказал в начале.
❗️В проде не забывайте ограничивать доступ ко всем открытым портам хостов с помощью файрвола.
#мониторинг #prometheus #devops
👍115👎3
Вчера была заметка про быструю установку связки Prometheus + Grafana. Из-за лимита Telegram на длину сообщений разом всё описать не представляется возможным. А для полноты картины не хватает настройки уведомлений, так как мониторинг без них это не мониторинг, а красивые картинки.
Для примера я настрою два типа уведомлений:
◽SMTP для только для метки critical
◽Telegram для меток critical и warning
Уведомления будут отправляться на основе двух событий:
▪️ С хоста нету метрик, то есть он недоступен мониторингу, метка critical
▪️ На хосте процессор занят в течении минуты более чем на 70%, метка warning
Я взял именно эти ситуации, так как на их основе будет понятен сам принцип настройки и формирования конфигов, чтобы каждый потом смог доработать под свои потребности.
Постить сюда все конфигурации в формате yaml неудобно, поэтому решил их собрать в архив и прикрепить в следующем сообщении. Там будут 4 файла:
-
-
-
-
Для запуска всего стека с уведомлениями достаточно положить эти 4 файла в отдельную директорию и там запустить compose:
На момент отладки рекомендую запускать прямо в консоли, чтобы отлавливать ошибки. Если где-то ошибётесь в конфигурациях правил или alertmanager, сразу увидите ошибки и конкретные строки конфигурации, с которыми что-то не так. В таком случае останавливайте стэк:
Исправляйте конфиги и заново запускайте. Зайдя по IP адресу сервера на порт 9090, вы попадёте в веб интерфейс Prometheus. Там будет отдельный раздел Alerts, где можно следить за работой уведомлений.
В данном примере со всем стэком наглядно показан принцип построения современного мониторинга с подходом инфраструктура как код (IaC). Имея несколько файлов конфигурации, мы поднимаем необходимую систему во всей полноте. Её легко переносить, изменять конфигурацию и отслеживать эти изменения через git.
#мониторинг #prometheus #devops
Для примера я настрою два типа уведомлений:
◽SMTP для только для метки critical
◽Telegram для меток critical и warning
Уведомления будут отправляться на основе двух событий:
▪️ С хоста нету метрик, то есть он недоступен мониторингу, метка critical
▪️ На хосте процессор занят в течении минуты более чем на 70%, метка warning
Я взял именно эти ситуации, так как на их основе будет понятен сам принцип настройки и формирования конфигов, чтобы каждый потом смог доработать под свои потребности.
Постить сюда все конфигурации в формате yaml неудобно, поэтому решил их собрать в архив и прикрепить в следующем сообщении. Там будут 4 файла:
-
docker-compose.yml - основной файл с конфигурацией всех сервисов. Его описание можно посмотреть в предыдущем посте. Там добавился новый контейнер с alertmanager и файл с правилами для prometheus - alert.rules-
prometheus.yml - настройки Прометеуса.-
alert.rules - файл с двумя правилами уведомлений о недоступности хоста и превышении нагрузки CPU.-
alertmanager.yml - настройки alertmanager с двумя источниками для уведомлений: email и telegram. Не забудьте там поменять токен бота, id своего аккаунта, куда бот будет отправлять уведомления и настройки smtp.Для запуска всего стека с уведомлениями достаточно положить эти 4 файла в отдельную директорию и там запустить compose:
# docker compose upНа момент отладки рекомендую запускать прямо в консоли, чтобы отлавливать ошибки. Если где-то ошибётесь в конфигурациях правил или alertmanager, сразу увидите ошибки и конкретные строки конфигурации, с которыми что-то не так. В таком случае останавливайте стэк:
# docker compose stopИсправляйте конфиги и заново запускайте. Зайдя по IP адресу сервера на порт 9090, вы попадёте в веб интерфейс Prometheus. Там будет отдельный раздел Alerts, где можно следить за работой уведомлений.
В данном примере со всем стэком наглядно показан принцип построения современного мониторинга с подходом инфраструктура как код (IaC). Имея несколько файлов конфигурации, мы поднимаем необходимую систему во всей полноте. Её легко переносить, изменять конфигурацию и отслеживать эти изменения через git.
#мониторинг #prometheus #devops
👍79👎1
Я недавно написал 2 публикации на тему настройки мониторинга на базе Prometheus (1, 2). Они получились чуток недоделанными, потому что некоторые вещи всё же приходилось делать руками - добавлять Datasource и шаблоны. Решил это исправить, чтобы в полной мере раскрыть принцип IaC (инфраструктура как код). Плюс, для полноты картины, добавил туда в связку ещё и blackbox-exporter для мониторинга за сайтами. В итоге в пару кликов можно развернуть полноценный мониторинг с примерами стандартных конфигураций, дашбордов, оповещений.
Для того, чтобы более ясно представлять о чём тут пойдёт речь, лучше прочитать две первых публикации, на которые я дал ссылки. Я подготовил docker-compose и набор других необходимых файлов, чтобы автоматически развернуть базовый мониторинг на базе Prometheus, Node-exporter, Blackbox-exporter, Alert Manager и Grafana.
По просьбам трудящихся залил всё в Git репозиторий. Клонируем к себе и разбираемся:
Что есть что:
▪️
▪️
▪️
▪️
▪️
▪️
▪️
Скопировали репозиторий, пробежались по настройкам, что-то изменили под свои потребности. Запускаем:
Идём на порт сервера 3000 и заходим в Grafana. Учётка стандартная - admin / admin. Видим там уже 3 настроенных дашборда. На порту 9090 живёт сам Prometheus, тоже можно зайти, посмотреть.
Вот ссылки на шаблоны, которые я добавил. Можете посмотреть картинки, как это будет выглядеть. У Blackbox информативные дашборды. Уже только для них можно использовать эту связку, так как всё уже сделано за вас. Вам нужно будет только список сайтов заполнить в prometheus.yml.
⇨ Blackbox Exporter (HTTP prober)
⇨ Prometheus Blackbox Exporter
⇨ Node Exporter Full
Для того, чтобы автоматически доставлять все изменения в настройках на сервер мониторинга, можно воспользоваться моей инструкцией на примере gatus и gitlab-ci. Точно таким же подходом вы можете накатывать и изменения в этот мониторинг.
Мне изначально казалось, что подобных примеров уже много. Но когда стало нужно, не нашёл чего-то готового, чтобы меня устроило. В итоге сам набросал вот такой проект. Сделал в том числе и для себя, чтобы всё в одном месте было для быстрого развёртывания. Каждая отдельная настройка, будь то prometheus, alertmanager, blackbox хорошо гуглятся. Либо можно сразу в документацию идти, там всё подробно описано. Не стал сюда ссылки добавлять, чтобы не перегружать.
❗️Будьте аккуратны при работе с Prometheus и ему подобными, где всё состояние инфраструктуры описывается только кодом. После него будет трудно возвращаться к настройке и управлению Zabbix. Давно это ощущаю на себе. Хоть у них и сильно разные возможности, но IaC подкупает.
#prometheus #devops #мониторинг
Для того, чтобы более ясно представлять о чём тут пойдёт речь, лучше прочитать две первых публикации, на которые я дал ссылки. Я подготовил docker-compose и набор других необходимых файлов, чтобы автоматически развернуть базовый мониторинг на базе Prometheus, Node-exporter, Blackbox-exporter, Alert Manager и Grafana.
По просьбам трудящихся залил всё в Git репозиторий. Клонируем к себе и разбираемся:
# git clone https://gitflic.ru/project/serveradmin/prometheus.git# cd prometheusЧто есть что:
▪️
docker-compose.yml - основной compose файл, где описаны все контейнеры.▪️
prometheus.yml - настройки prometheus, где для примера показаны задачи мониторинга локального хоста, удалённого хоста с node-exporter, сайтов через blackbox.▪️
blackbox.yml - настройки для blackbox, для примера взял только проверку кодов ответа веб сервера. ▪️
alertmanager.yml - настройки оповещений, для примера настроил smtp и telegram▪️
alert.rules - правила оповещений для alertmanager, для примера настроил 3 правила - недоступность хоста, перегрузка по CPU, недоступность сайта.▪️
grafana\provisioning\datasources\prometheus.yml - автоматическая настройка datasource в виде локального prometheus, чтобы не ходить, руками не добавлять.▪️
grafana\provisioning\dashboards - автоматическое добавление трёх дашбордов: один для node-exporter, два других для blackbox.Скопировали репозиторий, пробежались по настройкам, что-то изменили под свои потребности. Запускаем:
# docker compose up -dИдём на порт сервера 3000 и заходим в Grafana. Учётка стандартная - admin / admin. Видим там уже 3 настроенных дашборда. На порту 9090 живёт сам Prometheus, тоже можно зайти, посмотреть.
Вот ссылки на шаблоны, которые я добавил. Можете посмотреть картинки, как это будет выглядеть. У Blackbox информативные дашборды. Уже только для них можно использовать эту связку, так как всё уже сделано за вас. Вам нужно будет только список сайтов заполнить в prometheus.yml.
⇨ Blackbox Exporter (HTTP prober)
⇨ Prometheus Blackbox Exporter
⇨ Node Exporter Full
Для того, чтобы автоматически доставлять все изменения в настройках на сервер мониторинга, можно воспользоваться моей инструкцией на примере gatus и gitlab-ci. Точно таким же подходом вы можете накатывать и изменения в этот мониторинг.
Мне изначально казалось, что подобных примеров уже много. Но когда стало нужно, не нашёл чего-то готового, чтобы меня устроило. В итоге сам набросал вот такой проект. Сделал в том числе и для себя, чтобы всё в одном месте было для быстрого развёртывания. Каждая отдельная настройка, будь то prometheus, alertmanager, blackbox хорошо гуглятся. Либо можно сразу в документацию идти, там всё подробно описано. Не стал сюда ссылки добавлять, чтобы не перегружать.
❗️Будьте аккуратны при работе с Prometheus и ему подобными, где всё состояние инфраструктуры описывается только кодом. После него будет трудно возвращаться к настройке и управлению Zabbix. Давно это ощущаю на себе. Хоть у них и сильно разные возможности, но IaC подкупает.
#prometheus #devops #мониторинг
👍105👎1
Небольшая справочная заметка для тех, кто пользуется Prometheus. Речь пойдёт про простенький и быстрый в настройке обратный прокси для метрик - exporter-exporter. Я вообще не знал про его существование, хотя пользоваться им удобно, настраивается быстро. Плюс, живёт в базовых системных репозиториях. По крайней мере в Debian и Ubuntu он есть, искать по имени prometheus-exporter-exporter. Есть даже версия под Windows, можно запустить как службу.
По своей сути exporter-exporter обычный бинарник на Go. Заменяет настройку любого другого обратного прокси на базе полноценного веб-сервера, типа Nginx или Traefik. Пригодится, когда у тебя несколько экспортеров и ты хочешь использовать для них единую точку входа, скрывая реальные адреса экспортеров.
У exporter-exporter небольшой конфиг в формате yaml. Экспортер поддерживает 3 эндпоинта:
◽️/ - отображает список всех экспортеров, которые на нём настроены;
◽️/proxy - через этот эндпоинт можно обратиться к конкретному экспортеру, настроенному через отдельный module в конфиге;
◽️/metrics - показывает метрики самого exporter-exporter.
Настройка примерно такая для двух разных экспортеров, локального и внешнего:
А вот так их добавляем в Prometheus вместе с метриками самого exporter-exporter, запущенного на сервере 192.168.101.2:
В примере репозитория exporter-exporter не сразу понял, как добавить внешний экспортер. Там были примеры только для localhost. Спросил об этом DeepSeek, перед этим уточнив, знаком ли он с этим продуктом. Ответил, что знаком и выдал совершенно нерабочий конфиг для службы, просто придумав различные несуществующие параметры. Такой вот он помощник. Пришлось самому разбираться.
Для тех, кто не видел, у меня была серия публикаций по запуску полноценного мониторинга на связке prometheus+grafana+alertmanager:
⇨ Запуск Prometheus + Grafana
⇨ Добавление туда Alertmanager
⇨ Полная автоматизация запуска и эксплуатации по принципу IaC
Данная заметка их хорошо дополняет. Удобно использовать именно exporter-exporter в связке с Prometheus, а не какой-то другой обратный прокси. Тут всё в едином формате, легко автоматизировать настройку и запуск.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#prometheus
По своей сути exporter-exporter обычный бинарник на Go. Заменяет настройку любого другого обратного прокси на базе полноценного веб-сервера, типа Nginx или Traefik. Пригодится, когда у тебя несколько экспортеров и ты хочешь использовать для них единую точку входа, скрывая реальные адреса экспортеров.
У exporter-exporter небольшой конфиг в формате yaml. Экспортер поддерживает 3 эндпоинта:
◽️/ - отображает список всех экспортеров, которые на нём настроены;
◽️/proxy - через этот эндпоинт можно обратиться к конкретному экспортеру, настроенному через отдельный module в конфиге;
◽️/metrics - показывает метрики самого exporter-exporter.
Настройка примерно такая для двух разных экспортеров, локального и внешнего:
modules:
node_exporter_loc:
method: http
http:
port: 9100
path: '/metrics'
node_exporter_ext:
method: http
http:
address: 172.20.4.15
port: 9100
path: '/metrics'
А вот так их добавляем в Prometheus вместе с метриками самого exporter-exporter, запущенного на сервере 192.168.101.2:
- job_name: 'exp_exp_metrics'
scrape_interval: 5s
static_configs:
- targets: ['192.168.101.2:9999']
- job_name: 'exp_exp-local'
scrape_interval: 5s
metrics_path: /proxy
params:
module:
- node_exporter_loc
static_configs:
- targets: ['192.168.101.2:9999']
- job_name: 'exp_exp-external'
scrape_interval: 5s
metrics_path: /proxy
params:
module:
- node_exporter_ext
static_configs:
- targets: ['192.168.101.2:9999']
В примере репозитория exporter-exporter не сразу понял, как добавить внешний экспортер. Там были примеры только для localhost. Спросил об этом DeepSeek, перед этим уточнив, знаком ли он с этим продуктом. Ответил, что знаком и выдал совершенно нерабочий конфиг для службы, просто придумав различные несуществующие параметры. Такой вот он помощник. Пришлось самому разбираться.
Для тех, кто не видел, у меня была серия публикаций по запуску полноценного мониторинга на связке prometheus+grafana+alertmanager:
⇨ Запуск Prometheus + Grafana
⇨ Добавление туда Alertmanager
⇨ Полная автоматизация запуска и эксплуатации по принципу IaC
Данная заметка их хорошо дополняет. Удобно использовать именно exporter-exporter в связке с Prometheus, а не какой-то другой обратный прокси. Тут всё в едином формате, легко автоматизировать настройку и запуск.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#prometheus
GitHub
GitHub - QubitProducts/exporter_exporter: A reverse proxy designed for Prometheus exporters
A reverse proxy designed for Prometheus exporters. Contribute to QubitProducts/exporter_exporter development by creating an account on GitHub.
1👍89👎3
Вчера был на конференции Deckhouseconf компании Флант. Пишу от себя, меня специально туда никто не звал. Сам просто увидел где-то анонс мероприятия и отправил заявку. Меня иногда спрашивают, как я попадаю на разные конференции. На некоторые приглашают, но чаще всего - нет. Сам отправляю заявку да и всё. Пишу, что я DevOps инженер. Ни разу отказ не получал. Может как-то идентифицируют меня, может так совпадает. Приезжаю как обычный участник и не отсвечиваю. Я и пишу о поездках редко, только если что-то полезное увижу.
Расскажу о том, что мне показалось интересным и полезным. Эта конференция в основном посвящена продукту Deckhouse. Это большая коммерческая платформа, которая объединяет в себе управление контейнерами и виртуальными машинами на базе Kubernetes. И приправлено всё это различными вспомогательными сервисами, некоторые из которых полностью или частично переписаны самостоятельно - мониторинг, управление секретами, управление кодом, хранилище контейнеров и т.д.
Я впервые узнал про эту платформу на прошлой конференции. Выглядит всё круто и интересно, но в основном для большого и очень большого бизнеса. Я даже примерно не знаю, сколько всё это стоит, не интересовался. В прошлом году было упомянуто, что есть бесплатная community версия. Я мельком глянул на неё - там всё управление только через CLI, вообще никакого интерфейса нет. Практического применения в таком виде не увидел, даже пробовать не стал.
А в этом году рассказали и показали простой и удобный установщик и панель управления платформой, которая частично поддерживает community версию в режиме только просмотра, не управления. Установщик позволяет развернуть бесплатную версию на железо, виртуалки или в Yandex Cloud. Можно поставить как на одну ноду, так и на 2-3. То есть это нормальное решение для небольшого отказоустойчивого кластера.
На выходе вы получаете платформу высокой доступности для запуска контейнеров и виртуальных машин, которая управляется манифестами кубернетиса с поддержкой иностранный и отечественных ОС как основы кластера, так и машин, которые в нём могут быть запущены (винду тоже можно). Соответственно, все возможности Kubernetes реализованы и для виртуальных машин. Они запускаются в подах, автоматически переезжают, к ним прокидывается доступ через ингресс контроллер, нарезаются диски и т.д.
Полное сравнение редакций и обзор функциональных возможностей каждой из них можно посмотреть в табличке. Конечно, в бесплатной версии много всего урезано. Хотелось хотя бы на 3 ноды полнофункциональный кластерок 🙄 Может быть с ограничением по виртуалкам, чтобы вкусить все прелести на небольшой масштабе, но увы. Придётся довольствоваться тем, что есть. В принципе, и так немало. Можно попробовать. Думаю, разверну у себя и напишу, что получилось. Интересно самому посмотреть.
Также напомню тем, кто не знает, что команда Deckhouse полностью переписала Prometheus на C++ 😎, назвав его Prom++. Он тратит на работу в разы меньше ресурсов, чем оригинальный Prom, и меньше, чем VictoriaMetrics, которая тоже отличается легковесностью. Prom++ полностью совместим с оригинальным Prometheus и внедряется простой заменой оригинала. Вообще ничего больше делать не надо. Если вы используете Prometheus или VictoriaMetrics, можете без каких-либо усилий снизить потребляемые мониторингом ресурсы. Не вижу никаких причин не делать это прямо сейчас.
Остальные выступления послушал, но поделиться в формате заметки больше нечем. Там в основном про внутреннее устройство Deckhouse было. Из приятного - выиграл на стенде Selectel очередного Тирекса - мягкую игрушку. У меня дети любят их. Дома несколько штук есть, некоторые совсем поистрепались.
#devops #kuber #prometheus
Расскажу о том, что мне показалось интересным и полезным. Эта конференция в основном посвящена продукту Deckhouse. Это большая коммерческая платформа, которая объединяет в себе управление контейнерами и виртуальными машинами на базе Kubernetes. И приправлено всё это различными вспомогательными сервисами, некоторые из которых полностью или частично переписаны самостоятельно - мониторинг, управление секретами, управление кодом, хранилище контейнеров и т.д.
Я впервые узнал про эту платформу на прошлой конференции. Выглядит всё круто и интересно, но в основном для большого и очень большого бизнеса. Я даже примерно не знаю, сколько всё это стоит, не интересовался. В прошлом году было упомянуто, что есть бесплатная community версия. Я мельком глянул на неё - там всё управление только через CLI, вообще никакого интерфейса нет. Практического применения в таком виде не увидел, даже пробовать не стал.
А в этом году рассказали и показали простой и удобный установщик и панель управления платформой, которая частично поддерживает community версию в режиме только просмотра, не управления. Установщик позволяет развернуть бесплатную версию на железо, виртуалки или в Yandex Cloud. Можно поставить как на одну ноду, так и на 2-3. То есть это нормальное решение для небольшого отказоустойчивого кластера.
На выходе вы получаете платформу высокой доступности для запуска контейнеров и виртуальных машин, которая управляется манифестами кубернетиса с поддержкой иностранный и отечественных ОС как основы кластера, так и машин, которые в нём могут быть запущены (винду тоже можно). Соответственно, все возможности Kubernetes реализованы и для виртуальных машин. Они запускаются в подах, автоматически переезжают, к ним прокидывается доступ через ингресс контроллер, нарезаются диски и т.д.
Полное сравнение редакций и обзор функциональных возможностей каждой из них можно посмотреть в табличке. Конечно, в бесплатной версии много всего урезано. Хотелось хотя бы на 3 ноды полнофункциональный кластерок 🙄 Может быть с ограничением по виртуалкам, чтобы вкусить все прелести на небольшой масштабе, но увы. Придётся довольствоваться тем, что есть. В принципе, и так немало. Можно попробовать. Думаю, разверну у себя и напишу, что получилось. Интересно самому посмотреть.
Также напомню тем, кто не знает, что команда Deckhouse полностью переписала Prometheus на C++ 😎, назвав его Prom++. Он тратит на работу в разы меньше ресурсов, чем оригинальный Prom, и меньше, чем VictoriaMetrics, которая тоже отличается легковесностью. Prom++ полностью совместим с оригинальным Prometheus и внедряется простой заменой оригинала. Вообще ничего больше делать не надо. Если вы используете Prometheus или VictoriaMetrics, можете без каких-либо усилий снизить потребляемые мониторингом ресурсы. Не вижу никаких причин не делать это прямо сейчас.
Остальные выступления послушал, но поделиться в формате заметки больше нечем. Там в основном про внутреннее устройство Deckhouse было. Из приятного - выиграл на стенде Selectel очередного Тирекса - мягкую игрушку. У меня дети любят их. Дома несколько штук есть, некоторые совсем поистрепались.
#devops #kuber #prometheus
1👍89👎4
К одной из заметок про Loki в комментариях поделились ссылкой на любопытный проект - MKTXP-Stack. Это готовое решение для мониторинга и сбора логов с устройств Mikrotik. Состоит из:
◽️Prometheus для хранения метрик
◽️Grafana для визуализации
◽️MKTXP - exporter для сбора метрик с Микротиков по API
◽️Loki для хранения логов
◽️Promtail и Syslog-NG для сбора логов
Всё это упаковано в docker compose и запускается за 5 минут. Всё, что нужно - заполнить конфигурационный файл с доступом к микротикам. Весь стек полностью настроен. Я его запустил и попробовал. Экспортер и визуализация к нему очень понравились. Сбор логов не особо, потому что, во-первых, используется Promtail, а он не очень хорошо парсит syslog от микротов. Какие там есть проблемы, писал в отдельной заметке про Alloy. У него такие же проблемы, как у Promtail. Для этой задачи лучше подходит Vector. Во-вторых, у меня в контейнере с Promtail периодически вылезали ошибки, и он переставал собирать логи. Помогал перезапуск. С ошибками разбираться не стал, Promtail всё равно уже deprecated, его надо менять.
А вот сам экспортер и дашборд к нему очень хороши. Если у вас уже есть свой стэк Prometheus + Grafana, можете взять отдельно экспортер и дашборд. В репозитории есть инструкция, там всё просто для тех, кто работает с Prometheus и знает его. Для тех, кто не знает, покажу, как всё это дело запустить и наслаждаться мониторингом микротиков без погружения в тему prometheus и grafana.
Берём любую машину с установленным Docker. Клонируем себе репозиторий и переходим в него:
Открываем файл конфигурации mktxp.conf в директории mktxp и добавляем свои устройства в файл:
И так далее. На всех устройствах добавляем отдельного пользователя для доступа mktxp. Ему достаточно прав read и api. Можете сделать через winbox или в консоли:
Используем эту учётку в mktxp.conf
Остальные параметры включайте на своё усмотрение. Там по названию понятен смысл, плюс, есть комментарии. Если на устройствах будут разные учётки, то пропишите их в разделе с устройством.
Больше ничего делать не надо. Можно запускать весь стек. Для этого переходим в директорию mktxp-stack и запускаем:
Переходим в веб интерфейс по IP адресу сервера на порт 3000, например http://192.168.137.29:3000. Попадёте сразу в веб интерфейс Grafana. Там уже всё настроено, аутентификация отключена. Вы сразу же увидите метрики со своих настроенных устройств. По крайней мере у меня сразу всё заработало. Ничего больше не делал.
Дашборд продуман и информативен. Я себе оставлю его. Не скажу, что сильно надо. Самому лень было настраивать. Но готовый можно взять. Там те же лизы от DHCP можно смотреть. Я иногда захожу через winbox поискать потерявшиеся хосты. Ну и просто статистику, загрузку интерфейсов, открытые соединения и топ хостов по ним посмотреть. На дашборде всё это нагляднее, чем в Winbox.
Как я уже сказал, аутентификация в Grafana отключена, по умолчанию почему-то установлена светлая тема. Мне привычнее тёмная. Поменять настройки grafana можно в основном compose файле - docker-compose-mktxp-stack.yml. Я вернул чёрный цвет:
Хорошее, добротное решение. Мне понравилось. Ниже много интересных картинок.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#mikrotik #prometheus
◽️Prometheus для хранения метрик
◽️Grafana для визуализации
◽️MKTXP - exporter для сбора метрик с Микротиков по API
◽️Loki для хранения логов
◽️Promtail и Syslog-NG для сбора логов
Всё это упаковано в docker compose и запускается за 5 минут. Всё, что нужно - заполнить конфигурационный файл с доступом к микротикам. Весь стек полностью настроен. Я его запустил и попробовал. Экспортер и визуализация к нему очень понравились. Сбор логов не особо, потому что, во-первых, используется Promtail, а он не очень хорошо парсит syslog от микротов. Какие там есть проблемы, писал в отдельной заметке про Alloy. У него такие же проблемы, как у Promtail. Для этой задачи лучше подходит Vector. Во-вторых, у меня в контейнере с Promtail периодически вылезали ошибки, и он переставал собирать логи. Помогал перезапуск. С ошибками разбираться не стал, Promtail всё равно уже deprecated, его надо менять.
А вот сам экспортер и дашборд к нему очень хороши. Если у вас уже есть свой стэк Prometheus + Grafana, можете взять отдельно экспортер и дашборд. В репозитории есть инструкция, там всё просто для тех, кто работает с Prometheus и знает его. Для тех, кто не знает, покажу, как всё это дело запустить и наслаждаться мониторингом микротиков без погружения в тему prometheus и grafana.
Берём любую машину с установленным Docker. Клонируем себе репозиторий и переходим в него:
# git clone https://github.com/akpw/mktxp-stack.git# cd mktxp-stackОткрываем файл конфигурации mktxp.conf в директории mktxp и добавляем свои устройства в файл:
[hAPax3-01] hostname = 192.168.137.1[hAPax3-02] hostname = 192.168.137.2[hAPax3-03] hostname = 192.168.137.3И так далее. На всех устройствах добавляем отдельного пользователя для доступа mktxp. Ему достаточно прав read и api. Можете сделать через winbox или в консоли:
/user group add name=mktxp_group policy=api,read/user add name=mktxp_user group=mktxp_group password=mktxp_user_passwordИспользуем эту учётку в mktxp.conf
[default]................. username = mktxp_user password = mktxp_user_password...................Остальные параметры включайте на своё усмотрение. Там по названию понятен смысл, плюс, есть комментарии. Если на устройствах будут разные учётки, то пропишите их в разделе с устройством.
Больше ничего делать не надо. Можно запускать весь стек. Для этого переходим в директорию mktxp-stack и запускаем:
# docker compose -f ./docker-compose-mktxp-stack.yml up -dПереходим в веб интерфейс по IP адресу сервера на порт 3000, например http://192.168.137.29:3000. Попадёте сразу в веб интерфейс Grafana. Там уже всё настроено, аутентификация отключена. Вы сразу же увидите метрики со своих настроенных устройств. По крайней мере у меня сразу всё заработало. Ничего больше не делал.
Дашборд продуман и информативен. Я себе оставлю его. Не скажу, что сильно надо. Самому лень было настраивать. Но готовый можно взять. Там те же лизы от DHCP можно смотреть. Я иногда захожу через winbox поискать потерявшиеся хосты. Ну и просто статистику, загрузку интерфейсов, открытые соединения и топ хостов по ним посмотреть. На дашборде всё это нагляднее, чем в Winbox.
Как я уже сказал, аутентификация в Grafana отключена, по умолчанию почему-то установлена светлая тема. Мне привычнее тёмная. Поменять настройки grafana можно в основном compose файле - docker-compose-mktxp-stack.yml. Я вернул чёрный цвет:
GF_USERS_DEFAULT_THEME: "dark"Хорошее, добротное решение. Мне понравилось. Ниже много интересных картинок.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mikrotik #prometheus
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍103👎2
Вчера на прогулке прослушал длиннющий вебинар на тему, которую я никак не мог пропустить. Она тут на канале обсуждалась раз 10 в разное время:
⇨ Zabbix vs Prometheus на практике
Особо чего-то полезного и интересного, чего бы не знал, я не услышал. Автор сразу признался, что с Zabbix не работает, знает его приблизительно по старой памяти, когда сталкивался с ним по работе много лет назад. Из-за этого был в некоторых местах необъективен и никто не поправил в чате.
Например, он открыл из какого-то шаблона Zabbix старые графики, которые никто уже не использует, которые выглядят, как графики из начала двухтысячных и показал, как он мог бы быстро и удобно создать дашборд с визуализацией в Grafana в противовес тому, что он увидел на этих графиках. А факт в том, что в Zabbix в современных дашбордах можно получить так же быстро точно такой же дашборд ровно с такими же виджетами, как в его примере. Так же был продемонстрирован как пример удобства - сквозной запрос в Prom по какой-то метрике в разрезе сразу всех узлов. Zabbix тоже в какой-то момент после смены синтаксиса научился так делать.
Не то, чтобы я защищаю Zabbix. Он в этом не нуждается. Я и то, и другое активно использую и более-менее прилично знаю. Это инструменты под свои разные задачи. Я тут за объективность. Пишу заметку, чтобы акцентировать внимание на ключевом отличии с точки зрения автора вебинара между этими двумя системами. Никогда не смотрел на них под этим ключом.
В Zabbix всё крутится вокруг айтема, который привязан к метрике и по сути ей и является. Тебе обязательно надо подготовить систему мониторинга и конкретно узел, создав на нём тем или иным способом айтем - вручную, через шаблон, через правило автообнаружения или ещё как-то. И только после этого ты можешь принимать данные. Без этого ничего не получится.
В Prometheus принципиально другой подход - туда без всякой подготовки можно лить разные метрики. На сервере под каждую метрику не нужно создавать никаких сущностей. Хочешь 10 метрик отправляй, хочешь через минуту - 100. Серверу всё равно, он примет все без какой-либо донастройки. Это экономит время и организационно выглядит проще, что имеет решающее значение для динамических сред при выборе инструмента сбора метрик.
Архитектурно всё так и есть, это отличие ключевое. Я обычно на этот вопрос смотрю с точки зрения пользовательского опыта и воспринимаю Zabbix как полноценную систему мониторинга, где из коробки есть всё, что для неё нужно с удобной панелью управления. А Prometheus больше похож на фреймворк, который только собирает метрики, вокруг которого тебе предстоит самому из разных компонентов создать систему мониторинга. Как по мне - это ключевое отличие. Просто взгляд на продукты под другим углом.
Сколько лет прошло, а это принципиальное отличие не меняется. Из-за него у Prometheus появилось несколько совместимых взаимозаменяемых продуктов, которые можно безболезненно менять местами в системе мониторинга, не трогая остальные компоненты. А Zabbix как был сам собой, так и остался. Никто его не форкнул, не доработал, не написал совместимую замену. Были попытки, но все они остались местечковыми и не получили широкого распространения.
Второе заметное отличие с точки зрения практической работы с ним - Prometheus полностью совместим с подходом IaC, Zabbix - нет.
Ну и ещё один полезный момент. На вебинаре кто-то в чате написал, что активные агенты меньше нагружают сервер, так как сами шлют метрики, что упрощает процесс сбора. На самом деле это не так. Пассивные проверки архитектурно проще и если есть возможность забирать метрики сервером, то лучше делать именно так. Сервер обратился к агенту и забрал метрики. Если агент сам их отправляет, то он сначала стучится к серверу, забирает у него набор настроенных для него метрик и потом только их отправляет. Это больше итераций. Плюс, под нагрузкой у сервера меньше вариантов разрулить её, когда на него постоянно валится поток данных. Проще самому им управлять.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#zabbix #prometheus
⇨ Zabbix vs Prometheus на практике
Особо чего-то полезного и интересного, чего бы не знал, я не услышал. Автор сразу признался, что с Zabbix не работает, знает его приблизительно по старой памяти, когда сталкивался с ним по работе много лет назад. Из-за этого был в некоторых местах необъективен и никто не поправил в чате.
Например, он открыл из какого-то шаблона Zabbix старые графики, которые никто уже не использует, которые выглядят, как графики из начала двухтысячных и показал, как он мог бы быстро и удобно создать дашборд с визуализацией в Grafana в противовес тому, что он увидел на этих графиках. А факт в том, что в Zabbix в современных дашбордах можно получить так же быстро точно такой же дашборд ровно с такими же виджетами, как в его примере. Так же был продемонстрирован как пример удобства - сквозной запрос в Prom по какой-то метрике в разрезе сразу всех узлов. Zabbix тоже в какой-то момент после смены синтаксиса научился так делать.
Не то, чтобы я защищаю Zabbix. Он в этом не нуждается. Я и то, и другое активно использую и более-менее прилично знаю. Это инструменты под свои разные задачи. Я тут за объективность. Пишу заметку, чтобы акцентировать внимание на ключевом отличии с точки зрения автора вебинара между этими двумя системами. Никогда не смотрел на них под этим ключом.
В Zabbix всё крутится вокруг айтема, который привязан к метрике и по сути ей и является. Тебе обязательно надо подготовить систему мониторинга и конкретно узел, создав на нём тем или иным способом айтем - вручную, через шаблон, через правило автообнаружения или ещё как-то. И только после этого ты можешь принимать данные. Без этого ничего не получится.
В Prometheus принципиально другой подход - туда без всякой подготовки можно лить разные метрики. На сервере под каждую метрику не нужно создавать никаких сущностей. Хочешь 10 метрик отправляй, хочешь через минуту - 100. Серверу всё равно, он примет все без какой-либо донастройки. Это экономит время и организационно выглядит проще, что имеет решающее значение для динамических сред при выборе инструмента сбора метрик.
Архитектурно всё так и есть, это отличие ключевое. Я обычно на этот вопрос смотрю с точки зрения пользовательского опыта и воспринимаю Zabbix как полноценную систему мониторинга, где из коробки есть всё, что для неё нужно с удобной панелью управления. А Prometheus больше похож на фреймворк, который только собирает метрики, вокруг которого тебе предстоит самому из разных компонентов создать систему мониторинга. Как по мне - это ключевое отличие. Просто взгляд на продукты под другим углом.
Сколько лет прошло, а это принципиальное отличие не меняется. Из-за него у Prometheus появилось несколько совместимых взаимозаменяемых продуктов, которые можно безболезненно менять местами в системе мониторинга, не трогая остальные компоненты. А Zabbix как был сам собой, так и остался. Никто его не форкнул, не доработал, не написал совместимую замену. Были попытки, но все они остались местечковыми и не получили широкого распространения.
Второе заметное отличие с точки зрения практической работы с ним - Prometheus полностью совместим с подходом IaC, Zabbix - нет.
Ну и ещё один полезный момент. На вебинаре кто-то в чате написал, что активные агенты меньше нагружают сервер, так как сами шлют метрики, что упрощает процесс сбора. На самом деле это не так. Пассивные проверки архитектурно проще и если есть возможность забирать метрики сервером, то лучше делать именно так. Сервер обратился к агенту и забрал метрики. Если агент сам их отправляет, то он сначала стучится к серверу, забирает у него набор настроенных для него метрик и потом только их отправляет. Это больше итераций. Плюс, под нагрузкой у сервера меньше вариантов разрулить её, когда на него постоянно валится поток данных. Проще самому им управлять.
———
ServerAdmin:
#zabbix #prometheus
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Zabbix vs Prometheus на практике
🔥 Бесплатный демодоступ к практикуму Zabbix: https://clck.ru/3ThA4W
🔥 Бесплатный демодоступ к практикуму Prometheus: https://clck.ru/3ThA3t
Понравилась запись вебинара? Приходи на другие эфиры по DevOps и инфраструктуре: https://clck.ru/3SbNdf
Запись открытого…
🔥 Бесплатный демодоступ к практикуму Prometheus: https://clck.ru/3ThA3t
Понравилась запись вебинара? Приходи на другие эфиры по DevOps и инфраструктуре: https://clck.ru/3SbNdf
Запись открытого…
👍64👎1