Http prometheus freize net

Cкрипт для обслуживания и перепрошивки роутеров

Скрипт запускаются на любом Debian подобном Linux дистрибутиве. Он мало весит, шустро работает, соответствует критериям безопасности при прошивке и содержит различные моды и хаки. Время необходимое для компиляции и установки программного обеспечения может занимать от 10 минут на современном компьютере и до 15 часов на наследстве из девяностых. Здраво оценивайте ваше время перед началом операции компиляции, это залог успеха.
На данный момент, кроме официально заявленных роутеров ASUS: RT-AC1200HP, RT-AC51U, RT-AC54U, RT-N11P, RT-N14U, RT-N56U, RT-N56UB1, RT-N65U поддерживаются Xiaomi MI-MINI, MI-NANO, MI-3, NEXX WT3020 (A,H,F), Belkin N750 DB, Samsung CY-SWR1100 и ZyXEL Keenetic devices 4g3, extra, giga3, lite2, lite3, omni, omni2, ultra2, viva.

Для запуска на вашей основной Linux системе произведите следующие действия:

1. Откройте терминал;
2. Скачайте скрипт, введя команду: wget -O start.sh http://prometheus.freize.net/script/start-99.sh
3. Введите: chmod +x start.sh
4. Запустите скрипт и следуйте дальнейшим инструкциям в терминале: ./start.sh

Нет Linux под рукой? Вы можете воспользоваться виртуальной машиной:

Если у вас установлена 64х разрядная система, рекомендуется воспользоваться VMware Workstation Player:
1. Скачайте и установите VMware Workstation Player;
2. Скачайте и распакуйте образ виртуальной машины PROMETHEUS;
3. Запустите VMware Workstation Player и добавьте распакованный контейнер;
4. Настройте параметры контейнера:
4.1. Настройте количество ядер и оперативной памяти для виртуальной машины;
4.2. Проверьте остальные настройки контейнера.
5. Запустите виртуальную машину.

Если у вас 86х (32х) разрядная система, рекомендуется установить Oracle VM VirtualBox:
1. Скачайте и установите Oracle VM VirtualBox;
2. Скачайте и распакуйте образ виртуальной машины PROMETHEUS;
3. Запустите Oracle VM VirtualBox и добавьте распакованный контейнер;
4. Настройте параметры контейнера:
4.1. Настройте количество ядер и оперативной памяти для виртуальной машины;
4.2. Обязательно переключите сетевое подключение в режим моста.
5. Запустите виртуальную машину.

Перед первичной прошивкой роутера, необходимо выполнить инициализацию роутера и однократно применить хак SSH (пункт 0), а на установленной xrmwrt достаточно включить поддержку SSH в настройках роутера, где логин и пароль будут такие как и на WEB интерфейсе.
После первой инициализации скрипта можно воспользоваться файловым менеджером, набрав команду mc
Для работы скрипта нужен интернет на стадии подготовки к компиляции и вовремя обновления, для взлома и прошивки интернет не нужен.

Крайне рекомендуется идти от первого пункта к последнему (в пределах разумного конечно, обновлять скрипты и исходники после первого запуска не нужно и некоторые пункты могут дублировать друг друга, например, ручной и автоматический редактор конфига), а после перепрошивки перезагружать роутер. Ничего страшного не случится при несоблюдении данных рекомендаций, но чтобы получить 100% положительный результат лучше их соблюдать.

ВНИМАНИЕ! Скрипт никак не влияет на то, собирается прошивка или нет. Влияет только версия исходного кода и зависимости (установленные пакеты). Если у вас что-то не собралось, вам нужно проверить целостность исходников и установленные пакеты.

В предыдущих публикациях мы уже затрагивали вопросы мониторинга и сбора метрик. В сегодняшней статье мы хотели бы вернуться к этой теме и рассказать об интересном инструменте под названием Prometheus. Он был создан в 2012 году в качестве внутренней системы мониторинга небезызвестного проекта SoundCloud, но впоследствии получил более широкое распространение.

Prometheus — инструмент совсем новый (первый публичный релиз состоялся в начале 2015 года), и на русском языке публикаций о нём пока почти что нет (несколько месяцев назад была опубликована статья в журнале «Хакер», но она доступна только подписчикам).

Разработчики SoundCloud отмечают (см. подробный доклад здесь), что новый инструмент мониторинга понадобился им в связи с переходом к микросервисной архитектуре. Рост интереса к микросервисам — одна из характерных тенденций последних нескольких лет.
С точки зрения микросервисного подхода приложение пониматеся не как монолит, а как набор сервисов. Каждый из этих сервисов работает в своём процессе и взаимодействует с окружением при помощи простого механизма (как правило, через протокол HTTP).

