Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
Пятничный деплой
Открыть в Telegram
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest
Больше4 728
Подписчики
+124 часа
+57 дней
-830 день
Загрузка данных...
Похожие каналы
Облако тегов
Входящие и исходящие упоминания
---
---
---
---
---
---
Привлечение подписчиков
июль '26
июль '26
+4
в 0 каналах
июнь '26
+78
в 0 каналах
Get PRO
май '26
+86
в 0 каналах
Get PRO
апрель '26
+114
в 0 каналах
Get PRO
март '26
+127
в 8 каналах
Get PRO
февраль '26
+67
в 0 каналах
Get PRO
январь '26
+46
в 0 каналах
Get PRO
декабрь '25
+46
в 0 каналах
Get PRO
ноябрь '25
+56
в 1 каналах
Get PRO
октябрь '25
+49
в 0 каналах
Get PRO
сентябрь '25
+44
в 1 каналах
Get PRO
август '25
+55
в 0 каналах
Get PRO
июль '25
+58
в 0 каналах
Get PRO
июнь '25
+53
в 0 каналах
Get PRO
май '25
+48
в 0 каналах
Get PRO
апрель '25
+62
в 1 каналах
Get PRO
март '25
+82
в 0 каналах
Get PRO
февраль '25
+50
в 0 каналах
Get PRO
январь '25
+88
в 1 каналах
Get PRO
декабрь '24
+82
в 0 каналах
Get PRO
ноябрь '24
+126
в 4 каналах
Get PRO
октябрь '24
+110
в 1 каналах
Get PRO
сентябрь '24
+74
в 0 каналах
Get PRO
август '24
+73
в 0 каналах
Get PRO
июль '24
+87
в 0 каналах
Get PRO
июнь '24
+87
в 1 каналах
Get PRO
май '24
+94
в 0 каналах
Get PRO
апрель '24
+112
в 0 каналах
Get PRO
март '24
+113
в 0 каналах
Get PRO
февраль '24
+106
в 1 каналах
Get PRO
январь '24
+131
в 0 каналах
Get PRO
декабрь '23
+101
в 1 каналах
Get PRO
ноябрь '23
+177
в 1 каналах
Get PRO
октябрь '23
+21
в 0 каналах
Get PRO
сентябрь '23
+45
в 0 каналах
Get PRO
август '23
+42
в 0 каналах
Get PRO
июль '23
+50
в 0 каналах
Get PRO
июнь '23
+44
в 0 каналах
Get PRO
май '23
+32
в 0 каналах
Get PRO
апрель '23
+24
в 0 каналах
Get PRO
март '23
+32
в 0 каналах
Get PRO
февраль '23
+29
в 0 каналах
Get PRO
январь '23
+27
в 0 каналах
Get PRO
декабрь '22
+31
в 0 каналах
Get PRO
ноябрь '22
+30
в 0 каналах
Get PRO
октябрь '22
+32
в 0 каналах
Get PRO
сентябрь '22
+42
в 0 каналах
Get PRO
август '22
+53
в 0 каналах
Get PRO
июль '22
+39
в 0 каналах
Get PRO
июнь '22
+46
в 0 каналах
Get PRO
май '22
+37
в 0 каналах
Get PRO
апрель '22
+35
в 0 каналах
Get PRO
март '22
+24
в 0 каналах
Get PRO
февраль '22
+32
в 0 каналах
Get PRO
январь '22
+55
в 0 каналах
Get PRO
декабрь '21
+55
в 0 каналах
Get PRO
ноябрь '21
+71
в 0 каналах
Get PRO
октябрь '21
+59
в 0 каналах
Get PRO
сентябрь '21
+71
в 0 каналах
Get PRO
август '21
+75
в 0 каналах
Get PRO
июль '21
+44
в 0 каналах
Get PRO
июнь '21
+78
в 0 каналах
Get PRO
май '21
+32
в 0 каналах
Get PRO
апрель '21
+91
в 0 каналах
Get PRO
март '21
+66
в 0 каналах
Get PRO
февраль '21
+82
в 0 каналах
Get PRO
январь '21
+67
в 0 каналах
Get PRO
декабрь '20
+2 821
в 0 каналах
| Дата | Привлечение подписчиков | Упоминания | Каналы | |
| 01 июля | +4 |
Посты канала
We’re excited to introduce opensource vmestimator, a new component in the VictoriaMetrics ecosystem.
vmestimator measures metrics cardinality across arbitrary label dimensions and exposes the results as Prometheus-compatible metrics. It helps to understand where cardinality comes from, track how it evolves over time, and build early-warning alerts before cardinality becomes a problem.
If you’re operating Prometheus-compatible monitoring systems and want realtime visibility into metric cardinality, give vmestimator a try. We’d love to hear your feedback and learn more about your use cases.
Read more about its design and configuration in the documentation, or explore it yourself in the playground.
| 2 | Why Your Grafana is Slow on Kubernetes (and 3 Replicas Won't Fix It)
How we eliminated crash loops and hundreds of errors and why “high availability” was making everything worse.
https://medium.com/@j.aslanov94/why-your-grafana-is-slow-on-kubernetes-and-3-replicas-wont-fix-it-f375527de85a | 221 |
| 3 |  Kuber Community Day возвращается: 30 июля, Москва 😀
30 июля во второй раз состоится конференция Kuber Community Day. В этом году участников ждут новые доклады, форматы и площадка.
Будут два пространства с техническим контентом от практиков из X5 Tech, MWS, «Райффайзенбанка», «СберЗдоровья», «Лаборатории Числитель», «Инфосистемы Джет», Hilbert Team, OpsMaster и других компаний.
Среди заявленных тем:
- Не Argo CD единым живы: комплексная автоматизация на стеке Argo Project
- Неидемпотентный мир победил, AI оказался сильней
- NixOS вместо Talos: когда хочется Kubernetes, но не хочется терять Linux
- Kubernetes — это всего пять сертификатов
- Мониторинг здоровья Kubernetes
◽️ Форматы: офлайн и онлайн (трансляция предусмотрена для обоих залов).
Участие бесплатное, но места на офлайн ограничены площадкой.
Регистрация уже идет по ссылке. | 692 |
| 4 | Наткнулся на очередную статью: «Zero-Downtime Deployments with Docker Compose — No Kubernetes Required». Автор прямо пишет - в индустрии, мол, массовое заблуждение, что для серьёзного прода нужен k8s. Не нужен. Тысячи проверок в минуту, мульти-регион, деплой по нескольку раз в день - и всё на компоузе.
И тут он прав. Для одного хоста и пары сервисов Kubernetes - это из пушки по воробьям. Бесшовно перекатить контейнер умеет и nginx, никакой оркестратор для этого не нужен.
Только это подмена тезиса. В k8s идут не за zero-downtime деплоем - за ним и так все умеют. Идут за другим.
Первое - пул машин. Compose заперт в пределах одного хоста. В комментах это сразу и поймали: «тысячи проверок в минуту - это вообще немного, спокойно живёт на одной железке. Kubernetes берут, когда надо выйти за её пределы». Вот и весь спор.
Второе - стандарт. k3s ставится за пять минут, и ты получаешь готовую вселенную типового тулинга. Новый человек приходит с любого облака и сразу в теме. А не разбирает полгода твой самодельный оркестратор из bash'а и скотча.
Лучший коммент в треде - вообще не про технику. Человек честно признался: «взяли инструмент попроще, проект взлетел - и все эти "сложные" фичи k8s внезапно стали нужны. Зря не взяли сразу». Знакомо до боли. 🤡🤡
Короче. «Не нужен Kubernetes» - честный заголовок. Просто допишите в конце: «пока у тебя один хост». А на втором десятке нод поговорим заново.
#kubernetes #docker #devops | 644 |
| 5 |  Когда метрики сходят с ума: автоматическая детекция аномалий во временных рядах в Yandex Monium
А вот Яндекс пишет как они решали задачу поиска аномалий на своем внутреннем контуре Monium. Когда-нибудь обещают это это же самое реализовать и для внешних пользователей.
📱 Telegram | 📲 MAX | 838 |
| 6 |  Если в вашей работе регулярно всплывают GitLab Runner, Kubernetes, ArgoCD или CDN, возможно, этот митап стоит добавить в календарь.
10 июля команда Спортса" проводит Infrastructure & Reliability Meetup
📍 Москва + онлайн
В программе четыре доклада:
• как защитить GitLab Runner;
• как устроена CDN и что важно при миграции инфраструктуры;
• опыт внедрения ArgoCD и GitOps;
• запуск GPU-задач в Kubernetes на нестандартном железе.
Выступать будут инженеры из Спортса", Wildberries & Russ и 2ГИС. После докладов обещают просмотр матча 1/4 финала ЧМ-2026 ⚽️
Подробная программа и регистрация по ссылке: https://sprts.cc/deploy | 912 |
| 7 | 📎 Пусть main делает реальную работу
«Просто свяжи всё в main, логику вынеси в пакеты, держи main.go в двадцать строк». Так советуют.
Совет не то чтобы неверный, но ведёт к конкретной поломке. Вы получаете папку cmd/ из пакетов, которые вызываются ровно из одного места, и main.go на двадцать строк вида «вызвать функцию бутстрапа в internal/app». Вы добавили лишний слой, но не добавили абстракции.
➡️ Что делать вместо
Пусть main делает настоящую работу. Читает конфиг, инициализирует пул базы, связывает зависимости, поднимает gRPC сервер и регистрирует обработчик остановки.
Если ваш main.go на двести строк, но каждая строка это честная проводка без бизнес логики и без условий по фичефлагам, это нормально:
func main() {
ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
defer stop()
cfg := config.MustLoad() // паникует на плохом конфиге, намеренно на старте
pool, err := pgxpool.New(ctx, cfg.DatabaseURL)
if err != nil {
log.Fatal("failed to initialize database pool", zap.Error(err))
}
defer pool.Close()
queries := db.New(pool)
memberSvc := members.NewService(queries)
srv := grpc.NewServer(grpc.ChainUnaryInterceptor(
logging.UnaryServerInterceptor(logger),
recovery.UnaryServerInterceptor(),
))
memberspb.RegisterMembersServiceServer(srv, memberSvc)
go func() {
if err := srv.Serve(lis); err != nil {
log.Fatal("server exited", zap.Error(err))
}
}()
<-ctx.Done()
srv.GracefulStop()
}
Это читаемо, и это реальная топология приложения, видная в одном файле. Тонкий main оправдан, только когда стартовая логика действительно сложная и заслуживает отдельного пакета. В остальных случаях честная проводка прямо в main понятнее.
📍 Навигация: Вакансии • Задачи • Собесы
🐸 Библиотека Go-разработчика
#GoToProduction | 1 344 |
| 8 | herdr
agent multiplexer that lives in your terminal.
https://github.com/ogulcancelik/herdr | 1 037 |
| 9 |  4 MCP-сервера, о которых стоит знать каждому DevOps-инженеру
1. Kubernetes MCP
- расследовать pod’ы в CrashLoopBackOff;
- дебажить неудачные деплои;
- анализировать состояние кластера.
Repo:
https://github.com/Flux159/mcp-server-kubernetes
2. AWS MCP
- разбирать резкие скачки расходов в AWS;
- находить неиспользуемые ресурсы;
- troubleshooting облачной инфраструктуры.
Repo:
https://github.com/awslabs/mcp
3. Terraform MCP
- проверять Terraform-планы;
- находить drift в инфраструктуре;
- объяснять изменения в инфраструктуре.
Repo:
https://github.com/hashicorp/terraform-mcp-server
4. Grafana + Prometheus MCP
- расследовать скачки latency;
- анализировать production-инциденты;
- объяснять alert storms.
Repos:
https://github.com/grafana/mcp-grafana
https://github.com/pab1it0/prometheus-mcp-server
ИИ может получать доступ к вашей инфраструктуре, понимать, что реально происходит, и помогать разбирать проблемы на основе настоящих данных, а не догадок. | 1 299 |
| 10 |  📖 Как использовать Temporal
Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта.
❇️ Не поддавайтесь иллюзии чистой архитектуры
Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы.
Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход.
❇️ Как надо делать:
🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK
🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования
🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity
💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики
Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность.
Какие инструменты могут помочь:
🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение
🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката
🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться
➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫
🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 1 195 |
| 11 | cardamon | 1 |
| 12 | О бенчмаркинге, часть 2
(первая часть тут)
Производительности в вакууме не бывает
Состояние одной и той же системы от запуска к запуску бенчмарков всегда разное. Даже если зафиксированы все статические параметры (настройки OS и рантайма, CPU affinity, etc), то температура процессоров, состояние кешей, layout кода в памяти всё равно плавают. Что уж говорить про внешне схожие окружения - там различий может быть еще больше.
Следовательно результаты на выходе всегда различаются.
Так какой из них нам взять за основу?
———
Помогает формулировка от Ben Sigelman: «Performance is a shape, not a number».
Производительность это всегда распределение, а не одно конкретное число. Не существует одного единственного, правильного значения.
И каждый отдельный прогон бенчмарка это просто один сэмпл из всего распределения, полученный при конкретных условиях.
Если углубить, то и внутри одного запуска мы всегда получаем распределение:
$ funclatency-bpfcc __sys_sendto -d 10 -u
usecs : count distribution
0 -> 1 : 12433 |************ |
2 -> 3 : 20394 |******************* |
4 -> 7 : 20540 |********************|
8 -> 15 : 1962 |** |
16 -> 31 : 237 | |
32 -> 63 : 19 | |
64 -> 127 : 8500 |******** |
128 -> 255 : 12 | |
256 -> 511 : 0 | |
512 -> 1023 : 4 | |
1024 -> 2047 : 5 | |
2048 -> 4095 : 1 | |
4096 -> 8191 : 2 | |
———
Задача перформанс-инженера сводится к двум вещам:
1. сужать это распределение
2. объяснять, почему оно именно такое
На ширину распределения влияет шум: переключение контекста, прерывания, соседи, и т.д. И чем шум больше, тем шире хвосты распределения.
Важный момент: шум может быть случайным, а может быть систематическим. Бороться с ними нужно по-разному.
———
Случайный шум (random noise) это то, что возникает непредсказуемо, без видимой системы. Например, фоновый процесс случайно попал на наше ядро в одних прогонах и не попал в других. Или соседнее ядро внезапно дало всплеск нагрузки на общий L3.
Лечится количеством прогонов: чем их больше, тем сильнее усредняем случайные отклонения, и тем точнее итоговая оценка.
Систематический шум (systematic bias), уже другое явление. Какой-то фактор стабильно сдвигает измерения в одну и туже сторону. Например IRQ, прибитый к нашему ядру, просыпается через равные промежутки. Такой тип шумов (или отклонений) не лечится количеством прогонов, из раза в раз будем получать искаженный результат.
В "Producing Wrong Data Without Doing Anything Obviously Wrong", авторы показали, что даже размер переменных окружения может вносить существенные искажения в итоговый результат.
С систематическим шумом борются наблюдением и рандомизацией факторов, см. Stabilizer.
———
Это объясняет, почему Passive Benchmarking плох, даже при тысяче прогонов: он не отличает один тип шума от другого. Active Benchmarking, помимо прочего, как раз про то, чтобы такие смещения находить.
Ранее мы говорили о цикле в Active Benchmarking: запустил → пронаблюдал → сформулировал гипотезу → проверил → повторил.
Это как раз про то, что борьба с шумом процесс бесконечный: зафиксировали частоту, получили распределение уже, в следующем прогоне в топ выходят прерывания, вынесли их с ядра, получили еще более стабильный результат.
Далее поднимают голову соседи по L3 кешу...
По своей природе это похоже на дрейфующее бутылочное горлышко в производительности: всегда что-то будет в топ-1.
Следующим возникает естественный вопрос: "где и когда остановиться?" To be continued.
———
Выводы
- Производительность это распределение, а не число
- Шум есть всегда, и работать с ним нужно исходя из его типа
- Борьба с шумом бесконечный процесс - главное знать, где остановиться.
———
Поставить лайк на Linkedin | 926 |
| 13 | Контроль доступа в Kubernetes
🔐Всем DevOps! Собрали для вас подборку статей с LearnKube, которая поможет разобраться, кто может подключаться к серверу API, что именно ему разрешено и как это контролировать в Kubernetes.
⏺В первой статье Гулькан Топку и Артур Чиао сосредоточились на аутентификации. На примерах поймете, как действуют ограничения к серверу HTTP API и ни слова про kubectl.
⏺Следующий этап – авторизация и RBAC. Всё о том, как ограничить доступ, чтобы у каждого пользователя и сервиса были только нужные права.
⏺И наконец, практическая модель адаптации аутентификации под свою инфраструктуру, например через LDAP.
Желаем приятного чтения и продуктивной недели!
#девопс #kubernetes #безопасность | 1 133 |
| 14 | Антиконференция Summer Merge — летняя перезагрузка для ИТ, которую нельзя пропускать 🔥
Устали от одинаковых событий и рабочей рутины? Присоединяйтесь к Summer Merge! Это по-настоящему летний формат ИТ-ивента. Программа события готова и уже на сайте.
— 3 дня на природе, без офисов и дедлайнов;
— Живые дискуссии под открытым небом вместо лекций в аудиториях;
— Soft skills, карьера и реальные боли индустрии;
— Нетворкинг, который действительно работает;
— Спорт, вечерние посиделки у костра и десятки видов активностей.
🤝 За 4 года антиконференция объединила тысячи IT-специалистов: разработчиков, менеджеров, аналитиков, владельцев бизнеса и маркетологов. Summer Merge – сообщество, в котором легко находить единомышленников, деловых партнеров, новые карьерные возможности и даже вторую половинку.
⛺ Формат палаточного лагеря и дружеская открытая атмосфера помогают перезагрузиться, посмотреть на работу по-новому и уехать с новыми идеями и вдохновением на весь год.
Спешите приобрести билет до повышения цен со скидкой 15% по промокоду «ПЯТНИЧНЫЙДЕПЛОЙ»!
Купить билеты на сайте. | 1 164 |
| 15 | 📖100 Go Mistakes and How to Avoid Them
🖋Harsanyi Teiva | 2022
Книга «100 ошибок в Go и как их избежать» показывает, как заменить распространенные проблемы в программировании на Go идиоматичным и выразительным кодом. Вы изучите десятки интересных примеров и кейсов и научитесь выявлять ошибки, которые могут возникнуть в ваших собственных приложениях. Автор книги Тейва Харсаньи систематизирует методы предотвращения ошибок по удобным категориям — от типов данных и строк до параллелизма и тестирования.
💾 Скачать книгу
Clean Code | #книги #Go & Мах | 1 116 |
| 16 | OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel | 627 |
| 17 | nfraDev Community приглашает на InfraDev Meetup #4: про AI и не только
Прямо сейчас мы наблюдаем как AI в SDLC меняет процесс разработки — об удачных примерах и кейсах поговорим в этот раз. Обсудим, как разрабатывать инфраструктурные сервисы с помощью AI и как построить MLOps-платформу для обучения моделей. И не только: пока AI не перестроил DevOps-цикл, классические вызовы сборки образов для виртуальных машин остаются актуальными.
Спикеры
▫️Кирилл Фролов, эксперт-разработчик в отделе разработки базовых сервисов, VK Cloud, VK Tech
▫️Павел Шипилов, Старший разработчик ML Платформы в Avito
▫️Александр Александров, системный архитектор в направлении разработки и управления инфраструктурой, VK Cloud, VK Tech
Подробнее о докладах читайте на странице мероприятия.
Когда: 10 июня, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться. | 1 410 |
| 18 | OpenTelemetry Semantic Conventions: изменения в HTTP, RPC, gRPC, JSON-RPC (v1.37 → v1.43)
Собрал это, потому что был удивлен, когда ребята в сервисе обновили либу otel для golang, а там часть метрик для gRPC исчезла, они перестали видеть сервис на нашей стандартизированной доске gRPC RED-метрики в Grafana.
Версия 1.37.0 (Базовая)
- HTTP:
- Метрики: http.server.request.duration, http.client.request.duration
- Единица измерения: Секунды (s)
- Атрибуты: http.request.method, url.scheme, http.response.status_code и др.
- RPC (включая gRPC и JSON-RPC):
- Метрики: rpc.server.duration, rpc.client.duration
- Единица измерения: Миллисекунды (ms)
- Атрибуты: rpc.system, rpc.service, rpc.method
Версия 1.38.0
- HTTP:
- Единица измерения: Окончательно закреплена в секундах (s). В более ранних черновиках и некоторых реализациях использовались миллисекунды, но в 1.38.0 стандарт окончательно перешел на секунды для всех duration метрик.
- RPC:
- Начало перехода от rpc.server.duration к rpc.server.call.duration.
Версия 1.39.0
- RPC:
- Переименование метрик: Метрики rpc.server.duration и rpc.client.duration начинают заменяться на rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Переход с миллисекунд (ms) на секунды (s) для новых метрик call.duration.
- gRPC/JSON-RPC:
- Продолжают следовать общим правилам для RPC, но теперь используют новые имена и секунды.
Версия 1.40.0
- RPC:
- Стабилизация: rpc.server.call.duration и rpc.client.call.duration становятся основными и рекомендуемыми метриками.
- Атрибуты: Уточнены требования к атрибутам rpc.system (например, grpc, jsonrpc), rpc.service и rpc.method.
- HTTP:
- Незначительные уточнения в описании атрибутов, связанных с повторными попытками (retries).
Версия 1.41.0
- RPC:
- Финализация: Старые метрики rpc.server.duration и rpc.client.duration официально помечены как устаревшие (deprecated) или удалены из основных рекомендаций в пользу rpc.server.call.duration и rpc.client.call.duration.
- Единица измерения: Строго секунды (s) для всех call.duration метрик.
- gRPC/JSON-RPC:
- Значения атрибута rpc.system стандартизированы: grpc для gRPC, jsonrpc для JSON-RPC.
Версия 1.42.0
- HTTP:
- Уточнения в атрибутах http.request.method (например, добавление поддержки нестандартных методов или уточнение регистра).
- RPC:
- Уточнения в описании того, как должны обрабатываться ошибки и какие атрибуты должны добавляться при сбоях (например, error.type).
Версия 1.43.0
- RPC:
- Продолжение работы над согласованностью атрибутов между различными RPC-системами.
- Уточнения в документации по использованию rpc.service и rpc.method для gRPC и JSON-RPC.
- HTTP:
- Незначительные корректировки в семантике атрибутов server.address и server.port.
Резюме ключевых изменений:
- Единицы измерения: Повсеместный переход с миллисекунд (ms) на секунды (s) для всех метрик duration.
- Имена метрик RPC: Переход от rpc.*.duration к rpc.*.call.duration.
- Атрибуты: Стандартизация значений для rpc.system (grpc, jsonrpc) и уточнение набора обязательных атрибутов.
А как вы решаете вопрос с именами метрик и изменениями в OTEL?
#opentelemetry #observability #changelog #otel | 1 123 |
| 19 |  Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет
Автор оригинальной статьи, Пьер Мане, рассказывает, как его команда столкнулась с на первый взгляд необъяснимым поведением Cilium и как поиск решения привёл его к конфигурации ядра Linux.
Отладка сродни археологии: ты пробираешься сквозь слои абстракций, пока не доберёшься до коренной породы — ядра. Это история о том, как скрытая в коде Linux логика работы со степенями двойки приводила к случайным и загадочным падениям Cilium, из-за чего мы не могли выкатиться в production.
Подробности в статье на Хабре.
@usr_bin_linux | 1 319 |
| 20 |  Материалы и слайды своего мастер-класса на CodeFest выложил на GitHub (продублирую в комменты)
Open source на страже Kubernetes Runtime Security
https://github.com/rusdacent/codefest-2026 | 1 234 |
