Метрики? Метрики! Метрики...Или введение в Prometheus и Monitoring

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

В том числе это нужно и нам - разработчикам. Для поддержки высокого уровня сервиса и построения надежных системм важно понимать как функционирует написанный нами код и железка на которой мы его развернули. А понимание можно извлечь только собирая информацию и вариантов у нас обычно 3 - логи, метрики, трейсы. Если с логами все интуитивно понятно - это фиксация фактов / событий в нашей системе. Их легко начать собирать и пользоваться ими, то с метриками дела обстоят веселее и стартануть в их сборе также быстро как с логами не получится, про трейсы вообще молчу.

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

📖Шаг №1 - Нескучная теория

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

👨‍🔬Шаг №2 - Закрепляем теорию

Закрепить изученное в статье на практике можно с помочью https://demo.promlens.com. Это интерактивный визуализатор метрик по запросу. С возможностью разобрать запрос на этапы выполнения и получить пояснения. Можно засунуть в него свой эндпоинт для работы с метриками, а можно работать с источником по умолчанию https://demo.promlens.com/metrics

Примеры метрик которые можно быстро засунуть в него и посмотреть результат доступен в шпаргалке https://promlabs.com/promql-cheat-sheet/


🔬Шаг №3 - Экспериментируем на своей машине

После быстрого освоения построения визуализаций и готовых метрик в браузере можно переходить поближе к коду и практическому применению. Как пример - можно взять репозиторий https://github.com/ContainerSolutions/k8s-deployment-strategies и посмотреть как работают в связке K8s + Prometheus + Grafana. Как происходит экспорт метрик, увидеть на графиках разницу стратегий деплоя приложения.

Задача со звездочкой - добавить в свое приложение сбор стандартных runtime метрик. Гайд для Golang.

🤔Шаг №4 - А какие метрики мне нужны?

После того как мы овладели инструментом может возникнуть соблазн начать собирать все что только можно. Или наоборот ступор от того что все ещё непонятно - а что собирать то? И у сообщества есть ответ на этот вопрос:
- R.E.D. Metrics: Rate, Errors, and Duration
- U.S.E. Metrics: Utilization, Saturation, and Errors
- The “Four Golden Signals” Metrics: Latency, Traffic, Errors, and Saturation

Эти метрики станут надежным фундаментом для вашей системы мониторинга.

------

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

Road to Highload

Сегодня пост посвящен материалам команды Яндекс 360 о том как развивались их системы со временем и какие челленджи были на пути к желаемому всеми инженерами Highload.

Из прошлых постов вы наверняка заметили, что мне обычно интересно не только читать про классные алгоритмы и модные штучки, но и искать ответы на вопросы "Зачем? Почему именно так?" Ребята декларируют намерение поделиться собственным опытом и дать те самые ответы, а не только "навалить базы". Поэтому я решил посмотреть, что же там внутри.

В проекте 5 выпусков. Покрывают фундамент классического серверного приложения, а именно:

- Сбор требований и его влияние на архитектуру системы, ее надежность и масштабируемость.
- Проектирование API. Почему это важно, и чем чреваты ошибки. Мне этот выпуск отдельно запал в сердечко, потому что в нем было и про breaking changes и обратную совместимость, вещи с которыми я намучался😁
- Визуализация верхнеуровневой архитектуры как инструмент коммуникации и способ storytelling'a о системе.
- Как справляться с ростом объема данных. Индексы, согласованность. Разбор трейдоффов.
- Интеграции. Как подключать к своей системе внешние источники данных, челленжи и разбор популярных проблем.

Я отсмотрел проект целиком и могу сказать - материал достойный. Все о чем ребята рассказали это не что-то на эльфийском, а то что имеет место быть в больших системах. В общем - рекомендую к просмотру. Для начинающих прям 100%.

Расскажите в комментариях ваши впечатления от просмотра, а также делитесь своими любимыми материалами😊

🚀 Demystifying memory management in modern programming languages

Хочу с вами поделиться циклом статей, который мне пригодился во времена переката из Ruby в Go. Мне требовалось заново вспоминать всякие low level детали из-за специфики проекта и высокой нагрузки.