Мониторинг микросервисов — задача непростая: в режиме реального времени нужно отслеживать как состояние отдельных компонентов, так и состояние системы в целом. Задача усложняется, если помимо технических нужно проверять ещё и бизнес-значимые показатели. Как отмечают сами разработчики Prometheus в многочисленных статьях и докладах, с помощью имеющихся систем мониторинга её решить проблематично. Поэтому они создали собственный инструмент.

Prometheus представляет собой комплексное решение, в состав которого входят и фреймворк для мониторинга, и собственная темпоральная база данных. В некоторых обзорах его даже называют «системой мониторинга нового поколения».
Публикации о Prometheus нас заинтересовали, и мы решили познакомиться с этим инструментом поближе.

Архитектура Prometheus

В состав Prometheus входят следующие компоненты:

сервер, который считывает метрики и сохраняет их в темпоральной (time series) базе данных;
клиентские библиотеки для различных языков программирования (Go, Java, Python, Ruby; сообществом также созданы библиотеки для Bash, Node.js, Haskell, .NET/C#);
Pushgateway — компонент для приёма метрик кратковременных процессов;
PROMDASH — дашборд для метрик;
инструменты для экспорта данных из сторонних приложений (Statsd, Ganglia, HAProxy и других);
менеджер уведомлений AlertManager (на текущий момент находится на стадии бета-тестирования);
клиент командной строки для выполнения запросов к данным.

Большинство из них написаны на Go, а совсем небольшая часть — на Ruby и Java.
Все компоненты Prometheus взаимодействуют между собой по протоколу HTTP:

Главный компонент всей системы — сервер Prometheus. Он работает автономно и сохраняет все данные в локальной базе данных. Обнаружение сервисов происходит автоматически. Это упрощает процедуру развёртывания: для наблюдения за одним сервисом не нужно разворачивать распределённую систему мониторинга; достаточно установить только сервер и необходимые компоненты для сбора и экспорта метрик. Таких компонентов, «заточенных» под конкретные сервисы, уже создано довольно много: для Haproxy, MySQL, PostrgreSQL и другие (полный список см. здесь, а также на GitHub).

Сбор метрик в Prometheus осуществляется с помощью механизма pull. Имеется также возможность сбора метрик с помощью механизма push (для этого используется специальный компонент pushgateway, который устанавливается отдельно). Это может понадобиться в ситуациях, когда сбор метрики с помощью pull по тем или иным причинам невозможен: например, при наблюдении за сервисами, защищёнными фаерволлом. Также механизм push может оказаться полезным при наблюдении за сервисами, подключающихся к сети периодически и на непродолжительное время.

Prometheus хорошо подходит для сбора и анализа данных, представленных в виде временных рядов (time series). Все метрики он хранит в собственной темпоральной БД (её сравнение с OpenTSDB и InfluxDB см. здесь); для хранения индексов используется LevelDB.

Модель данных

Prometheus хранит данные в виде временных рядов — наборов значений, соотнесённых с временной меткой (timestamp).

Элемент временного ряда (измерение) состоит из имени метрики, временной метки и пары «ключ — значение». Временные метки имеют точность до миллисекунд, значения представлены с 64-битной точностью.

Имя метрики указывает на параметр системы, о котором собираются данные. Например, у метрики с информацией о количестве HTTP-запросов к некоему API имя может выглядеть так: api_http_requests_total. Временной ряд в такой метрике может хранить информацию о обо всех GET-запросах на адрес /api/tracks, на которые был отдан ответ с кодом 200. Этот временной ряд можно представить в виде следующей нотации:

Модель данных, используемая в Prometheus, напоминает ту, что используется в OpenTSDB. У всех метрик есть имя, но оно может быть одним и тем же у нескольких рядов.
При этом каждый временной ряд должен быть помечен хотя бы одним тэгом. Измерения для одного тэга хранятся последовательно, что обеспечивает быструю агрегацию данных.
Поддерживаются следующие типы метрик:

счётчик (counter) — хранит значения, которые увеличиваются с течением времени (например, количество запросов к серверу);
шкала (gauge) — хранит значения, которые с течением времени могут как увеличиваться, так и уменьшаться (например, объём используемой оперативной памяти или количество операций ввода-вывода);
гистограмма (histogram) — хранит информацию об изменении некоторого параметра в течение определённого промежутка (например, общее количество запросов к серверу в период с 11 до 12 часов и количество запросов к этому же серверов в период с 11.30 до 11.40);
сводка результатов (summary) — как и гистограмма, хранит информацию об изменении значения некоторого параметра за временной интервал, но также позволяет рассчитывать квантили для скользящих временных интервалов.

Установка

Рассмотрим теперь практические аспекты использования Prometheus. Начнём с описания процедуры установки.
Совсем недавно Prometheus был включён в официальные репозитории Debian 8 и Ubuntu 15.10.
В Ubuntu 14.04 его тоже можно установить при помощи стандартного менеджера пакетов. Естественно, для этого понадобится подключить соответствующий репозиторий:

С помощью приведённых команд мы установили сервер Prometheus, а также дополнительные компоненты — node_exporter и alertmanager. Node_exporter собирает данные о состоянии сервера, а alertmanager (о нём мы более подробно поговорим ниже) — рассылает уведомления в случае выполнения или невыполнения заданных условий.

Установка завершена, но остался ещё один маленький штрих: нужно сделать так, чтобы node_exporter постоянно собирал метрики в фоновом режиме. Для этого сначала создадим символическую ссылку в /usr/bin:

Затем создадим файл /etc/init/node_exporter.conf и добавим в него следующие строки:

Сохраним внесённые изменения и выполним команду:

В дистрибутивах, перешедших на systemd (например, в Ubuntu 15.10), для запуска node_exporter в фоновом режиме нужно создать файл /etc/systemd/system/node_exporter.service и добавить в него следующие строки:

Сохранив внесённые изменения, нужно выполнить команды:

Конфигурирование

Настроек Prometheus по умолчанию вполне достаточно, чтобы следить за всем происходящим на локальной машине. Дополнительные настройки в случае необходимости всегда можно прописать в конфигурационном файле /etc/prometheus/prometheus.yml. Рассмотрим его структуру более подробно. Начинается он с секции globals:

Она включает следующие параметры:

scrape_interval — интервал сбора метрик (по умолчанию — 15 секунд);
evaluation_interval — интервал сверки с правилами (по умолчанию — 15 секунд);
rule_files — файлы правил (речь о них пойдёт ниже).

Далее следует секция scrape_configs с базовыми настройками сбора метрик на сервере:

Она включает следующие обязательные параметры:

job_name — имя задачи;
scrape_interval — интервал сбора метрик (в приведённом примере — каждые 15 секунд);
target_groups — сервисы и группы сервисов, для которых нужно собирать метрики.

В этой же секции можно прописать дополнительные настройки:

scrape_timeout — время ожидания данных;
metrics_path — HTTP-ресурс, на который будут передаваться метрики;
scheme — протокол, который будет использоваться для передачи метрик;
basic_auth — реквизиты для авторизации на сервере, с которого будут собираться метрики (username:, password:).

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

В общем виде синтаксис правил можно представить так:

Приведём более конкретные и понятные примеры:

Prometheus сверяется с правилами с определённой периодичностью, указанной в конфигурационном файле в параметре evaluation_interval). После каждой сверки Prometheus пересчитывает значение параметра и сохраняет его под новым именем с текущей временной меткой.
Итак, структуру и синтаксис конфигурационного файла мы в общих чертах рассмотрели. Чтобы прописанные настройки вступили в силу, нужно выполнить следующую команду (вместо path/to/prometheus.yml указываем путь к конфигурационному файлу):

