VPS куплен, SSH-сессия открыта. У многих здесь возникает пауза: непонятно, с чего начать и под какую задачу настраивать VPS-сервер. Разберём пять практических сценариев того, как использовать VPS: хостинг сайтов, запуск ботов, размещение API, мониторинг и автоматизация. У каждого – конкретный стек, ориентиры по ресурсам и нюансы, которые лучше знать до начала настройки, а не в процессе. Реальные требования зависят от сложности проекта, нагрузки, выбранного стека и числа одновременно работающих сервисов.

Что даёт VPS и почему его берут

VPS-сервер отличается от shared-хостинга тремя вещами. Первое – у вас есть заявленные параметры тарифа: CPU, RAM, диск и сетевой канал. На качество работы всё ещё может влиять общая инфраструктура хоста, но изоляция здесь выше, чем на shared-хостинге. Второе – root-доступ: можно установить любой софт, выбрать версию PHP, настроить nginx под конкретную задачу. Третье – VPS-сервер работает круглосуточно без вашего участия, независимо от состояния вашего компьютера или интернета. На shared-хостинге чужая нагрузка может повлиять на соседние сайты, если провайдер плохо ограничивает ресурсы аккаунтов.

От облачных функций (AWS Lambda, Yandex Cloud Functions) VPS отличается предсказуемостью: нет cold-start задержек, нет тарификации за каждый вызов функции, нет ограничений по времени выполнения. Для задач с постоянными процессами: баз данных, ботов, мониторинга – VPS часто проще и предсказуемее, чем serverless-архитектура с оплатой за вызов. При низкой или нерегулярной нагрузке serverless может оказаться дешевле.

Базовая подготовка: что сделать сразу после покупки

Настройка VPS начинается не сразу с рабочего проекта, а с базовой конфигурации. Базовая настройка снижает риск классических проблем: открытого SSH, устаревших пакетов, лишних портов и нехватки памяти при пиковых нагрузках. Пропуск таких шагов может увеличить риск потерять сервер из-за брутфорса или случайной команды от root.

•  SSH-ключи. Сгенерируйте пару через ssh-keygen, передайте публичный ключ через ssh-copy-id, отключите аутентификацию по паролю в sshd_config.

•  Пользователь без root. Создайте аккаунт с правами sudo. Работа от root в продакшене – плохая практика. Одна ошибка может стоить всей системы.

•  Firewall. Откройте в UFW SSH-порт, 80 и 443, если они нужны вашему сценарию. Если используется стандартный SSH-порт, это 22. Fail2ban добавит защиту от брутфорса на SSH.

•  Swap. Если RAM меньше 2 ГБ, добавьте swap-файл на 1–2 ГБ. Он снижает риск OOM при пиковой нагрузке, но при активном использовании может ухудшить производительность.

•  Обновления. Запустите sudo apt update && apt upgrade сразу после входа на сервер, до начала любой работы.

Сценарий 1. Хостинг сайтов и веб-проектов

Хостинг на VPS оправдан, когда shared-хостинг перестал справляться: нет нужной версии PHP или Python, не хватает памяти, несколько доменов требуют разных настроек или нестандартного ПО. На VPS больше свободы в настройке: можно выбрать версии ПО, настроить веб-сервер, подключить нужные модули и управлять несколькими проектами независимо. Именно поэтому многие переезжают сюда с первого же конфликта с техподдержкой shared-хостинга.

Стек: Nginx как веб-сервер и reverse proxy, PHP-FPM для WordPress или других CMS, MySQL или PostgreSQL как база данных. Для статических сайтов (Hugo, Astro, Next.js SSG) Nginx работает без интерпретатора, нагрузка минимальная. SSL – Let’s Encrypt через Certbot, бесплатно и с автообновлением. Один Nginx обслуживает несколько доменов через server blocks.

Порты СУБД (3306, 5432) наружу не открывайте: приложение обращается к базе внутри сервера. Для сайта с умеренным трафиком часто хватает 1 vCPU и 1–2 ГБ RAM; для тяжёлых CMS с кешированием, большим числом плагинов или высокой посещаемостью лучше закладывать 2 vCPU и 2–4 ГБ. Добавьте Redis для кеша сессий: это может снизить нагрузку на базу данных и улучшить отклик WordPress при росте трафика.

