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

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

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

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

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

Работая за компьютером по 10-12 часов в день, я постоянно ловил себя на том, что проверяю диспетчер задач. То процессор грузится, то память подыхает, то диск трещит по швам. Стандартные инструменты Windows работают, но постоянно переключаться между окнами — то еще удовольствие.

Попробовал разные программы — одни слишком навороченные, другие жрут память как не в себя, третьи выглядят так, будто их делали в 2005 году. В какой-то момент мне это надоело, и я подумал: "А почему бы не сделать свой монитор? Простой, удобный и легкий".

Aether Monitor+ — это как раз та утилита, которой мне не хватало. Она висит поверх всех окон маленьким виджетом и показывает самое важное: загрузку процессора, использование памяти, свободное место на диске и температуру. Всё это в реальном времени, без лишних деталей.

Grafana Image Renderer, являясь серверной частью для Grafana OSS, Grafana Enterprise и Grafana Cloud, позволяет использовать Grafana для различных сценариев, связанных с генерацией и обменом изображениями из Grafana. К ним относятся:

🚀 Экспорт дашбордов в форматы PDF и PNG.

🚀 Включение изображений в уведомления об оповещениях

🚀 Обмен отрендеренными изображениями по прямым ссылкам.

🚀 Создание изображений для экспорта в PDF и запланированных отчетов (доступно в Grafana Cloud и Grafana Enterprise)

Долгое время можно было выбрать между установкой Image Renderer в качестве плагина для Grafana или развертыванием его как сервиса. Плагин был объявлен устаревшим в сентябре 2025 года, и теперь Image Renderer существует только как сервис, который можно развернуть отдельно вместе с Grafana; он не входит в стандартную комплектацию Grafana.

Краткие рекомендации о деплое Helm-чарта VictoriaLogs для одного сервера в боевой среде:

🚀 Для сервера VictoriaLogs используйте выделенный узел (предпочтительно NVMe), чтобы избежать влияния соседних приложений.

🚀 Настройте параметры хранения и сохранения данных в соответствии с объемом ваших логов; VictoriaLogs хорошо сжимает данные, но хранение все равно требует затрат.

🚀 Если вы используете Vector в качестве сборщика логов, ограничьте обогащение метаданных, чтобы уменьшить количество записей и потребление ресурсов.

🚀 Включите дашборды и собирайте метрики Vector с помощью VMPodScrape для обеспечения оперативной прозрачности.

🚀 Запустите выделенный экземпляр VMAlert для VictoriaLogs и настройте правила с селекторами.

🚀 Следуйте рекомендациям LogsQL (уменьшите количество меток, избегайте ресурсоемких регулярных выражений, ограничьте временные диапазоны).

В этой статье я расскажу, как с помощью Python, Flask и SNMP создать простой веб-мониторинг для МФУ в корпоративной сети. Решение позволяет видеть статус, уровень тонера, тип картриджа и серийный номер принтера прямо в браузере.

Для реализации на МФУ должен быть включен SNMP v1/v2c. Порт 161/UDP должен быть открыт.

Почему я так упираюсь в связку “трейсы + логи”? Потому что это реально магия. Ты открываешь проблемный трейс, видишь trace_id, и дальше хочешь в один клик найти все логи по этому запросу. Чтобы это работало, логгер должен вытаскивать trace_id и span_id из контекста.

Идея простая: у каждого запроса есть trace_id, и по нему ты видишь весь путь запроса через сервисы, очереди, базы и внешние интеграции. Внутри trace есть span — атомарные операции. Хорошая новость в том, что большая часть спанов создаётся автоматически, если ты используешь нормальные инструменты (HTTP middleware, SQL драйверы с OTel-инструментацией, клиенты Kafka/Redis и т.д.). Плохая новость в том, что бизнес-логика “между ними” сама себя не оттрассирует, и иногда надо уметь добавить span руками.

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

Плюс есть технические метрики, которые не про сервис в целом, а про конкретную бизнес-механику: сколько сообщений улетело в DLQ, сколько промахов у кэша, как часто включается fallback. Такие числа позволяют развивать сервис на цифрах, а не на ощущениях.

Анализ логов в больших масштабах — одна из самых сложных задач в области мониторинга. Современные системы генерируют огромные объемы неструктурированных данных — они часто повторяются, содержат много шума и не имеют контекста, необходимого инженерам для принятия решений. В результате получается океан строк логов, где сигнал скрыт в шуме, а поиск смысла становится медленным и дорогостоящим процессом.

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

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

В этой статье представлено сравнение четырёх реализаций одного и того же сервиса поверх PostgreSQL:

Spring MVC + JDBC

Spring WebFlux + R2DBC

Ktor + JDBC

Go + pgx

Все сервисы крутятся в Docker с одинаковыми ресурсными лимитами и прогоняются через один и тот же JMeter-план. Для каждого стека определяется максимальный RPS при соблюдении SLO по p99-латентности.

Давайте будем реалистами: тысяча графиков не спасет вас в 2 часа ночи. Спасут вас десять правильных графиков, основанных на фундаментальных принципах и настроенные на сигнал, а не на шум. Ниже приведены дашборды, которые я снова и снова видел превращающими «загадочные падения» в «незначительные сбои». Каждый из них объясняет, как он работает, и содержит фрагмент кода, который вы можете адаптировать под себя.

Проблема: Традиционное нагрузочное тестирование включает в себя обширную ручную корреляцию данных с бэкэндом и часто заходит в тупик из-за «слепых зон» в коде приложения и распределенных системах.

Решение: Благодаря автоматической инструментации скриптов Locust с помощью OpenTelemetry, нагрузочные тесты теперь будут генерировать сигналы OpenTelemetry. Эта телеметрия нагрузочных тестов передается в платформу мониторинга на основе OTel в режиме реального времени, позволяя визуализировать каждый запрос нагрузочного тестирования и отслеживать всю его транзакцию. Теперь у вас есть полная сквозная видимость — ваши запросы нагрузочного тестирования коррелированы с вашим приложением, инструментированным OTel.

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