Веб-интерфейс

Веб-интерфейс Prometheus будет доступен в браузере по адресу: http://[IP-адрес сервера]:9090:

В поле Expression можно выбрать метрику, для которой будет отображаться график. Попробуем отследить, например, объём активной памяти на сервере. Выбираем метрику node_memory_active и нажимаем на кнопку Execute:

Над графиком расположены кнопки, с помощью которых можно выбирать период для отображения статистики.

Шаблоны консолей

Основную консоль Prometheus мы только что рассмотрели. Для просмотра более специализированных графиков используются кастомные консоли.
На сервере они хранятся в директории /еtc/prometheus/consoles. Кастомные консоли отображают общую статистику сервера (node.html), статистику СPU (node-cpu.html), статистику операций ввода-вывода на сервере (cpu-disk.html) и другие. В браузере они доступны по адресу: http://[IP адрес сервера]:9090/consoles/ .html.
Вот так, например, выглядит консоль node.html:

Если вам не подходит ни одна из имеющихся консолей, вы можете создать собственную консоль, которая будет отображать нужную вам статистику. Для написания консолей в Prometheus используется HTML-шаблонизатор Go. Подробные инструкции по созданию кастомных консолей приведены в официальной документации.
А если вас по тем или иным причинам не устраивают имеющиеся консоли, вы можете интегрировать Prometheus с популярным инструментом Grafana.