Сценарий 2. Запуск Telegram- и Discord-ботов

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

Стек для Telegram: Python + aiogram, управление процессом через systemd, хранение состояния в SQLite или PostgreSQL. SQLite подходит для небольших ботов с умеренной нагрузкой, но при высокой конкуренции запросов или запуске нескольких экземпляров приложения лучше сразу выбирать PostgreSQL. Для Discord – Node.js + discord.js, для управления процессом удобен PM2. Redis подойдёт для быстрого хранения временных данных и очередей.

Для большинства продакшен-сценариев с Telegram-ботами удобен webhook-режим: сервер сам получает обновления, не опрашивая API Telegram. Для webhook нужен домен с HTTPS. Polling тоже остаётся корректным вариантом для небольших проектов: он проще в запуске и не требует домена с HTTPS. Простой бот без базы данных умещается на 1 vCPU и 1 ГБ RAM. Бот со сложными очередями, вызовами внешних API и ML-моделями потребует минимум 2 ГБ RAM. Через systemd настраивается автозапуск: после перезагрузки сервера бот поднимется сам.

Сценарий 3. Размещение API и бэкендов

VPS-сервер даёт API постоянный адрес, свою базу данных и полный контроль над окружением, без vendor lock-in и без ограничений по времени выполнения запросов. Это важно для бэкендов с длительными операциями: обработкой файлов, парсингом, генерацией отчётов.

Стек: FastAPI (Python) или Express.js (Node.js) для REST, Docker для изоляции сервисов, Nginx или Traefik как reverse proxy. Приложение слушает на localhost, наружу открыты только 80 и 443. GraphQL – Strawberry (Python) или Apollo Server (Node.js). Для автодеплоя – GitHub Actions: пуш в main запускает пересборку и перезапуск контейнера.

Порты базы данных держите внутри Docker-сети, не открывайте наружу: бэкенд обращается к базе по имени сервиса внутри сети. Для API с базой данных начинайте с 2 vCPU и 2–4 ГБ RAM. При росте нагрузки Docker и reverse proxy позволяют масштабировать сервисы без переписывания архитектуры. Traefik автоматически получает и обновляет SSL-сертификаты через Let’s Encrypt при настроенном ACME, поэтому отдельная настройка Certbot не нужна.

Сценарий 4. Мониторинг и сбор метрик

Сервер мониторинга должен работать независимо от мониторируемой инфраструктуры. Если основной сервер упал, система мониторинга должна увидеть это первой и отправить алерт, а не упасть вместе с ним. Отдельный небольшой VPS для мониторинга решает эту задачу.

Uptime Kuma – удобный инструмент с веб-интерфейсом: отслеживает HTTP-статусы, время ответа, порты TCP, отправляет алерты в Telegram, Slack и другие каналы. Разворачивается через Docker за несколько минут и обычно помещается в небольшой VPS. Для лёгкого мониторинга часто достаточно 512 МБ RAM, но потребление зависит от числа проверок и их типа.

Prometheus + Grafana – полный стек для сбора метрик, построения дашбордов и настройки алертов. Prometheus собирает данные с exporters, Grafana строит графики. Оба сервиса вместе могут потреблять примерно 600–1000 МБ RAM в покое, но фактическое потребление зависит от retention, числа targets и объёма метрик. Под этот сценарий обычно стоит закладывать не меньше 2 ГБ RAM. Node Exporter собирает системные метрики хоста – CPU, RAM, диск, сеть; добавьте его на каждый наблюдаемый сервер. Алерты в Telegram настраиваются через Alertmanager за несколько минут.

Сценарий 5. Автоматизация и рабочие процессы

Сервер не выключается. Это главное преимущество VPS для автоматизации: cron-задачи запускаются по расписанию в любое время суток, скрипты работают столько, сколько нужно, без ограничений по времени выполнения и без зависимости от того, включён ли ваш компьютер.

