Drinking the OTel SODA: Send Observability Data Anywhere
Долгое время наблюдаемость означала организацию полного стека, который невозможно изменить: проприетарные агенты для сбора данных, проприетарный протокол для их передачи и проприетарный бэкенд для их просмотра. Наблюдаемость находилась в замкнутом пространстве.
OpenTelemetry был создан, чтобы сломать эту парадигму. Благодаря OTel Collector, выступающему в роли механизма трансляции и маршрутизации, метрики, журналы и трейсы больше не ограничены проприетарными средствами.
Наблюдаемость — это не монолит
Нет ничего плохого в проприетарном программном обеспечении; многие отличные системы имеют закрытый исходный код. Проблема в том, что данные становятся проприетарными в этих системах.
Когда сбор, передача и хранение тесно связаны с одним вендором, возможности сужаются. Нужна поддержка менее распространённого языка программирования? Вам придётся ждать агента кварталами. Хотите сменить вендора? Приготовьтесь к неделям перенастройки. Даже простые идеи, например, эксперименты со вторым параллельным бэкендом, могут стать «проектами».
OTel меняет весь подход. Сегодня вы можете единообразно инструментировать практически всё, и да, ещё никогда не было так просто менять платформу наблюдения, не трогая код приложения. Но дело не только в снижении привязки к вендору; когда вы контролируете, как перемещаются данные, вы можете отправлять их куда угодно.
Термин «наблюдаемость» создаёт впечатление, что сбор, обработка и хранение телеметрии — это один большой монолит. Это не так. Конвейер изначально компонуется, и наибольший эффект достигается в его хвосте: «бэкенде». Относитесь к этому хвосту как к развилке, а не как к тупику.
И вот тут предлагаю вам перейти к чтению оригинальной статьи, где рассказано что же такое SODA (Send Observability Data Anywhere) и как этот подход адаптировать к вашему окружению. Так как статься написана с прицелом на ClickStack, то в конце вам предлагается к нему еще раз присмотреться.
Долгое время наблюдаемость означала организацию полного стека, который невозможно изменить: проприетарные агенты для сбора данных, проприетарный протокол для их передачи и проприетарный бэкенд для их просмотра. Наблюдаемость находилась в замкнутом пространстве.
OpenTelemetry был создан, чтобы сломать эту парадигму. Благодаря OTel Collector, выступающему в роли механизма трансляции и маршрутизации, метрики, журналы и трейсы больше не ограничены проприетарными средствами.
Наблюдаемость — это не монолит
Нет ничего плохого в проприетарном программном обеспечении; многие отличные системы имеют закрытый исходный код. Проблема в том, что данные становятся проприетарными в этих системах.
Когда сбор, передача и хранение тесно связаны с одним вендором, возможности сужаются. Нужна поддержка менее распространённого языка программирования? Вам придётся ждать агента кварталами. Хотите сменить вендора? Приготовьтесь к неделям перенастройки. Даже простые идеи, например, эксперименты со вторым параллельным бэкендом, могут стать «проектами».
OTel меняет весь подход. Сегодня вы можете единообразно инструментировать практически всё, и да, ещё никогда не было так просто менять платформу наблюдения, не трогая код приложения. Но дело не только в снижении привязки к вендору; когда вы контролируете, как перемещаются данные, вы можете отправлять их куда угодно.
Термин «наблюдаемость» создаёт впечатление, что сбор, обработка и хранение телеметрии — это один большой монолит. Это не так. Конвейер изначально компонуется, и наибольший эффект достигается в его хвосте: «бэкенде». Относитесь к этому хвосту как к развилке, а не как к тупику.
И вот тут предлагаю вам перейти к чтению оригинальной статьи, где рассказано что же такое SODA (Send Observability Data Anywhere) и как этот подход адаптировать к вашему окружению. Так как статься написана с прицелом на ClickStack, то в конце вам предлагается к нему еще раз присмотреться.
🔥7❤2👍2
From Signals to Reliability: SLOs, Runbooks and Post-Mortems
Вы можете создать идеальную инфраструктуру наблюдения: унифицированные конвейеры OpenTelemetry, непрерывное профилирование, инструментирование каждого сервиса, сбор всех метрик, логов и трейсов и щепотка привлекательных дашбордов в Grafana.
Но это не спасет от возможных трудностей во время инцидентов. Недостающий элемент не технический, а организационный. Когда во время инцидентов срабатывают оповещения, команде необходимо мгновенно ответить на четыре вопроса: насколько это серьёзно? Какие действия следует предпринять? Кого необходимо привлечь? Когда проблема будет решена?
Без целей уровня обслуживания (SLA) критичность становится субъективной. Разные инженеры будут по-разному оценивать, приемлемо ли 5% ошибок или катастрофично. Без регламентов реагирование на инциденты превращается в импровизацию. Каждый инженер следует своей ментальной модели, что приводит к противоречивым результатам. Без структурированного анализа инцидентов команды устраняют симптомы, но упускают первопричины, постоянно сталкиваясь с одними и теми же проблемами.
В этой статье интересный разбор подхода к формированию SLA, ранбуков и пост-мортемов.
Вы можете создать идеальную инфраструктуру наблюдения: унифицированные конвейеры OpenTelemetry, непрерывное профилирование, инструментирование каждого сервиса, сбор всех метрик, логов и трейсов и щепотка привлекательных дашбордов в Grafana.
Но это не спасет от возможных трудностей во время инцидентов. Недостающий элемент не технический, а организационный. Когда во время инцидентов срабатывают оповещения, команде необходимо мгновенно ответить на четыре вопроса: насколько это серьёзно? Какие действия следует предпринять? Кого необходимо привлечь? Когда проблема будет решена?
Без целей уровня обслуживания (SLA) критичность становится субъективной. Разные инженеры будут по-разному оценивать, приемлемо ли 5% ошибок или катастрофично. Без регламентов реагирование на инциденты превращается в импровизацию. Каждый инженер следует своей ментальной модели, что приводит к противоречивым результатам. Без структурированного анализа инцидентов команды устраняют симптомы, но упускают первопричины, постоянно сталкиваясь с одними и теми же проблемами.
В этой статье интересный разбор подхода к формированию SLA, ранбуков и пост-мортемов.
🔥7❤5👍1
Изучаем инструменты мониторинга сети для Linux: tcpdump, wireshark и iftop
Linux предлагает много мощных инструментов, которые помогают администраторам захватывать, проверять и анализировать сетевой трафик в режиме реального времени. Три наиболее часто используемых инструмента — это tcpdump, wireshark и iftop. Подробнее в этой статье.
Linux предлагает много мощных инструментов, которые помогают администраторам захватывать, проверять и анализировать сетевой трафик в режиме реального времени. Три наиболее часто используемых инструмента — это tcpdump, wireshark и iftop. Подробнее в этой статье.
🔥8👍3
Галс Софтвэр приглашает на обновленный тренинг по OpenSearch 22-24 декабря
Приходите на дополнительный тренинг по OpenSearch в этом году. Мы обновили программу до версии 3.3 и добавили новые блоки:
🚀 сегментная репликация
🚀 мониторинг (Performance Analyzer)
🚀 отправка оповещений
🚀 работа с Vector
🚀 работа с Ingest pipelines
❗️ За 3 дня вы получите глубокий опыт работы с самой последней версией OpenSearch. Интенсив поможет быстро погрузиться в продукт, на растягивая знакомство на долгий срок.
Программа тренинга
Подробную информацию вы можете запросить, написав @galssoftware или через почту hello@gals.software.
Реклама. ООО «Галс Софтвэр», ИНН 5047195298, erid 2VtzquYcAp6
Приходите на дополнительный тренинг по OpenSearch в этом году. Мы обновили программу до версии 3.3 и добавили новые блоки:
🚀 сегментная репликация
🚀 мониторинг (Performance Analyzer)
🚀 отправка оповещений
🚀 работа с Vector
🚀 работа с Ingest pipelines
❗️ За 3 дня вы получите глубокий опыт работы с самой последней версией OpenSearch. Интенсив поможет быстро погрузиться в продукт, на растягивая знакомство на долгий срок.
Программа тренинга
Подробную информацию вы можете запросить, написав @galssoftware или через почту hello@gals.software.
Реклама. ООО «Галс Софтвэр», ИНН 5047195298, erid 2VtzquYcAp6
gals.software
Gals Software | OpenSearch | Обучение
Обучение работе с OpenSearch, OpenSearch Dashboards, Vector, DataPrepper
🔥6👍3👎1
Анализ проекта VictoriaMetrics
Мальчишки и девчонки, а также их родители, как устроена VictoriaMetrics узнать не хотите ли? В этой статье вы узнаете структуру каталогов проекта и о предназначении различных файлов. А ещё там описаны некоторые проектные решения при разработке продукта.
Эту статью можно назвать продолжением цикла. Есть еще одна похожая, которую я уже публиковал в канале. Но там рассмотрено все немного под другим углом.
Мальчишки и девчонки, а также их родители, как устроена VictoriaMetrics узнать не хотите ли? В этой статье вы узнаете структуру каталогов проекта и о предназначении различных файлов. А ещё там описаны некоторые проектные решения при разработке продукта.
Эту статью можно назвать продолжением цикла. Есть еще одна похожая, которую я уже публиковал в канале. Но там рассмотрено все немного под другим углом.
🔥8👍1👎1
Хорошая новость: Рег.облако компенсирует весь первый месяц использования Kubernetes.
Подключайте кластеры K8s до 30 декабря и получайте 100% суммы обратно бонусами.
Подробнее — по ссылке.
Подключайте кластеры K8s до 30 декабря и получайте 100% суммы обратно бонусами.
Подробнее — по ссылке.
🔥6👎3🤔2
Лучшие практики трассировки производительности для Linux
В этой статье перечислены готовые утилиты и скрипты для трассировки вызовов внутри Linux-систем между компонентами приложения. Рассмотрены perf, strace, eBPF и OTel.
В этой статье перечислены готовые утилиты и скрипты для трассировки вызовов внутри Linux-систем между компонентами приложения. Рассмотрены perf, strace, eBPF и OTel.
❤5👍1🔥1
Faster incident response through distributed tracing: Inside Glovo's use of Traces Drilldown
Понедельник, почти час дня, и вы голодны. Открываете приложение доставки еды, выбираете любимый ресторан и блюдо. Затем идёте оформлять заказ, но ничего не происходит.
Ваше раздражение нарастает, поскольку с каждой минутой вы становитесь всё более голодными. Но есть и раздражение с другой стороны этой сделки: инженеры пытаются понять, в чём проблема, поскольку заказов становится меньше, а потери прибыли растут.
Это тот тип сценария, которого вы пытаетесь избежать, если вы работаете в команде SRE в Glovo, дочерней компании Delivery Hero и платформы доставки еды и продуктов по запросу, работающей в 23 странах Европы, Африки и Азии.
В статье рассказано об опыте использования Grafana Traces Drilldown.
Понедельник, почти час дня, и вы голодны. Открываете приложение доставки еды, выбираете любимый ресторан и блюдо. Затем идёте оформлять заказ, но ничего не происходит.
Ваше раздражение нарастает, поскольку с каждой минутой вы становитесь всё более голодными. Но есть и раздражение с другой стороны этой сделки: инженеры пытаются понять, в чём проблема, поскольку заказов становится меньше, а потери прибыли растут.
Это тот тип сценария, которого вы пытаетесь избежать, если вы работаете в команде SRE в Glovo, дочерней компании Delivery Hero и платформы доставки еды и продуктов по запросу, работающей в 23 странах Европы, Африки и Азии.
В статье рассказано об опыте использования Grafana Traces Drilldown.
🔥6👍2
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
Надо же, 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
OpenTelemetry
OpenTelemetry eBPF Instrumentation Marks the First Release
Following a significant collaboration between Grafana Labs, Splunk, Coralogix, Odigos and many other community members, we are thrilled to announce the first alpha release of OpenTelemetry eBPF Instrumentation, or OBI for short.
This event marks a significant…
This event marks a significant…
🔥8👍5❤1
Обучающие материалы о Grafana от самой Grafana
Узнаете то, о чем раньше не знали. Изучение каждого мини-курса займет 10-20 минут. Все описано в доступной форме в виде пошаговой инструкции.
Среди обучающих курсов:
🚀 Kubernetes Monitoring
🚀 Connect to a Prometheus data source
🚀 Visualize logs
🚀 Create logsalert rule
и многое другое.
@monitorim_it
Узнаете то, о чем раньше не знали. Изучение каждого мини-курса займет 10-20 минут. Все описано в доступной форме в виде пошаговой инструкции.
Среди обучающих курсов:
🚀 Kubernetes Monitoring
🚀 Connect to a Prometheus data source
🚀 Visualize logs
🚀 Create logsalert rule
и многое другое.
@monitorim_it
👍11🔥8
Continuous profiling for native code: Understanding the what, why, and how
Профилирование как метод отладки существует уже давно. В середине 2010-х годов, появился ряд продуктов, которые дали начало использованию этой технологии как четвёртого метода наблюдаемости. Появление eBPF сделали расширило его возможности.
В этой статье рассмотрены преимущества непрерывного профилирования и пример использования для получения наглядной информации о производительности кода.
Профилирование как метод отладки существует уже давно. В середине 2010-х годов, появился ряд продуктов, которые дали начало использованию этой технологии как четвёртого метода наблюдаемости. Появление eBPF сделали расширило его возможности.
В этой статье рассмотрены преимущества непрерывного профилирования и пример использования для получения наглядной информации о производительности кода.
🔥6👍4
Классический мониторинг уже не справляется с вызовами сложных ИТ-систем: он фиксирует сбои, но не раскрывает их причины.
Observability меняет подход — помогает понять взаимосвязи сервисов, качество работы и опыт пользователей. Подробнее об этом рассказал Антон Новоженин, технический директор GMONIT. В материале:
📌 ограничения традиционного мониторинга;
📌 особенности APM;
📌 ключевые принципы observability;
📌 преимущества сочетания подходов;
📌 тенденции, определяющие развитие систем анализа ИТ-инфраструктуры.
Переходите по ссылке, чтобы прочитать статью! 📖
Реклама. ООО "ХАЙПЕРСОФТЛАБ", ИНН 9705151703, erid 2Vtzqv6m13P
Observability меняет подход — помогает понять взаимосвязи сервисов, качество работы и опыт пользователей. Подробнее об этом рассказал Антон Новоженин, технический директор GMONIT. В материале:
📌 ограничения традиционного мониторинга;
📌 особенности APM;
📌 ключевые принципы observability;
📌 преимущества сочетания подходов;
📌 тенденции, определяющие развитие систем анализа ИТ-инфраструктуры.
Переходите по ссылке, чтобы прочитать статью! 📖
Реклама. ООО "ХАЙПЕРСОФТЛАБ", ИНН 9705151703, erid 2Vtzqv6m13P
👍8👎3❤2
Your Brain on Incidents
Опыт работы автора этой статьи дежурным начался в середине 2000-х. Было пять вечера пятницы, конец первой недели работы инженером-программистом в финансовой компании в Лондоне. Он как раз закрывал свою IDE на выходные, когда к столу, неловко улыбаясь, подошёл начальник. В руках у него были IBM Thinkpad, Blackberry и, несомненно, грузная ноша человека, которому нужно было сделать одолжение. Веселые истории и поучительный опыт из жизни дежурного.
Опыт работы автора этой статьи дежурным начался в середине 2000-х. Было пять вечера пятницы, конец первой недели работы инженером-программистом в финансовой компании в Лондоне. Он как раз закрывал свою IDE на выходные, когда к столу, неловко улыбаясь, подошёл начальник. В руках у него были IBM Thinkpad, Blackberry и, несомненно, грузная ноша человека, которому нужно было сделать одолжение. Веселые истории и поучительный опыт из жизни дежурного.
🔥4👍2👎1
Как продуктовые аналитики в Туту ловят аномалии в метриках
Рано или поздно в любом продукте встает вопрос о том, как успевать отлавливать аномалии в аналитических логах и метриках. В статье продуктовый аналитик из команды Отелей сервиса путешествий Туту расскажет о подходе к алертингу и поделится кодом, с помощью которого продуктовый аналитик может за пару часов самостоятельно настроить базовый алертинг.
Рано или поздно в любом продукте встает вопрос о том, как успевать отлавливать аномалии в аналитических логах и метриках. В статье продуктовый аналитик из команды Отелей сервиса путешествий Туту расскажет о подходе к алертингу и поделится кодом, с помощью которого продуктовый аналитик может за пару часов самостоятельно настроить базовый алертинг.
👍4🔥4👎1
Configuring PostgreSQL Logs: A Practical Guide
Анализ логов PostgreSQL даёт следующие преимущества:
🚀 Отладка и устранение неполадок: выявление медленных запросов, взаимоблокировок и проблем с подключением.
🚀 Оптимизация производительности: выявление узких мест, конфликтов блокировок и неэффективных шаблонов запросов.
🚀 Аудит и соответствие требованиям: регистрация того, кто, к чему, когда и откуда получил доступ, для обеспечения подотчетности и безопасности.
Проблема в том, что в большинстве боевых сред логирование по-прежнему выполняется неправильно. Некоторые регистрируют всё, генерируя столько данных, что они становятся бесполезными. Другие не регистрируют практически ничего, оставляя критические пробелы при снижении производительности или сбое.
В этой статье основное внимание уделяется поиску правильного баланса: настройке PostgreSQL для регистрации значимых событий, обеспечению компактности и эффективности журналов, а также созданию основы для бесшовной интеграции с современными фреймворками наблюдения, такими как OpenTelemetry.
@monitorim_it
Анализ логов PostgreSQL даёт следующие преимущества:
🚀 Отладка и устранение неполадок: выявление медленных запросов, взаимоблокировок и проблем с подключением.
🚀 Оптимизация производительности: выявление узких мест, конфликтов блокировок и неэффективных шаблонов запросов.
🚀 Аудит и соответствие требованиям: регистрация того, кто, к чему, когда и откуда получил доступ, для обеспечения подотчетности и безопасности.
Проблема в том, что в большинстве боевых сред логирование по-прежнему выполняется неправильно. Некоторые регистрируют всё, генерируя столько данных, что они становятся бесполезными. Другие не регистрируют практически ничего, оставляя критические пробелы при снижении производительности или сбое.
В этой статье основное внимание уделяется поиску правильного баланса: настройке PostgreSQL для регистрации значимых событий, обеспечению компактности и эффективности журналов, а также созданию основы для бесшовной интеграции с современными фреймворками наблюдения, такими как OpenTelemetry.
@monitorim_it
👍5🔥4
Специальное предложение для планирующих миграцию виртуализации
Компания ISPsystem запустила акцию «Мигрируем VMeste» — комплексное решение для перехода с российских платформ виртуализации на VMmanager (Продукт года по версии CNews Awards).
Ключевые преимущества программы:
• Лицензия VMmanager на 12 месяцев по цене технической поддержки
• Годовая лицензия BILLmanager Enterprise в подарок
• Экспертное сопровождение миграции специалистами ISPsystem
Условия участия:
- Приобретение годовой технической поддержки на количество мигрирующих хостов
- Регистрация в акции — до 31 декабря 2025 года
- Завершение всех миграций — до 31 декабря 2026 года
Программа предлагает экономически эффективный подход к переходу на современную российскую платформу виртуализации с профессиональной поддержкой на всех этапах.
Детали акции доступны на официальном сайте ISPsystem.
Реклама. АО «Экзософт»
Компания ISPsystem запустила акцию «Мигрируем VMeste» — комплексное решение для перехода с российских платформ виртуализации на VMmanager (Продукт года по версии CNews Awards).
Ключевые преимущества программы:
• Лицензия VMmanager на 12 месяцев по цене технической поддержки
• Годовая лицензия BILLmanager Enterprise в подарок
• Экспертное сопровождение миграции специалистами ISPsystem
Условия участия:
- Приобретение годовой технической поддержки на количество мигрирующих хостов
- Регистрация в акции — до 31 декабря 2025 года
- Завершение всех миграций — до 31 декабря 2026 года
Программа предлагает экономически эффективный подход к переходу на современную российскую платформу виртуализации с профессиональной поддержкой на всех этапах.
Детали акции доступны на официальном сайте ISPsystem.
Реклама. АО «Экзософт»
🔥4👎2
Масштабируемый мониторинг: Настраиваем VictoriaMetrics в HA-конфигурации с VMAgent и Grafana
Когда стек мониторинга перерастает масштаб нескольких серверов, классический Prometheus показывает свои ограничения:
🚀 Проблемы с производительностью при миллионах метрик
🚀 Вертикальное масштабирование
🚀 Сложности с долгосрочным хранением
🚀 Ограниченные возможности репликации
Очередная статья про настройку VM
@monitorim_it
Когда стек мониторинга перерастает масштаб нескольких серверов, классический Prometheus показывает свои ограничения:
🚀 Проблемы с производительностью при миллионах метрик
🚀 Вертикальное масштабирование
🚀 Сложности с долгосрочным хранением
🚀 Ограниченные возможности репликации
Очередная статья про настройку VM
@monitorim_it
🔥6👍4👎4
Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
🔥12❤2👍1
Свой мини-«мониторинг как сервис»: Python-демон + Next.js-дашборд
В какой-то момент автор этой статьи поймал себя на том, что в третий раз пишет похожий набор проверок (API, страницы, базы, очереди, TLS, Docker…) и снова открывает это все в голых логах или простых HTML-страничках. В итоге он сел и сделал отдельный проект — мониторинг-демон на Python + Next.js-дашборд. Подробности в статье.
Репыч на Гитхабе
@monitorim_it
В какой-то момент автор этой статьи поймал себя на том, что в третий раз пишет похожий набор проверок (API, страницы, базы, очереди, TLS, Docker…) и снова открывает это все в голых логах или простых HTML-страничках. В итоге он сел и сделал отдельный проект — мониторинг-демон на Python + Next.js-дашборд. Подробности в статье.
Репыч на Гитхабе
@monitorim_it
👍7🔥2👎1
RUM на Prometheus: пишем за вечер свой простой и надёжный фронтенд-мониторинг
В разработке давно привыкли смотреть на потребление процессора и памяти, на ошибки и бизнес-метрики, но метрики скорости фронтенда почему-то до сих пор игнорируют даже в крупных компаниях. В этой статье автор рассказывает, как решить эту задачу, сделав свой RUM поверх Prometheus. Читать дальше на Хабре.
@monitorim_it
В разработке давно привыкли смотреть на потребление процессора и памяти, на ошибки и бизнес-метрики, но метрики скорости фронтенда почему-то до сих пор игнорируют даже в крупных компаниях. В этой статье автор рассказывает, как решить эту задачу, сделав свой RUM поверх Prometheus. Читать дальше на Хабре.
@monitorim_it
🔥13👍3❤1
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
В очередной раз натолкнулся на статью с предложением снизить расходы на 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
🔥14👍6❤2