Галс Софтвэр приглашает на обновленный тренинг по OpenSearch 22-24 декабря

Приходите на дополнительный тренинг по OpenSearch в этом году. Мы обновили программу до версии 3.3 и добавили новые блоки:

🚀 сегментная репликация
🚀 мониторинг (Performance Analyzer)
🚀 отправка оповещений
🚀 работа с Vector
🚀 работа с Ingest pipelines

❗️ За 3 дня вы получите глубокий опыт работы с самой последней версией OpenSearch. Интенсив поможет быстро погрузиться в продукт, на растягивая знакомство на долгий срок.

Программа тренинга

Подробную информацию вы можете запросить, написав @galssoftware или через почту hello@gals.software.

Реклама. ООО «Галс Софтвэр», ИНН 5047195298, erid 2VtzquYcAp6

Анализ проекта VictoriaMetrics

Мальчишки и девчонки, а также их родители, как устроена VictoriaMetrics узнать не хотите ли? В этой статье вы узнаете структуру каталогов проекта и о предназначении различных файлов. А ещё там описаны некоторые проектные решения при разработке продукта.

Эту статью можно назвать продолжением цикла. Есть еще одна похожая, которую я уже публиковал в канале. Но там рассмотрено все немного под другим углом.

Хорошая новость: Рег.облако компенсирует весь первый месяц использования Kubernetes.

Подключайте кластеры K8s до 30 декабря и получайте 100% суммы обратно бонусами.
Подробнее — по ссылке.

Лучшие практики трассировки производительности для Linux

В этой статье перечислены готовые утилиты и скрипты для трассировки вызовов внутри Linux-систем между компонентами приложения. Рассмотрены perf, strace, eBPF и OTel.

Faster incident response through distributed tracing: Inside Glovo's use of Traces Drilldown

Понедельник, почти час дня, и вы голодны. Открываете приложение доставки еды, выбираете любимый ресторан и блюдо. Затем идёте оформлять заказ, но ничего не происходит.

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

Это тот тип сценария, которого вы пытаетесь избежать, если вы работаете в команде SRE в Glovo, дочерней компании Delivery Hero и платформы доставки еды и продуктов по запросу, работающей в 23 странах Европы, Африки и Азии.

В статье рассказано об опыте использования Grafana Traces Drilldown.

OpenTelemetry eBPF Instrumentation Marks the First Release

Надо же, OpenTelemetry теперь и в eBPF может. Пока в альфе.

Результатом коллаборации Grafana Labs, Splunk, Coralogix, Odigos и многих других членов сообщества стало решение OpenTelemetry eBPF Instrumentation (OBI). Этот продукт основан на Grafana Beyla, которая была пожертвована Grafana Labs в начале этого года. Разработка инструментария eBPF значительно ускорилась после того, как проект перешёл под управление OpenTelemetry. Было добавлено множество новых протоколов, качество повысилось, особенно при масштабном деплое, а тестирование выполняется в 10 раз быстрее.

Инструментирование OpenTelemetry eBPF (OBI) выполняется вне процесса и использует инструменты на уровне протокола, а не на уровне библиотеки. Оно использует глубокую интеграцию с ядром, изоляцию процессов, безопасность выполнения и преимущества производительности технологии eBPF.

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

В общем просто космос какой-то. Читайте продолжение в блоге OpenTelemetry.

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

@monitorim_it

Обучающие материалы о Grafana от самой Grafana

Узнаете то, о чем раньше не знали. Изучение каждого мини-курса займет 10-20 минут. Все описано в доступной форме в виде пошаговой инструкции.

Среди обучающих курсов:

🚀 Kubernetes Monitoring

🚀 Connect to a Prometheus data source

🚀 Visualize logs

🚀 Create logsalert rule

и многое другое.

@monitorim_it

Continuous profiling for native code: Understanding the what, why, and how

Профилирование как метод отладки существует уже давно. В середине 2010-х годов, появился ряд продуктов, которые дали начало использованию этой технологии как четвёртого метода наблюдаемости. Появление eBPF сделали расширило его возможности.