n8n – self-hosted инструмент для визуальной автоматизации, аналог Zapier на вашем сервере. Разворачивается через Docker, а потребление памяти может начинаться примерно от 500 МБ RAM и расти с числом workflow, интеграций и выбранной БД. Данные о задачах хранятся в БД, поэтому volume для персистентности обязателен. Настроенный VPS с n8n заменяет подписку на облачные сервисы автоматизации и не передаёт данные третьим сторонам.

Для простых задач достаточно cron: бэкап файлов, отправка отчётов, очистка временных директорий, синхронизация данных между сервисами.

Как выбрать свой сценарий и не перегрузить сервер

Примерные ориентиры по ресурсам под основные задачи:

•  Сайт или бот без тяжёлых фоновых задач: 1 vCPU, 1–2 ГБ RAM

•  API с базой данных: 2 vCPU, 2–4 ГБ RAM

•  Prometheus + Grafana: 2 vCPU, 2–4 ГБ RAM

•  n8n плюс несколько сценариев одновременно: 2–4 vCPU, 4–8 ГБ RAM

Несколько сценариев на одном VPS совместить возможно, но требования зависят от сложности проекта, выбранного стека, объёма трафика и числа одновременно работающих сервисов. Для простого сайта, небольшого бота и лёгкого мониторинга 2 ГБ RAM могут быть достаточны, если нет тяжёлых фоновых задач. Docker упрощает совмещение: каждый сервис в своём контейнере, порты не конфликтуют, ресурсы лимитируются. Постоянная загрузка CPU или RAM выше 80% может стать сигналом для апгрейда. Начните с минимального тарифа и расширяйте по мере роста – большинство провайдеров позволяют сделать это без пересоздания сервера.

Чек-лист: что настроить на VPS под любой сценарий

1.  SSH-ключи настроены, аутентификация по паролю отключена

2. Создан sudo-пользователь, работа от root прекращена

3. Система обновлена: sudo apt update && apt upgrade

4. UFW включён: открыты только нужные входящие порты, например SSH-порт, 80 и 443 для веб-сценариев

5. Swap настроен при RAM < 2 ГБ

6. Автоматические снапшоты или бэкапы настроены

7.  Домен привязан, HTTPS работает через Let’s Encrypt

8.  Базовый мониторинг: uptime и диск под контролем

VPS это не готовый продукт, а платформа для разных задач: сайта, бота, API, мониторинга или автоматизации. Начните с одного сценария, не пытайтесь запускать всё сразу. Сначала закройте базовую настройку из чек-листа: SSH-ключи, firewall, обновления, бэкапы и мониторинг. После этого разверните минимальную рабочую версию сервиса и расширяйте конфигурацию по мере роста нагрузки.

Облачный инстанс создан, SSH-доступ работает, и первое, что хочется сделать, это запустить приложение. Но новый сервер в этот момент уязвим: root-доступ может быть разрешён, часть пакетов требовать обновления, firewall ещё не настроен, мониторинга нет. Автоматические сканеры находят новые IP-адреса за минуты и начинают перебор паролей ещё до того, как вы откроете второй терминал.

Настройка облачных серверов перед нагрузкой – это четыре конкретных блока: сеть, пользователи и доступ, firewall, мониторинг. Каждый занимает от десяти минут до получаса. Пропустить любой – значит получить дыру в безопасности и эксплуатации.

Разберём все четыре блока по порядку на примере Ubuntu 22.04 LTS. Все команды воспроизводимы и проверены. Порядок шагов важен: каждый следующий опирается на предыдущий. Не запускайте приложение до настройки firewall: незащищённый VPS с открытым SSH быстро попадает под автоматический перебор паролей.

С чего начинается настройка облачного сервера?

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

Если обновление затронуло ядро – перезагрузите сервер. После перезагрузки убедитесь, что соединение восстановилось, и продолжайте.

Следующий шаг – проверить синхронизацию времени. Расхождение системных часов ломает TLS-рукопожатие, сбивает JWT-токены и делает логи бесполезными при сравнении событий с разных хостов. На Ubuntu 22.04 за это отвечает systemd-timesyncd. Проверьте его статус:

В строке NTP service должно стоять active. Если нет – включите вручную:

Также сразу посмотрите, что уже запущено на сервере, и сколько свободно дискового пространства. На минимальном образе Ubuntu 22.04 запущено около 25–30 системных сервисов. Если их заметно больше, образ уже преднастроен провайдером:

Если корневой раздел занят более чем на 80%, разберитесь с этим до любых дальнейших шагов: нехватка места ломает обновления пакетов, ротацию логов и запись временных файлов.

Настройка сети на облачном сервере

Начните с просмотра текущего состояния сетевых интерфейсов. Две команды дают полную картину: какие интерфейсы подняты, какие IP назначены и куда идёт маршрут по умолчанию.

В выводе ip a найдите интерфейс с публичным IP-адресом – обычно это ens3, ens4 или eth0, в зависимости от провайдера. Запомните его имя: оно понадобится в конфигурации netplan.

На Ubuntu 22.04 сетевые настройки управляются через netplan: конфигурационные файлы лежат в /etc/netplan/. Если провайдер использует cloud-init для автоматической конфигурации сети, в /etc/netplan/ уже может быть файл 50-cloud-init.yaml. Его можно редактировать, но изменения могут быть перезаписаны cloud-init при следующей перезагрузке или пересоздании конфигурации. Безопаснее создать отдельный файл с более высоким приоритетом, например 99-custom.yaml: числа в именах файлов определяют порядок применения, большее число применяется последним и переопределяет предыдущее.

Пример конфигурации со статическим IP (замените значения на реальные):

Директива addresses задаёт статический IP с маской. routes описывает маршрут по умолчанию – шлюз, через который идёт весь трафик. nameservers – DNS-серверы; при необходимости укажите серверы провайдера или вашего корпоративного резолвера.

Перед применением проверьте конфигурацию через netplan try: он применит настройки и автоматически откатит их через 120 секунд, если вы не подтвердите. Это страховка от потери соединения. Если всё в порядке – зафиксируйте:

Последний штрих – задать осмысленное имя хоста. Понятное имя упрощает навигацию в логах и мониторинге, особенно когда серверов несколько:

Диагностика сетевых проблем

Если после применения netplan что-то пошло не так, три команды помогут локализовать проблему:

Если ping проходит, а dig не разрешает имена – проблема в DNS. На Ubuntu 22.04 DNS управляется через systemd-resolved. Его состояние:

Если dig не установлен, установите пакет:

В выводе resolvectl смотрите секцию DNS Servers для каждого интерфейса. Если серверы не отображаются или стоит 127.0.0.53, убедитесь, что в файле netplan прописан раздел nameservers, и заново примените конфигурацию.

Команда ss -tulpn полезна не только при диагностике сети: её стоит запускать после каждого шага настройки, чтобы убедиться – ничего лишнего не появилось на открытых портах.

Управление пользователями и доступом (users)

Постоянно работать от root – плохая практика. Опечатка в пути к файлу под root может уничтожить данные без возможности отмены. Любая уязвимость в запущенном от root приложении даёт атакующему полный контроль над системой. При командной работе аудит затруднён: в логах нет разграничения между разными администраторами.

Создайте пользователя для повседневной работы. В Ubuntu удобнее использовать adduser: команда создаёт домашнюю директорию, настраивает оболочку и интерактивно запрашивает пароль.

Команда usermod -aG sudo <name> добавляет пользователя в группу sudo. На Ubuntu эта группа по умолчанию имеет право выполнять любые команды через sudo без изменения файла /etc/sudoers. Проверьте, что всё работает не закрывая текущую сессию root:

Для входа по SSH без пароля сгенерируйте ключ на локальной машине и скопируйте публичную часть на сервер. Тип ed25519 предпочтительнее rsa:

Если нужно добавить публичный ключ вручную – создайте структуру директорий самостоятельно. Разрешения важны: 700 на директорию, 600 на файл:

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

Безопасные настройки SSH

Настройка SSH на сервере сводится к нескольким директивам в /etc/ssh/sshd_config. Ключевой принцип: ограничить поверхность атаки. Откройте файл:

