💻 А вот и заключительная часть серии постов про ключевые подходы к мониторингу SRE.

Four Golden Signals — это методология, которая позволяет установить базовый уровень прозрачности в мониторинге ваших систем.

🔍 Концепцию «Четырёх золотых сигналов» разработала команда Google SRE. Первое упоминание о Four Golden Signals содержится в их книге “Site Reliability Engineering”.

Эти метрики были созданы для связки классического мониторинга (показывающего, КОГДА возникла проблема) и наблюдаемости (англ. observability; показывающей, ПОЧЕМУ возникла проблема).

Подход Four Golden Signals подразумевает следующие метрики:

• Latency (задержка): время, необходимое для обслуживания запроса.
• Errors (ошибки): количество неудачных запросов в секунду.
• Traffic (трафик): количество пользователей или транзакций, проходящих через сервис.
• Saturation (насыщенность): загруженность системы.

Из полезного: здесь можно прочитать все три книги о SRE, которые написала команда Google.

#DevOps #SRE #мониторинг

🔍 Формируем SLO: пять советов от команды Google SRE

SLO (цель уровня обслуживания) — это соглашение в рамках SLA о конкретном показателе, который определяет качество обслуживания, предоставляемого конкретным сервисом или системой. Соглашения SLO формируют ожидания клиента и показывают команде DevOps, на какие показатели она должна ориентироваться и каких целей нужно достичь. Например, SLO может определять минимальное время доступности сервиса или максимальное время ответа на запрос.

1. Не выбирайте цель, основываясь только на текущих показателях

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

2. Будьте проще

Сложные расчёты SLI могут скрыть изменения в производительности системы и усложнят поиск причины возникшей проблемы.

3. Избегайте абсолюта

Заманчиво иметь систему, которая может принимать неограниченно растущую нагрузку без увеличения задержки. Но это требование нереально. Система, которая стремится к таким идеалам, вероятно, потребует много времени и ресурсов на проектирование и создание, будет дорогой в эксплуатации… и, скорее всего, окажется неоправданно лучше той, которую пользователи уже были бы рады иметь.

4. Используйте как можно меньше SLO

Выберите достаточное количество SLO, чтобы обеспечить хорошее покрытие атрибутов системы. Защищайте выбранные вами SLO: если вы никогда не можете выиграть спор о приоритете конкретной SLO, вероятно, не стоит рассматривать эту SLO. Однако не все атрибуты системы можно преобразовать в SLO: трудно подсчитать, например, уровень "user delight" с помощью SLO.

5. Не торопитесь достичь совершенства

Лучше начать с плавающей цели, которую со временем можно сделать более точной, чем выбрать слишком строгую цель, а потом её ослабить в случае, если вы обнаружите, что она не достижима. Уточните SLO тогда, когда ваша команда узнает больше о поведении системы под нагрузкой.

#DevOps #SRE #Google

Авто-ресурсы в Kubernetes, Pulumi NEO и Google MCP: инфраструктура на автопилоте

🔔Всем срединедельный DevOps! Обсудим свежие апдейты авто-выделения ресурсов в K8s и инструментов GitOps. Полезно тем, кто хочет меньше крутить кластеры вручную.

🟡 Kubernetes 1.34 и динамическое выделение ресурсов
В версии Kubernetes 1.34 кластер сам подбирает ресурсы GPU, CPU и I/O под конкретные задачи — без необходимости заранее прописывать лимиты в PodSpec. Теперь через API можно запрашивать устройства с нужными параметрами (тип GPU, версия CUDA, объём памяти) — и Kubernetes подберёт подходящее оборудование.
Это снижает долю простаивающих ресурсов, особенно при ML- и AI-нагрузках, где требования к железу меняются на лету.

⚫️ Pulumi NEO упрощает GitOps
Pulumi NEO читает IaC-код, сам формирует план изменений инфраструктуры, проверяет его через Policy as Code и применяет. Он понимает зависимости, окружения и может откатывать изменения без ручного kubectl apply. Полезен, когда GitOps-потоки разрастаются, а ручное управление окружениями тормозит релизы.

🟡 Google MCP для баз данных
Google представил MCP Toolbox — серверный набор инструментов, который реализует MCP для безопасной автоматизации доступа к базам данных. SQL-операции задаются декларативно в tools.yaml , а MCP управляет подключениями, пулами и правами доступа. Поддерживает Cloud SQL, AlloyDB, Spanner, PostgreSQL и MySQL. Система следит за нагрузкой, масштабирует кластеры и перестраивает схемы без ручного вмешательства DBA. Ещё один шаг к инфраструктуре, где всё крутится само.

#DevOps #Kubernetes #SRE

Как развернуть 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