В этой статье рассмотрены преимущества непрерывного профилирования и пример использования для получения наглядной информации о производительности кода.

Классический мониторинг уже не справляется с вызовами сложных ИТ-систем: он фиксирует сбои, но не раскрывает их причины.

Observability меняет подход — помогает понять взаимосвязи сервисов, качество работы и опыт пользователей. Подробнее об этом рассказал Антон Новоженин, технический директор GMONIT. В материале:

📌 ограничения традиционного мониторинга;
📌 особенности APM;
📌 ключевые принципы observability;
📌 преимущества сочетания подходов;
📌 тенденции, определяющие развитие систем анализа ИТ-инфраструктуры.

Переходите по ссылке, чтобы прочитать статью! 📖

Реклама. ООО "ХАЙПЕРСОФТЛАБ", ИНН 9705151703, erid 2Vtzqv6m13P

Your Brain on Incidents

Опыт работы автора этой статьи дежурным начался в середине 2000-х. Было пять вечера пятницы, конец первой недели работы инженером-программистом в финансовой компании в Лондоне. Он как раз закрывал свою IDE на выходные, когда к столу, неловко улыбаясь, подошёл начальник. В руках у него были IBM Thinkpad, Blackberry и, несомненно, грузная ноша человека, которому нужно было сделать одолжение. Веселые истории и поучительный опыт из жизни дежурного.

Как продуктовые аналитики в Туту ловят аномалии в метриках

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

Configuring PostgreSQL Logs: A Practical Guide

Анализ логов PostgreSQL даёт следующие преимущества:

🚀 Отладка и устранение неполадок: выявление медленных запросов, взаимоблокировок и проблем с подключением.

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

🚀 Аудит и соответствие требованиям: регистрация того, кто, к чему, когда и откуда получил доступ, для обеспечения подотчетности и безопасности.

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

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

@monitorim_it

Специальное предложение для планирующих миграцию виртуализации

Компания ISPsystem запустила акцию «Мигрируем VMeste» — комплексное решение для перехода с российских платформ виртуализации на VMmanager (Продукт года по версии CNews Awards).

Ключевые преимущества программы:

• Лицензия VMmanager на 12 месяцев по цене технической поддержки
• Годовая лицензия BILLmanager Enterprise в подарок
• Экспертное сопровождение миграции специалистами ISPsystem

Условия участия:
- Приобретение годовой технической поддержки на количество мигрирующих хостов
- Регистрация в акции — до 31 декабря 2025 года
- Завершение всех миграций — до 31 декабря 2026 года

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

Детали акции доступны на официальном сайте ISPsystem.

Реклама. АО «Экзософт»

Масштабируемый мониторинг: Настраиваем VictoriaMetrics в HA-конфигурации с VMAgent и Grafana

Когда стек мониторинга перерастает масштаб нескольких серверов, классический Prometheus показывает свои ограничения:

🚀 Проблемы с производительностью при миллионах метрик

🚀 Вертикальное масштабирование

🚀 Сложности с долгосрочным хранением

🚀 Ограниченные возможности репликации

Очередная статья про настройку VM

@monitorim_it

Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes

В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.

Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.

Свой мини-«мониторинг как сервис»: Python-демон + Next.js-дашборд

В какой-то момент автор этой статьи поймал себя на том, что в третий раз пишет похожий набор проверок (API, страницы, базы, очереди, TLS, Docker…) и снова открывает это все в голых логах или простых HTML-страничках. В итоге он сел и сделал отдельный проект — мониторинг-демон на Python + Next.js-дашборд. Подробности в статье.

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

@monitorim_it

RUM на Prometheus: пишем за вечер свой простой и надёжный фронтенд-мониторинг

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

@monitorim_it

Observability все дороже и дороже

В очередной раз натолкнулся на статью с предложением снизить расходы на Observability-платформу. На этот раз статья от ClickHouse (ClickStack).