Перед отключением парольного входа не закрывайте текущую root-сессию и убедитесь, что вход по SSH-ключу работает в новом терминале. Если в конфиге или ключах есть ошибка, SSH-доступ можно потерять, и восстанавливать его придётся через консоль провайдера, VNC/KVM или rescue mode.

Внесите следующие изменения:

PermitRootLogin no закрывает наиболее атакуемый вектор: большинство автоматических сканеров перебирают именно root. PasswordAuthentication no убирает парольный вход полностью после этого единственным способом войти остаются SSH-ключи. AllowUsers deploy добавляет дополнительный слой: даже если на сервере появятся другие пользователи, по SSH они войти не смогут.

Директива AllowUsers особенно полезна при командной работе: она задаёт явный белый список тех, кто может войти по SSH. Новый пользователь, не включённый в список, не получит доступ даже с корректным ключом.

Перед перезапуском проверьте синтаксис конфига, ошибка в директиве заблокирует вас при работающем соединении:

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

Дополнительно: смена стандартного порта 22 на нестандартный снижает количество автоматических сканирований и шум в логах. Если решите сменить, сначала откройте новый порт в UFW, затем измените Port в конфиге и перезапустите sshd, не наоборот.

Настройка firewall: UFW и iptables

UFW – стандартный инструмент управления firewall на Ubuntu. Он даёт простой интерфейс для настройки правил, а конкретный backend зависит от версии Ubuntu и конфигурации системы: это может быть iptables-совместимый слой или nftables. На новом сервере UFW установлен, но часто не активирован.

Настройка облачных серверов без активного firewall оставляет все порты открытыми. Порядок имеет значение: сначала разрешить SSH, потом включать UFW, иначе заблокируете собственное соединение:

Если SSH настроен на нестандартный порт, замените 22 на него. Правило ufw status verbose покажет активные разрешения и политику по умолчанию – полезно сверить сразу после включения.

Для отладки сначала используйте вывод UFW:

Если нужно посмотреть низкоуровневые правила, используйте инструмент, который соответствует backend системы:

или:

На Ubuntu 22.04 UFW может работать через iptables-совместимый backend или nftables. Поэтому не стоит ориентироваться только на одну цепочку INPUT: фактическое расположение правил зависит от backend и конфигурации системы.

Для автоматической блокировки IP-адресов после нескольких неудачных попыток входа установите fail2ban:

Создайте файл пользовательских настроек /etc/fail2ban/jail.local. Редактировать jail.conf напрямую не стоит – он перезаписывается при обновлении пакета:

При таких настройках IP блокируется на час после пяти неудачных попыток входа за десять минут. Перезапустите сервис и проверьте статус jail:

В выводе Currently banned покажет количество активных блокировок. Разбанить конкретный IP можно командой fail2ban-client set sshd unbanip <IP>. Кроме SSH, fail2ban поддерживает джейлы для nginx, apache2 и postfix. Они конфигурируются аналогично, добавлением отдельных секций в jail.local.

Мониторинг облачного сервера

Мониторинг сервера Linux без агентов начинается со встроенных инструментов. Для быстрой диагностики их вполне хватает:

Для постоянного мониторинга с метриками и алертами нужен агент. Выбор зависит от контекста: если в инфраструктуре уже есть Prometheus, оптимален node_exporter – он экспортирует более 800 метрик ОС с минимальным потреблением ресурсов (около 20–50 MB RAM):

Агент слушает на порту 9100 и отдаёт метрики в формате Prometheus по адресу http://<IP>:9100/metrics. Добавьте этот адрес как scrape target в конфигурацию Prometheus, и метрики появятся в Grafana. Не открывайте порт 9100 наружу: ограничьте доступ через security group, UFW или приватную сеть Prometheus.

Если Prometheus ещё нет – Netdata даёт готовый интерактивный дашборд из коробки, без дополнительной инфраструктуры:

Netdata слушает на порту 19999. Настройте SSH-туннель для разового просмотра или nginx с basic auth для постоянного доступа. Netdata потребляет от 100 MB RAM, на VPS с 1 GB это существенная разница по сравнению с node_exporter.