Цикл о том как происходит управление памятью в языках программирования. Первый пост разбирает основы и дает ответы на общие вопросы - RAM, Stack, Heap, Malloc / Realloc. Дальше автор начинает разбирать популярные рантаймы (JVM, V8) и ЯП (Golang, Rust).

Я такое люблю - когда коротко и понятным языком рассказывают базу.

https://deepu.tech/memory-management-in-programming/

🚨 Kubernetes v1.36 официально выходит 22 апреля 2026 года.

Вот 6 ключевых обновлений, к которым стоит подготовить свои кластеры: 👇

1⃣ HPA Scale-to-Zero (включено по умолчанию)
- Функция HPAScaleToZero выходит из alpha после того, как находилась там с версии v1.16.
- Теперь можно безопасно указывать minReplicas: 0.
- Это серьёзно снижает расходы для неактивных staging-окружений и batch-пайплайнов.

2⃣ Эфемерные Service Account токены для pull образов
- Заменяют долгоживущие статические секреты для доступа к приватным registry.
- Используются краткоживущие токены Service Account с автоматической ротацией.
- Учетные данные теперь привязаны к идентичности конкретного pod, что значительно снижает риск утечек.

3⃣ Более умный выбор pod’ов в HPA
- Исправлена проблема, когда HPA считал метрики устаревших или orphan-pod’ов.
- Новая логика учитывает только pod’ы, управляемые целевой workload.
- Автоскейлинг становится более предсказуемым и стабильным.

4⃣ Удаление режима kube-proxy IPVS
- Режим IPVS был deprecated в v1.35 и теперь будет полностью удалён.
- Пора переходить на iptables (backend nftables) или eBPF-proxy (например Cilium).
- Лучше запланировать миграцию заранее, чтобы обновление не сломало сетевой стек.

5⃣ Завершение эпохи Ingress NGINX и переход на Gateway API
- Сообщество постепенно отказывается от Ingress NGINX.
- Gateway API становится новым стандартом управления трафиком.
- Появляется нативная маршрутизация между namespace без набора кастомных annotations.

6⃣ Переход на containerd 2.x
- Версия v1.36, вероятно, станет последней, поддерживающей старые версии containerd (например **1.6.x**).
- Экосистема Kubernetes полностью выравнивается под containerd 2.x.
- Обновите runtime заранее, чтобы избежать breaking changes в следующих релизах.

https://habr.com/ru/news/1010702/ да что же это такое! Еще и ИИ нам работу увеличил! Доколе!

Если серьезно, то я не уверен что в эти проценты не входит adoption, но тут надо, конечно, глубоко погружаться в методику исследования

Проверяем навыки DevOps-инженеров. Проверим ваши?

Привет, это KTS. Мы создаем цифровые продукты и ведём блог на Хабре, где делимся практикой из проектов. Блогу исполнилось 5 лет, и мы решили отметить эту дату челленджем для девопсов. Победителям дарим футболки с нашим фирменным принтом — Котзиллой (как Годзилла, только кот).

В чем суть головоломки: вы получите доступ к тестовому стенду с Kubernetes-кластером, ArgoCD и GitLab с Helm-чартом. В ArgoCD добавлено приложение, но оно не деплоится.

Ваша задача — разобраться, что пошло не так, исправить конфигурацию и довести деплой до зелёного статуса.

Десять самых быстрых участников получат футболки. Прям СДЭКом отправим 📦

Начать можно по ссылке.

Итоги через неделю, 26 марта в 19:00.

Distributed tracing: от 100% error rate до первопричины за 60 секунд

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

Репыч Uptrace на Гитхабе

@monitorim_it