Разработчики Prometheus создали и собственный инструмент для создания дашбордов под названием Promdash (см. также репозиторий на GitHub), по интерфейсу напоминающий Grafana. На наш взгляд, он ещё находится в несколько «сыром» состоянии, и рекомендовать его к использованию пока что рано.

Alertmanager: настройка уведомлений

Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется alertmanager. Настройки уведомлений хранятся в конфигурационном файле alertmanager.conf.
Рассмотрим следующий фрагмент:

Его синтаксис вполне понятен: мы указали, что уведомления при наступлении определённого условия нужно отправлять по электронной почте на адрес test@example.org.

В конфигурационный файл можно добавлять ссылки на файлы правил (по сути они ничем не отличаются от файлов правил для сбора метрик, описанных выше). В правилах прописываются условия, при которых нужно отправлять уведомления.

В общем виде синтаксис правила выглядит так:

Рассмотрим функции правил на более конкретных примерах.
Пример1:

Это правило указывает, что уведомление нужно отправлять в случае, если некоторый инстанс недоступен в течение 5 минут и более.

Согласно этому правилу, уведомления нужно посылать, как только среднее время ответа на запросы к API превысит 1 мс.

Чтобы прописанные в конфигурационном файле настройки вступили в силу, нужно сохранить его и выполнить команду:

Можно создать несколько конфигурационных файлов и прописать в них настройки уведомлений для различных случаев.

Уведомления Prometheus отправляет в формате JSON. Выглядят они примерно так:

Отправка уведомлений осуществляется по электронной почте, через веб-хук, а также с помощью специализированных сервисов: PagerDuty, HipChat и других.
Разработчики Prometheus отмечают, что пока что alertmanager находится в «сыром» состоянии и предупреждают о возможных ошибках. Впрочем, мы никаких аномалий в работе этого компонента не заметили.

Заключение

Prometheus — инструмент достаточно интересный и перспективный, и на него стоит обратить внимание. В числе его преимуществ нужно в первую очередь выделить:

простоту развертывания;
широкие возможности интеграции со сторонними приложениями и сервисами;
удобный графический интерфейс для работы с метриками.

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

Для желающих узнать больше приводим несколько полезных ссылок:

Если вы по тем или иным причинам не можете оставлять комментарии здесь — приглашаем в наш блог.

Скрипты запускаются на любом Debian подобном Linux дистрибутиве.
Обратите внимание, что для работы скрипта желательно Ubuntu 15 или более свежая.

Для запуска на вашей основной Linux системе произведите следующие действия:
1. Откройте терминал;
2. Скачайте скрипт, введя команду:
2.1. Для х64 битной системы wget -O start.sh http://prometheus.freize.net/script/start-64.sh
2.2. Для х32 битной системы wget -O start.sh http://prometheus.freize.net/script/start-32.sh
3. Введите: chmod +x start.sh
4. Запустите скрипт и следуйте дальнейшим инструкциям в терминале: ./start.sh

Если у вас нет такого под рукой, вы можете воспользоваться виртуальной машиной, для этого выполните несколько простых пунктов:
1. Скачайте и установите VMware Workstation Player;
2. Скачайте и распакуйте образ виртуальной машины PROMETHEUS;
3. Запустите VMware Workstation Player и добавьте распакованный контейнер;
4. Настройте параметры контейнера:
4.1. Настройте количество ядер и оперативной памяти для виртуальной машины;
4.2. Проверьте остальные настройки контейнера.
5. Запустите виртуальную машину;
6. После запуска укажите логин user и пароль user (обратите внимание, что пароль при вводе не отображается);
7. После завершения авторизации введите ./start.sh и следуйте инструкциям в терминале.

Обратите внимание, что все манипуляции с файлами можно проводить в MC. Для этого необходимо и достаточно ввести команду mc
Для получения доступа по SSH в скрипт встроен хак.
Для работы скрипта нужен интернет на стадии подготовки к компиляции и вовремя обновления, для взлома и прошивки интернет не нужен.

ВНИМАНИЕ! Скрипт никак не влияет на то, собирается прошивка или нет. Влияет только версия исходного кода и зависимости (установленные пакеты). Если у вас что-то не собралось, вам нужно проверить целостность исходников и установленные пакеты.