Алерты настраиваются поверх метрик. Для node_exporter используйте Prometheus Alertmanager: правила на PromQL, уведомления в Slack, email или PagerDuty. Для Netdata встроена собственная система уведомлений – настройте её в /etc/netdata/health_alarm_notify.conf. На практике для старта хватает трёх порогов: CPU load выше числа vCPU, диск выше 85%, список упавших сервисов непуст.

Что мониторить в первую очередь

На только что настроенном сервере важны шесть базовых показателей:

CPU load average – если значение устойчиво превышает количество vCPU в течение 5–10 минут, сервер перегружен. htop или uptime показывают три скользящих средних: за 1, 5 и 15 минут.

Память – при использовании свыше 85% система начинает активно использовать swap, что резко увеличивает latency. Для веб-серверов и баз данных это ощутимо. Контролируется через free -h.

Диск – заполненность свыше 80% блокирует запись логов, временных файлов и данных приложений. Дополнительно следите за iostat (из пакета sysstat) – высокий await при умеренной нагрузке указывает на проблемы с хранилищем.

Failed services – systemctl --failed выводит список упавших юнитов. Перед выводом в продакшен этот список должен быть пустым.

Auth log – journalctl -u ssh --since "1 hour ago" покажет активность после настройки fail2ban. Строки Failed password могут продолжать появляться до бана или с других IP-адресов. Важнее проверить, что fail2ban видит попытки входа и добавляет нарушителей в jail; строки Accepted publickey должны соответствовать вашим успешным входам.

Открытые порты – ss -tulpn один раз после каждого изменения конфигурации. Всё, что слушает наружу, должно быть в явном белом списке UFW.

Чек-лист финальной проверки

Пройдитесь по списку перед открытием сервера под рабочий трафик:

•  Непривилегированный пользователь создан, добавлен в sudo

• Перед отключением парольного входа проверен вход по SSH-ключу в новом терминале

• PasswordAuthentication no и PermitRootLogin no прописаны в sshd_config

• UFW включён: ufw status verbose показывает только нужные порты

• fail2ban запущен: fail2ban-client status sshd показывает активный jail

• Пакеты обновлены: apt upgrade -y выполнен, при обновлении ядра – перезагрузка

• NTP активен: timedatectl показывает NTP service: active

• Мониторинг-агент запущен и метрики доступны

• Бэкапы настроены через панель провайдера или отдельный инструмент

• systemctl --failed возвращает пустой список

• Имя хоста и /etc/hosts настроены корректно

Четыре блока: сеть, пользователи, firewall, мониторинг – это минимальная конфигурация, без которой облачный сервер не готов к продакшену. Пропуск любого из этих шагов рано или поздно даёт о себе знать: либо взломом, либо аварией без видимой причины, либо часами поиска проблемы в логах.

Сохраните этот гайд и пройдитесь по нему при следующем деплое нового инстанса. В блоге Aeza регулярно выходят материалы по администрированию и безопасности серверов – подпишитесь, чтобы не пропускать NETTOWN5 обновления.

• Если средняя зарплата меньше 8000 то мы хотим видеть её зеленым светом

• Если средняя зарплата равна или больше 10000 то мы хотим увидеть красный цвет

• Также иметь возможность выйти за границы 10000 (до 12000) на тот случай если значение оказалось больше максимального.

Пишем запрос для получения всех зарплат

Преобразуем данные используя Transform Data

(чисто для практики, среднюю зарплату мы могли получить и запросом):

1. Выбираем Transform Data => Reduce

2. Mode: Reduce fields

3. Calculations = Mean (среднее значение).

Выбираем график Gauge

Получаем следующий график (и это не то, что мы хотим):

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

Thresholds

• Указать Thresholds mode - Absoulte

• Нажать Add threshould указать значение 10000 и отметить красным

• Нажать Add threshould указать значение 8000 и отметить желтым

Standart Options

• Указать Min - 0

• Указать Max - 12000

Результатом будет вот такая картина:

Визуализируем данные на карте - GeoMap