Представим, что мы средняя компания с несколькими сотнями сервисов, контейнеров и виртуалок. Мы хотим мониторить всё: метрики, логи, трейсы, пользовательские события. Давайте-ка теперь прикинем в формате пол-палец-потолок какие у нас будут расходы на хранение, например, логов.

Предположим, что у нас 200 нод/контейнеров/host-объектов, которые генерят
ingest ~ по 2 TB сырых логов, метрик и трейсов в месяц. Хранить для простоты мы будем эти данные 30 дней.

А теперь при помощи опыта, чатгпт и простого поиска в интернете разложим как эти данные ложатся в архитектуры Elasticsearch, LGTM, Victoria (Metrics/Logs/Traces), Thanos, Prometheus.

🚀 ElasticSearch

Логи: расжатие 1.2×–1.6×, ~1,5× в среднем (~3 Тб). Рост дают инвертированные индексы.
Метрики: ~0.9 Б/сэмпл (при хранении в формате TSDS) ~115 ГБ
Трейсы: расжатие 1.5×–2,5×, ~2× в среднем (~4 Тб).

🚀 Clickhouse

Логи: сжатие 10×-30×, ~20× в среднем (~100 Гб)
Метрики: 0.5–1.6 Б/сэмпл ~100 ГБ
Трейсы: сжатие 7×-18×, ~10× в среднем (~200 Гб)

🚀 Victoria

(Logs) Логи: сжатие 10×-20×, ~15× в среднем (~133 Гб)
(Metrics) Метрики: ≈1 Б/сэмпл ~125 ГБ
(Traces) Трейсы: сжатие 8×-15×, ~11,5× в среднем (~170 Гб)

🚀 Grafana

(Loki) Логи: сжатие 3×-10×, ~5× в среднем (~400 Гб)
(Mimir) Метрики: ~1.3 Б/сэмпл~160 ГБ
(Tempo) Трейсы: расжатие 0,8×-1,5×, ~1× в среднем (~2000 Гб)

🚀 Thanos

Метрики: ~1-2 Б/сэмпл + 20% оверхед на метаданные и индексы ~225 ГБ

🚀 Prometheus

Метрики: ~1-2 Б/сэмпл (среднее 1,5 Б/сэмпл) ~190 ГБ

По итогу логи/метрики/трейсы займут места в:

ElasticSearch ~7115 Гб
ClickHouse ~400 Гб
Victoria ~428 Гб
LGTM ~2560 Гб

Путем математических вычислений теперь можно посчитать сколько вам нужно заплатить или за хранение в облаке этих данных или за хранение во внутреннем контуре. Также очевидно, что чем больше данных вы храните тем большая инфраструктура это все должна обслуживать (кластера, ноды и т.д.). А ещё ведь резервные копии нужны. Уф.

В общем, правильный выбор стека сэкономит вам практически всё: деньги, человекочасы и нервы.

🚀 Напишите в комментариях какой стек используете в своих observability-системах и чем довольны/не довольны. Обменяемся опытом.

@monitorim_it

Deprecating Zipkin Exporter

Проанализировав особенности использования в различных языковых экосистемах, мы отметили, что сообщество всё больше склоняется к OTLP, при этом экспортёры Zipkin получили ограниченное распространение — на некоторых языках, даже меньшее, чем уже устаревший экспортёр Jaeger. Учитывая минимальное участие пользователей в решении связанных вопросов и наличие альтернатив, мы считаем, что сейчас самое время прекратить поддержку экспортёров Zipkin в SDK OTel.

Больше подробностей в блоге OTEL.

@monitorim_it

Zabbix Meetup уже завтра!

Уже завтра состоится наш совместный с Zabbix митап, где я также буду выступать. Приходите, чтобы узнать много интересного и просто поддержать🙏

🔥 На вебинаре выступит Алексей Владышев — СЕО Zabbix и расскажет о планируемых нововведениях в Zabbix 8.0.

Зарегистрируйтесь, чтобы не пропустить