Недавно думал, как может выглядеть действительно нормальное внедрение AI в работе компании и кажется что тут напрашивается целая команда AIOps, которая этим должна заниматься на постоянной основе, в список обязанностей которой должно входить:
1. Выработка единой модели-стандарта использования моделей и агентов в компании, куда входит:
- определение точного списка моделей по ролям-скилам в компании
- определение списка моделей-ролей для конкретных продуктов и команд в компании
- определение списка поддерживаемых инструментов - агентов, IDE (или плагинов для IDE)
- определение списка пресетов для моделей для разного рода технических специалистов
- пайплайны для обновления скилов/пресетов у инженеров
2. Мониторинг использования:
- дашборды с задачами, утилизацией моделей, бюджетом токенов и тд. Алертинг там где это необходимо
- мониторинг доступности моделей (особенно внешних)
- мониторинг эффективности - какие модели более, а какие менее эффективны и для каких задач (тут можно внедрить инструменты на этапе код ревью генерированного кода и сбор ОС от инженеров)
- мониторинг всех запросов (в том числе мониторинг использования моделей не по назначению или без соблюдения принятых практик или использование сторонних моделей, не принятых в компании в п.1)
3. Сопровождение:
- наблюдение за тем, чтобы сохранялся уровень эффективности и не было деградации, тюнинг скилов/пресетов, а если необходимо, то и моделей (в случае использования локальных)
- бенчмаркинг новых моделей и создание ворклоада для этого бенчмаркинга, выявление ключевых параметров и сравнение моделей по ним
- оценка финансовой эффективности (тарифы моделей и их потребление)
- обработка запросов от "внешних заказчиков" - добавление новых скилов/пресетов, изменение старых
- маркетплейс промптов с удобным поиском
- работа по внедрению практик для команд - презентация решений, удобный шэринг практик, консультации по использованию

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

#орижиналконтент

А вот и опыт какой-то. Ожидаемо, конечно, что бигтех тут уже что-то делает

Ну вот и комьюнити пытается само выкручиваться

SkillsБД 😂

В нашем AI чатике друзей ребята накинули а чего нет такого аналога в РФ как skills.sh?

Где будут собранны скиллы вокруг наших РФ сервисов для любых агентов в знакомом формате установки для кодинг агентов

Представляю вашему вниманию https://skillsbd.ru/

Навыки для работы с Яндекс, Битрикс, 1С и другими российскими сервисами. Устанавливайте одной командой, делитесь с RU-комьюнити

Есть простые проверки безопасноти (буду развивать сканнеры)

Есть скиллл find-skills который упаковывает всю бд в мощный поисковик

Модерация новых навыков ручная (будем так же автоматизировать)

На сегодня залил топ 3 скилла
1C
Bittix24
Яндекс сервисов

Любой может зарегистрироваться через гитхаб и тут же залить свой скилл через гитхаб и формат claude-skill

Чем отличается и будет отличаться

С этого канала стартует комьюинити вокруг данной БД + я сам лично буду продолжать поддерживать ряд навыков + уже залил навыки от части блогеров кто специализируется на работе с ними эври дей!

Навайбкожено от части из за задержки рейса Сочи>СПБ на 6 часов

Stay Tuned!

Nerdlog - быстрый, ориентированный на удаленное взаимодействие, многохостовый TUI-просмотрщик логов с временной гистограммой и без центрального сервера. Он создан по мотивам Graylog/Kibana, но без лишних функций. Практически не требует настройки.

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

Основной сценарий использования: чтение системных журналов (из файлов /var/log/messages или /var/log/syslog, или непосредственно из journalctl) с одного или нескольких удаленных хостов. Очень эффективно даже при работе с большими файлами журналов (например, 1 ГБ и более).

Он поддерживает некоторые другие форматы логов и может использовать любые файлы логов, но именно это и стало основной причиной внедрения: наш бэкэнд веб-сервиса работал как службы systemd на множестве экземпляров Linux, выводя большое количество логов, и мы хотели иметь возможность эффективно читать эти логи и получать гистограмму временной шкалы, как это делают такие инструменты, как Graylog.

https://github.com/dimonomid/nerdlog

Опубликовано в @gitgate

#moni #log #graylog #kibana #journalctl #journald

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

https://techdialogos.ru/#day2

Начнем с базы эксплуатации - мониторинга. Как построить мониторинг, который будет помогать понять что реально происходит с продом? Что важнее, мониторинг инфраструктуры или бизнес метрики и как долго нужно хранить данные. И это только первая лекция. А всего их семь.

Расписание и билеты по ссылке

https://techdialogos.ru/

witr (Why is this running?)

Утилита witr отвечает на один-единственный вопрос:

Почему это запущено?

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

Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.

Репыч на Гитхаб

@usr_bin_linux