Для данного графика в базе нет достаточно данных, поэтому координаты мы сгенерируем сами прямо внутри запроса. Карта богата возможностями, они описаны тут

Запрос длинный поэтому я просто прикреплю его вот по этой ссылке. Если запустить этот запрос и посмотреть данные то получится следующая картина. В нашем случае нам нужны были колонки latitude/longitude те ширина и долгота.

Слегка преобразуем карту:

• В настройках Map Layers выберем Tax Label Field - Employee Name

• Map view - view: North America, zoom - 4.5

Результатом будет карта:

Строим сколько человек работает в каждом департаменте (точнее городе где он расположен) Используем график Stat.

Сначала пишем запрос:

Теперь выбираем график - Stat и правим настройки

• Value options: fields - employee_count

• Stat styles: color mode - background gradient

В результате получаем вот такую картину:

Вместо заключения.

Фокус этой статьи был на работе с графиками. Графана во многом заточена под снятие и визуализацию данных в реальном времени с логов и программ. Если тема зайдет я раскрою больше возможностей. Всем кому интересна разработка добро пожаловать в мой телеграм канал.

Как сделать так чтобы график отобразился?

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

Начнем с простого - Bar Chart.

Построим график зарплат 50 сотрудников по возрастанию с минимальной зп в 10к. Тут нашей целью будет как минимум одна строковая колонка (мы возьмем имя она будет роль играть оси X) и зарплата (будет играть роль Y, хотя мы можем указать не только зарплату и график отсроит несколько вертикалей).

Сначала возьмем запрос ниже (он не отсортирован намеренно):

Теперь построим график, выбрав в списке графиков (сверху справа) Bar Chart:

Чтобы понять что происходит давайте глянем в данные выбрав Table View:

Теперь чтобы сделать график читаемым, приведем его к нужному типу а для этого надо:

• Скрыть все колонки кроме зарплаты и имени

• Отфильтровать зарплаты меньше 10к

• Отсортировать по росту зарплат от минимальной к максимальной

Transform Data - Одна из ключевых возможностей в Графане.

Для обработки данных есть как минимум два способа

• Обработать данные внутри запроса и выделить нужные колонки, добавить сортировку итд (И это применимо для всех языков запросов вроде LogQL, PromQL и остальным)

• Использовать интерфейс Transform Data который позволяет сделать тоже самое (хотя тут я не уверен, думаю первый вариант более гибок) но используя веб интерфейс, кнопки и поля ввода.

Transform Data это конструктор, позволяющий сделать различные преобразования, ниже лишь часть из них:

• Organize fields - скрыть колонки, переименовать их имена.

• Sort By - отсортировать

• Extract fields - "вытащить" поля из данных (например поля из json объекта)

• Filter by name/values - отфильровать по имени, данным

• Convert field type - сконвертировать поля (например строку в дату)

• Limit - ограничить количество записей

Теперь воспользуемся этой возможностью и:

• Скроем все поля кроме имени и зарплаты (Organize fields)

• Отсортируем по зарплате (Sort by)

• Исключим все зарплаты ниже 10 тысяч (Filter data by values)

Bar Chart автоматически построит график тк у него в наличии будет 1 строковая колонка и 1 численная. Это можно заметить по символам A (строковый) и +-х= (число):

И так вот результативный график:

Изобразим количество сотрудников в каждом департаменте. Pie Chart график.

Для этого ипользуем следующий запрос:

В данном случае группировку данных я сделал именно через запрос тк посчитал это наиболее простым подходом. Изначально график не может "понять" как его построить, для этого нужно зайти в настройки графика справа и выбрать:

• Value options - All Values

• Pie Chart - Name, Value

• Legend - Legend values - Value, Percent, Placement - Right, Mode - Table

Результатом будет график:

Строим график зависимостей. Сотрудник - Начальник. Node Graph

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

• source - номер вершины родителя

• target - номер вершины наследника

• id - номер ребра

• subtitle/title/secondarystat - опциональные данные для визуализации графа.

Строим запрос:

Результатом работы данного запроса получится таблица, где source будет имя менеджера и target имя подчиненного. Также дополнительным данными укажем зарплату.

