Что нового в релизах и инструментах: Vitess, Copilot и Monarch

🚀Традиционно публикуем срединедельный дайджест новостей, чтобы оставаться в курсе важных обновлений.

⚫️ Vitess 23.0.0 — операционная наблюдаемость и стабильное масштабирование
Команда Vitess представила новую основную версию популярного CNCF-проекта для масштабируемых MySQL-кластеров. Релиз Vitess 23.0.0 продолжает линию версии 22 и направлен на упрощение развертывания, повышение стабильности и наблюдаемости в больших инфраструктурах: переход на MySQL 8.4.6; TransactionsProcessed для VTGate, SkippedRecoveries для VTOrc. Подробности обновления читайте в статье блога CNCF.

🟡 GitHub Copilot CLI: ускорение работы с репозиториями
В Copilot добавлена поддержка CLI с доступом к репозиториям, возможностью редактировать файлы, запускать команды и интеграцией с GitHub через учётную запись. Параллельно представлены Copilot Spaces Copilot Spaces — контекстные «пространства» с документацией, примерами и задачами, которые дают агенту релевантный контекст для команды и ускоряют онбординг; CLI и Spaces поддерживают MCP-серверы и смену модели. Всё про GitHub Copilot CLI и Spaces здесь.

⚫️ PyTorch — Monarch упрощает разработку распределённых ML-программ
PyTorch представила Monarch — фреймворк для распределённого программирования, который позволяет работать с целыми кластерами GPU. Monarch упрощает разработку распределённых ML-программ: код остаётся похожим на обычный Python/PyTorch-скрипт, при этом масштабируется на тысячи GPU, облегчая написание распределённых алгоритмов, обработку сбоев и управление ресурсами. Читайте статью здесь.

Стабильных кластеров и эффективного онбординга команды!🤝

#Vitess #Observability #Copilot

Логирование и мониторинг — топ-3 инструмента для DevOps в 2025

🗣Несложно представить ситуацию: трафик на пике, API выдает 500-е ошибки. Вы заходите на сервер по SSH, суматошно переходите из директории в директорию, пытаетесь разобраться в веренице логов микросервисов и в конце находите виновника. Спустя время сбой устранили, но вопрос остался – «неужели нельзя проще?». Отвечаем – можно, с инструментами observability.

🚀Топ-3 инструмента для логирования и мониторинга:

1.Grafana Loki
Плюсы:
• Минимальные расходы: Loki не индексирует содержимое логов, используя только метки (labels) — как в Prometheus. Это снижает потребление CPU, RAM и дискового пространства.
• Тесная интеграция с Prometheus и Grafana: Если вы уже используете Grafana или Prometheus, например в рамках KubePrometheusStack, то вам может быть полезна возможность просматривать логи там же, где и метрики.
• Простота развёртывания и масштабирования: monolithic mode идеально подходит для старта, так как объединяет в рамках одно бинарного файла все компоненты Loki. Но как только вам его не хватает, советуем перейти на микросервисный режим, разделив Distributor, Ingester, Querier и Compactor на отдельные сервисы
• Гибкий язык запросов: LogQL похож на PromQL, что позволяет проводить агрегаций и подсчёт ошибок за период времени, а затем выводить панели с количеством ошибок, рейтами и распределениями в Grafana.
💬Что учесть
Однако, Loki разработан для фильтрации логов на основе меток и регулярных выражений, а не для глубокого полнотекстового поиска и не позволяет справляться со сложным анализом логов.

2. Elastic Stack
Плюсы:
• Настройка на всех уровнях: от сбора данных с помощью Logstash или Beats до запросов и дашбордов в Kibana — почти все можно настроить
• Мощный поиск и аналитика: Elasticsearch обеспечивает быстрый полнотекстовый поиск и агрегацию в больших масштабах
• Работа в реальном времени: данные индексируются и становятся доступны для поиска почти мгновенно
Гибкость индексации и управления данными: в Elasticsearch есть возможность настраивать ILM (Index Lifecycle Management) - автоматически перемещать "тёплые" и "холодные" данные между нодами, удалять старые индексы по политике.
💬Что учесть:
Операционные затраты могут быть высокими, а расходы на облачные услуги быстро растут при производственном масштабе.

