Вдохновленный статьей про сбор, хранение и визуализации показателей с помощью prometheus и grafana подготовил готовый docker-compose файл для быстрой настройки и запуска мониторинга windows серверов.
Набор настроенных приложений для мониторинга серверов. Выполняется сбор показателей производительности серверов, их визуализация и оповещение при достижении критических значений.
Хранение, визуализация и оповещение выполняется с помощью сервисов и их конфигурационных файлов, описанных в docker compose файле. В docker compose файле описаны сервисы:
prometheus — хранение показателей,
graphite-exporter — прием сообщений с показателями,
alertmanager — оповещение,
grafana — визуализация,
nginx — реверс прокси для безопасности.
Сбор и отправка показателей производительности сервера выполняется с помощью приложения telegraf. Запуск telegraf может выполняться в виде приложения или в виде службы.
Описание используемых компонент
Для сбора и хранения показателей используется приложение prometheus. Prometheus использует модель pull (тянуть, "дергать") запросов для получения показателей. Такой подход удобен, если prometheus и наблюдаемый сервер находятся "рядом", но при необходимости сбора показателей на "удаленных" серверах гораздо удобнее и безопаснее использовать модель push (толкать) запросов.
Поэтому, используется официальное расширение (exporter) graphite-exporter. Расширение запускается как отдельное приложение: оно принимает push сообщения с показателями, преобразует их и предоставляет для использования prometheus с помощью pull модели запросов.
Для отправки push сообщений используется приложение telegraf. У telegraf есть много различных плагинов для получения показателей ОС, СУБД и различных приложений. В данном случае используется плагин win_perf_counters для сбора показателей ОС windows. Собираются основные показатели производительности ЦП, оперативной памяти, дисков и сетевых интерфейсов. По умолчанию показатели отправляются раз в минуту.
Для визуализации показателей используется grafana с предустановленными дашбоардами: overview, disk_overview, memory_overview.
Для отправки предупреждений о критических ситуациях используется alertmanager. Предустановлена отправка электронных сообщений при превышении загруженности ЦП более 50% в течении 5 минут, при уменьшении доступной оперативной памяти менее 2 Гб, при уменьшении свободного дискового пространства менее 10%.
Для безопасного подключения к grafana и передачи показателей graphite-exporter используется реверс прокси nginx. Используется самоподписанный сертификат.
Быстрый старт для мониторинга в локальной сети
Предполагается, что уже есть linux сервер и на нем установлены последние версии docker и docker-compose.
1. Скопировать файл install.sh и архив prometheus_server.tar.
2. Разрешить исполнение скрипта install.sh:
chmod +x install.sh
3. Запустить скрипт install.sh.
4. Перейти в каталог prometheus_server.
5. Запустить команду:
docker-compose up
Будут загружены последние образы используемых приложений и запущены в отдельных контейнерах.
В консоли будут выводиться сообщения от приложений. Для запуска приложений в фоне нужно выполнить команду:
docker-compose up -d
6. Изменить адрес отправки показателей в файле telegraf.conf в разделе outputs.graphite с your-server:9109 на локальный адрес linux сервера.
Запустить отправку показателей с помощью telegraf:
telegraf.exe --config telegraf.conf
Просмотр показателей доступен в grafana по адресу your-server:3000. По умолчанию для первой авторизации используются логин, пароль: admin, admin.
Настройка оповещений по электронной почте
В файле alertmanager/alertmanager.yml:
заполнить настройки отправки сообщений по электронной почте smtp_*,
указать получателей в разделе receivers в параметре email_configs — to.
Настройка для мониторинга серверов вне локальной сети
Для приема сообщений с показателями от серверов вне локальной сети используется реверс прокси nginx с SSL/TLS. Для этого нужно в docker compose файле раскомментировать сервис nginx и в конфигурационном файле nginx/nginx.conf раскомментировать секцию stream. Запустить контейнер с сервисом nginx:
docker-compose up -d nginx
В конфигурационном файле telegraf/telegraf.conf в разделе outputs.graphite раскомментировать настройку insecure_skip_verify = true.
После этого можно отправлять сообщения с показателями производительности на внешний адрес по порту 49109.
Настройка для просмотра показателей не из локальной сети
Для просмотра показателей не из локальной сети нужно в docker compose файле для сервиса grafana раскомментировать раздел environment и заменить your-server на внешний адрес, а также раскомментировать в конфигурационном файле nginx/nginx.conf секцию http и заменить в ней параметр server_name c your-server.com на внешний адрес. Создать заново контейнер с grafana:
docker-compose up -d grafana
Перезапустить сервис nginx:
docker-compose restart nginx
К grafana можно подключиться по адресу https://your-server.com/grafana.
При использовании релизов с включенным реверс прокси (с суффиксом with_reverse_proxy) для начала использования достаточно настроить:
В конфигурационном файле telegraf/telegraf.conf в разделе outputs.graphite раскомментировать настройку insecure_skip_verify = true.
После этого можно отправлять сообщения с показателями производительности на внешний адрес по порту 49109.
В docker compose файле для сервиса grafana в разделе environment заменить your-server на внешний адрес и в конфигурационном файле nginx/nginx.conf в секции http заменить параметр server_name c your-server.com на внешний адрес.
Описание результата
Запущены сервисы:
prometheus:9090 — выполнение и отладка запросов к prometheus,
graphite-exporter:9108 — просмотр принимаемых показателей,
graphite-exporter:9109 — прием сообщений с показателями,
alertmanager:9093 — просмотр оповещений,
grafana:3000 — просмотр показателей,
nginx:443 — просмотр показателей через реверс прокси,
nginx:49109 — прием сообщений с показателями через реверс прокси.
Для подключения к запущенным приложениям с linux сервера нужно использовать localhost, например, localhost:9090. Для подключения к запущенным приложениям из локальной сети нужно использовать имя linux сервера, например, your-server:9090.
Для просмотра списка и статуса всех контейнеров нужно выполнить команду:
docker-compose ps
Для остановки приложений нужно выполнить команду:
docker-compose stop
Для удаления созданных контейнеров нужно выполнить команду:
docker-compose down
Описание настроек сервисов в docker compose файле.
Сервис prometheus
prometheus/prometheus.yml — настройки хранения данных, сбора показателей из graphite-exporter, правил генерации оповещений rules.yml, отправки оповещений в alertmanager
prometheus/rules.yml — правила генерации оповещений
prometheus/data — каталог хранения данных
Сервис graphite-exporter
graphite-exporter/graphite-exporter.yml — настройки преобразования сообщений с показателями производительности из формата graphite в формат prometheus
Сервис alertmanager
alertmanager/alertmanager.yml — настройки обработки и методов доставки оповещений
alertmanager/data — хранение данных оповещений
Сервис grafana
GF_SERVER_DOMAIN=your-server.com
GF_SERVER_ROOT_URL=%(protocol)s://%(domain)s/grafana
переменные окружения устанавливаются для использования grafana через реверс прокси nginx
grafana/grafana-storage — хранение данных grafana: источники, дашбоарды
Сервис nginx
nginx/nginx.conf — настройки прокси сервера
nginx/cert — самоподписанные сертификаты для использования защищенного соединения
Отладка
prometheus
your-server:9090 — выполнение и отладка запросов к prometheus
graphite-exporter
your-server:9108 — просмотр принимаемых показателей
alertmanager
your-server:9090/alerts — просмотр правил оповещений и их генерации
your-server:9093 — просмотр обработки оповещений
telegraf
telegraf.exe —config telegraf_debug.conf — отладка получения, отправки показателей
Получение и вывод одного показателя в консоль. Дополнительную информацию можно посмотреть в лог файле telegraf.log.
Просмотр журналов приложений:
docker-compose logs prometheus
Подключение к контейнеру с приложением:
docker-compose exec prometheus bash
или
docker-compose exec prometheus sh
Публикация на github.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
В чем преимущества по сравнению со штатными средствами (perfmon + Data Collectors Set)?
Буквально на днях пришла идея в prometheus отправлять логи тж, в графане по этим данным выводить дажборды
(1) Главное преимущество — это удобство:
быстрая настройка и запуск (для начала сбора показателей на новом сервере достаточно только запустить клиента),
дашбоарды,
возможность обработки показателей перед выводом,
возможность одновременно анализировать предыдущие данные и текущие (в perfmon либо пишутся в файл, либо выводятся в текущее окно),
возможность агрегации данных с разных серверов.
(2) Prometheus лучше подходит для хранения числовых рядов. Если нужно хранить ТЖ, то лучше использовать ELK, причем на инфостарте уже есть публикации на эту тему.
(4) можно ссылку?
(3)
быстрая настройка и запуск (для начала сбора показателей на новом сервере достаточно только запустить клиента)
Ну так для начала мониторинга штатными средствами достаточно набрать perfmon, выбрать сервер и добавить счетчики. Все уже есть 🙂
возможность одновременно анализировать предыдущие данные и текущие (в perfmon либо пишутся в файл, либо выводятся в текущее окно),
возможность агрегации данных с разных серверов.
Штатной возможностью является запись в СУБД.
Дальше Вы можете анализировать, агрегировать, сравнивать etc.
(6)
Прямо скажем, это все таки не одна команда по запуску клиента.
В простом случае показатели будут отображаться только в текущем окне и никуда не сохранятся и при повторном желании посмотреть показатели нужно будет повторять действия заново.
Это можно использовать при мониторинге за «локальными» серверам, для мониторинга за «удаленными» серверами такой вариант не подойдет.
(7)
В простом случае показатели будут отображаться только в текущем окне и никуда не сохранятся и при повторном желании посмотреть показатели нужно будет повторять действия заново
Да, Вы правы, описан простейший вариант, однако полная настройка ~ + 5-10 кликов мыши.
Локальный — это сервер в локальной сети?
А с чем связана невозможность по Вашему мнению?
(5) Вот ссылка на оригинальную , вот ссылка на . В статье не сказано про ElasticSearch, но в последних версиях есть такой функционал.
(9)и где там elk? Elk это не только ElasticSearch.
А если рассматривать elk для данной задачи, то конечно можно, но я бы не сказал, что это простой путь, как минимум нужно будет выучить очередной птичий язык (я про dsl у ElasticSearch). А я же хочу сделать проще, что бы интуитивно в графане можно было дажборды конфигурировать (и да в значениях будут числа (там ничего другого и не нужно). Да не так гибко как elk, но зато всем доступно. Если кто-то нормальную статью по elk сделает, будет здорово
(8)
А с чем связана невозможность по Вашему мнению?
Как я понимаю, для передачи данных в СУБД сначала нужно настроить источник данных. Потом будет выполняться подключение к указанному источнику данных и будут записываться показатели. Соответственно, нужно предоставлять возможность доступа к СУБД со всех наблюдаемых сервером.
В описываемом стеке приложений открывается только возможность приема сообщений с показателями, что является более безопасным сценарием.
(10)
Посмотрите исходники на гитхаб. Начиная со второй версии есть возможность выгрузки в ElasticSearch.
(10)
Трудно не согласиться, но других публикаций не видел.
(11)
Да, все верно.
Каким образом сервер определяет, что это сообщения с показателями и они отправлены не злоумышленником?
Вы считаете протокол взаимодействия с СУБД менее безопасным? Если да, то почему?
(14)
Вы считаете протокол взаимодействия с СУБД менее безопасным? Если да, то почему?
Я не считаю, что протокол взаимодействия с СУБД менее безопасный, я считаю более опасным возможность получения доступа злоумышленника к СУБД.
В описываемом стеке приложение graphite-exporter принимает сообщения с показателями и ничего другого оно принять не может. Самое плохое, что может произойти — это прием неверных показателей.
(9) Ошибочка, статья и приложение не для ТЖ, а для ЖР.
(10)
А какие числовые показатели имеются ввиду? Например, длительность вызова?
(15)
Какие дополнительные риски на Ваш взгляд существуют при прямом обращении к СУБД?
(18) Все зависит от настроек: в худшем случае можно потерять все, в лучшем — будут добавляться неверные показатели. Но чтобы достичь лучшего варианта необходимы дополнительные настройки разрешений для пользователя, под которым выполняется подключение.
А тут те же наименьшие риски, но «из коробки».
(17) duration, количество вызовов (с группировкой по разным свойствам, полезно для понимания сколько однотипных ошибок в системе), значение мемори и меморипик.