Результатом будет вот такой граф. График интерактивный и наводя на какую либо ноду можно увидеть зависимости.

Думаю для второй части достаточно, в третьей части я опубликую как построить оставшиеся три графика. Кому интересна разработка на Java, добро пожаловать в мою группу в телеграмме.

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

Запускаем Grafana в докере.

Используя докер мы можем запустить графану, чтобы это сделать нужно:

• Создать файл docker-compose.yaml (содержание будет ниже)

• Запустить команду docker-compose up -d

Содержание файла доступно по этой ссылке.

Welcome to Grafana.

Через несколько секунд на вашем сервере на 3000 порту будет доступна Grafana. На старте она попросит ввести имя и пароль, введите admin/admin. На первом входе будет необходимо сменить admin пароль. Главная страница будет выглядеть примерно вот так:

Прежде чем работать с графаной нам нужны данные. Добавляем DataSource.

Один из ключевых моментов - настройка подключения данных. Есть множество вариантов датасурсов (источников данных) а также соответствующего языка запросов. Например наиболее популярными являются:

• Prometheus - датасурс для мониторинга метрик с языком PromQL.

• Loki - датурс для мониторинга логов с языком LogQL

• InfluxDb - датасурс для хранения временных рядов (хотя она не ограничена этим) с языком InfluxQl.

• MySQL/PostgreSQL/MSSQL/.. - датасурсы для работы с реляционными базами данных, идет вместе со знакомым многим SQL.

• Список датасурсов огромен, ниже я вставлю картинку с опциями.

Подключаем Postgres DataSource.

Для того чтобы не нагружать читателя и сфокусироваться на построении графиков мы подключим самый простой вариант - Postgres базу данных с относительно популярной схемой - сотрудники.

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

Для старта базы данных с нужными данными нужно:

• Создать файл schema.sql и скопировать туда вот эти строки

• Создать еще один файл docker-compose.yaml (чтобы не было конфликтов можно создать его в отдельной папке вместе с schema.sql и лучше поменять пароль YOUR_COMPLEX_PASSWORD на что то более серьезное).

• Запустить команду docker-compose up -d

Интегрируем нашу запущенную базу данных добавляя Postgres DataSource.

Для добавления базы данных нужно нажать Home => Connections => Data sources и затем нажать Add new data source

После выбора PostgreSQL введите следующие данные как показано ниже (только подставьте IP и пароль который вы выбрали ранее, если ничего не меняли то YOUR_COMPLEX_PASSWORD )

Строим первый график. Подготовка.

Перед построением графика нужно добавить его в Dashboards. Для этого нажимаем слева Dashboards => New (кнопка справа) => New Dashboard => Add visualization и выбираем созданный ранее PostgresSQL датасурс (ну или как вы его назвали)

Готовим данные для графика.

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

На панели снизу нужно еще раз выбрать PostgresSQL и тогда графана предложит конструктор запросов но честно для SQL запросов мне лично удобнее просто писать текстовый запрос. Чтобы сменить конструктор на текст сменитe Builder => Code (справа сверху)

Последнее замечание перед написанием графиков.

В нашем случае мы используем SQL язык для обработки данных и он достаточен прост для подготовки данных. В случае интеграции Prometheus, Loki подготовка во многом требует знания языка запросов PromQL и LogQL и они не так очевидны для новичка (но довольно гибки).

Пишем первый запрос - график текущих зарплат и даты трудоустройства.

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

после этого нужно нажать Run Query. Также можно нажать сверху справа на поле ввода графиков и затем на кнопку Suggestions. Тогда графана автоматически предложит возможные варианты графиков:

Думаю для первой части будет достаточно. Во второй части подробнее рассмотрим работу с данными и как именно "подгонять" данные под нужные форматы для графиков.

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

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

В данном воркшопе мы настроим и установим мониторинг Prometheus и Grafana с помощью Ansible. Информации много и подана она в очень сжатом виде. #linux #ansible #prometheus #grafana #node_exporter

Больше видео и постов в тг канале: https://t.me/devops_spb_ru

Примеры кода из видео: https://github.com/DevOps-spb-org/monitoring-webinar