Всем привет! За последние пять лет мы достаточно часто сталкивались с запросами на мониторинг Java приложений. Собрав основные моменты по мониторингу Java, мы решили написать данный пост.

Сегодня мы с вами рассмотрим, что такое Full Stack мониторинг и чем он отличается от привычного “уху” понятию мониторинга, нюансы Full Stack мониторинга для Java и сложности мониторинга микросервисных приложений на Java. Расскажем, как мы реализуем Full Stack мониторинг с помощью OpenSource стандартов и платной платформы. 

Давайте определимся, что мы называем Full Stack мониторингом?

Full stack мониторинг – это подход в мониторинге производительности приложений, который подразумевает под собой мониторинг всего стека, что включает в себя:

Мониторинг приложений – сбор метрик приложения, сбор трейсов транзакций, обеспечение видимости на уровне кода и т.д.

Мониторинг инфраструктуры – метрики хостов, процессов, контейнеров и т.д.

Мониторинг конечных пользователей – сбор метрик с браузера пользователя, мобильного приложения, синтетические проверки и т.д.

Привет, друзья! Приглашаем на вебинар, посвященный продукту для углубленного мониторинга баз данных – DBmarlin, который:

– контролирует производительность баз данных – MySQL, MariaDB, PostgreSQL, Oracle, MS SQL Server, развернутых как в своей инфраструктуре, так и у облачного провайдера (AWS, Azure);

– предоставляет детальную видимость работы серверов, на которых развернуты БД;

– собирает statements и wait states, благодаря чему вы видите, на что именно тратится время внутри БД во время исполнения SQL запроса;

– автоматически обнаруживает изменения в объектах схемы БД, параметрах БД, собирает планы выполнения запросов, чтобы вы видели их влияние на производительность.

- регистрирует релизы и другие события для анализа их влияния на БД.

При возникновении проблемы с запросом к БД, инструменты мониторинга и APM, не специализирующиеся на БД, покажут вам SQL-запрос в трейсе, который долго исполнялся. Все, что вы сможете увидеть – это текст SQL запроса и длительность его исполнения. Причина, по которой он был таким медленным остается неизвестной. DBmarlin покажет, в чем именно была проблема в БД - вы увидите, например, что вызывает блокировку.

На вебинаре мы покажем и расскажем:

– Какие задачи должен решать современный продукт для мониторинга баз данных?

– Кто выигрывает от улучшения мониторинга СУБД (спойлер – не только DBA).

– Что отличает продукт DBMarlin от конкурентов?

Регистрация доступна прямо на этой странице ниже или по ссылке.

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

Всем привет. Сегодня мы хотели бы поговорить про выявления аномалий в микросервисной среде. Данный пост является краткой выжимкой нашего 40 минутного доклада, который мы делали на онлайн конференции DevOps Live 2020 и, чтобы не писать лонгрид, мы решили сфокусироваться на обзоре инструментов выявления аномалий в распределении значений метрик для автоматизации мониторинга микросервисов, которые возможно быстро начать использовать любой команде.

Тема детектирования аномалий сейчас очень актуальна, так как с переходом на микросервисы для SRE и DevOps приоритет задач, связанных с преобразованием алертов в осмысленный сигнал, снижением MTTD и упрощением настройки алертов в мониторинге распределенных сред значительно повысился.

На прошлой неделе мы выложили пост про то, как мы мониторим backend и микросервисную инфраструктуру с помощью Instana, и пообещали написать продолжение про мониторинг frontend.

В итоге мы решили не ограничиваться обзором Instana в качестве инструмента контроля frontend, а копнуть немного глубже и рассказать, для чего вообще нужен End User Monitoring, с какими проблемами производительности фронта мы сталкиваемся чаще всего, какие мы используем сценарии работы с собранными данными, и как Instana помогает нам контролировать пользовательский опыт в целом.

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

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

Мы прошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили на две части.