3. OpenSearch
Плюсы:
• Полный open-source: OpenSearch является решением с открытым кодом без лицензионных рисков.
• Гибкость в сборе и анализе логов: поддерживает SQL и PPL, а также обладает встроенным observability-стеком
• Alerting-plugin — в отличие от ElasticSearch, OpenSearch из коробки позволяет строить гибкие триггеры и уведомления.
• Активное сообщество и поддержка AWS: он поддерживается AWS, Capital One, Red Hat, SAP и другими.

👩‍💻 Подборки репозиториев:
https://github.com/grafana/grafana – интеграция с Grafana с дашбордами и алертингом;
https://github.com/grafana/loki – репозиторий для агрегации логов
https://github.com/elastic – у Elastic на GitHub свыше 800 репозиториев, включая ядро Elasticsearch и множество интеграций и плагинов.

#DevOps #Observability #Grafana #Elastic

Как развернуть Prometheus через systemd и запустить базовый мониторинг
👨‍💻Возвращаемся с инструментами по observability и SRE. Prometheus – это система мониторинга с открытым исходным кодом, которую можно использовать для сбора и отслеживания различных метрик из экспортеров в Time Series Database (TSDB). Сегодня разберем, как настроить и запустить Prometheus и управлять через systemd на сервере Ubuntu или Debian. Для инженеров single-node установка позволяет использовать Prometheus как базовую систему мониторинга без лишних инфраструктурных настроек.

⏺Шаг 1. Подготовка пользователя и загрузка Prometheus
Создаем отдельного пользователя для Prometheus:

sudo useradd -M -U prometheus

Выбираем версию для вашей системы и скачиваем бинарь:

wget https://github.com/prometheus/prometheus/releases/download/v2.40.0-rc.0/prometheus-2.40.0-rc.0.linux-amd64.tar.gz
tar -xzvf prometheus-2.40.0-rc.0.linux-amd64.tar.gz
sudo mv prometheus-2.40.0-rc.0.linux-amd64 /opt/prometheus

Меняем права на папку, чтобы Prometheus мог работать безопасно:

sudo chown prometheus:prometheus -R /opt/prometheus

⏺Шаг 2. Настройка systemd-сервиса
Создаем файл /etc/systemd/system/prometheus.service с таким содержимым:

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Restart=on-failure
ExecStart=/opt/prometheus/prometheus \
  --config.file=/opt/prometheus/prometheus.yml \
  --storage.tsdb.path=/opt/prometheus/data \
  --storage.tsdb.retention.time=30d

[Install]
WantedBy=multi-user.target

⏺Шаг 3. Запуск и управление Prometheus
Активируем сервис и запускаем его:

sudo systemctl daemon-reload

sudo systemctl start prometheus.service

sudo systemctl enable prometheus.service



Проверяем статус и логи сервиса:

sudo systemctl status prometheus.service

sudo journalctl -u prometheus.service -f

Теперь Prometheus работает как системный сервис, собирает метрики и готов к подключению экспортеров.

⏺Шаг 4. Дальнейшие шаги
⁃ Настройка AlertManager для уведомлений.
⁃ Подключение экспортеров для серверов, контейнеров и приложений.
⁃ Использование Grafana для визуализации метрик.

🗂Подробнее о настройке алертов: Prometheus Alerting

Вывод: такой минимальный setup позволяет быстро поднять Prometheus для тестов и PoC, понять, как работает TSDB, и интегрировать систему мониторинга в DevOps-процессы.

#sre #observability #prometheus #monitoring #devops