Все, что нужно знать про мониторинг — Transcript

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

Key Takeaways

Мониторинг должен обнаруживать проблемы раньше пользователей, иначе он неэффективен.
Современный мониторинг требует комплексного подхода с метриками, логами и трассировками.
Prometheus и Grafana — ключевые инструменты для мониторинга современных распределённых систем.
Наблюдаемость помогает понять не только что сломалось, но и почему это произошло.
Мониторинг бизнес-метрик критичен для оценки реального состояния системы с точки зрения пользователей.

Summary

Мониторинг — ключевой инструмент для раннего обнаружения проблем в системах, чтобы не дожидаться сигналов от пользователей.
История мониторинга начинается с простых проверок доступности серверов и протокола SNMP для сетевого оборудования.
Методология USE (Utilization, Saturation, Errors) помогает анализировать состояние ресурсов сервера.
Объекты мониторинга делятся на уровни: железо, ОС, сеть, приложения, базы данных, контейнеры и бизнес-метрики.
Появление контейнеров и микросервисов изменило подход к мониторингу, традиционные модели перестали работать.
Prometheus ввёл пул-модель сбора метрик, многомерные лейблы и специализированную TSDB, став стандартом CNCF.
Grafana стала стандартом визуализации метрик, дополняя Prometheus.
Появилась концепция наблюдаемости (observability), включающая метрики, логи и трассировки для комплексного анализа.
Важность мониторинга бизнес-метрик для своевременного обнаружения инцидентов, невидимых на технических графиках.
В видео также анонсирована образовательная платформа Просто Devops с курсами и практикой в браузере.

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

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

Speaker A

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

Speaker A

мониторинг. А вместе с этим подходом меняются инструменты. И сегодня мы как раз рассмотрим всю эту эволюцию. Как системы мониторинга развивались от обычного пинга сервера до наблюдаемости за тысячами микросервисов, какие методологии придумали по пути и зачем.

Speaker A

Это канал Просто Devops. И мы начинаем. Переместимся в восьмидесятые-девяностые годы. В то время сервер - это очень дорогая физическая машина, которая годами стоит в стойке. Таких машин, в принципе, немного. У каждой есть своё имя, и админы, ответственные за эти

Speaker A

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

Speaker A

для этого были очень простые инструменты. Пинк отвечал на вопрос, доступна ли машина в сети. CS собирал логи в одно место, а в восемьдесят восьмом году появился SNMP, протокол опроса сетевого железа. То есть система мониторинга ходила по роутерам и

Speaker A

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

Speaker A

потом вырос RRD Tool. Это кольцевая база под временные ряды, на который потом поднялось целое поколение инструментов.

Speaker A

А на рубеже веков пришли большие системы мониторинга, главным из которых стал Нагиос в 1999 году, который почти на два десятилетия стал синонимом инфраструктурного мониторинга, а рядом с ним поселился Какти, как удобный веб-фontнд для графиков. Модель у всех этих систем была одинаковая. Есть список

Speaker A

хостов, мы их регулярно опрашиваем и если что-то вышло за порог, шлём арт. Тогда же родилась первая методология, которая, в принципе, используется и сегодня. Сформулировал её инженер Брендон Грег. Называется методология use. Идея методологии заключается в том, что для каждого ресурса системы, будь то

Speaker A

процессор память диск сеть надо смотреть три вещи. Первая из них - это utilizли, то есть насколько ресурс занят. Следующее - это saturation, то есть сколько работы скопилось сверх того, что он успевает переварить. По сути, это длина очереди. И третья

Speaker A

метрика - это ирс, то есть ошибки. То есть эта методология смотрит снизу вверх от железа. З отвечает на вопрос, какому ресурсу плохо. А появился этот метод именно в парадигме хостов, где ресурс - это понятная физическая вещь. И, как я

Speaker A

уже сказал, эта методология до сих пор прекрасно используется для наблюдения за ресурсами сервера. А сейчас я хочу поделиться с вами важной новостью. Мы запустили собственную платформу просто devvobs.ru. Сейчас на ней три программы.

Speaker A

две полностью бесплатные введения в IT и введение в DevOps, а также платный DevOpsobs Bootcam. Внутри вы найдёте не только видео, а к каждому видео идёт конспект, чтобы то же самое можно было спокойно повторить в тексте. Есть большие подробные статьи с картинками и

Speaker A

схемами, и есть интерактивы, например, собрать схему архитектуры своими руками или пройти RPG-сценарий по мотивам реальных рабочих ситуаций. А в буткемпе есть то, ради чего всё и затевалось.

Speaker A

Практика в настоящем Linux-терминале прямо в браузере не нужно ничего устанавливать на свой компьютер. Просто открываете терминал и решаете задачу.

Speaker A

Причём это не только про Linux. Ansible, Teroформ, Kubernetis и всё остальное тоже под рукой через тот же терминал и встроенную среду разработки. Если тема вам близка, загляните, ссылка в описании. А мы возвращаемся к делу. А прежде чем идти дальше по истории,

Speaker A

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

Speaker A

операционной системы и хоста. Load, average, процессы, файловые дескрипторы, swop, живыли сервисы. Про Load average у нас есть отдельное видео. Там мы подробно разбирали, что это за метрика и почему она такая полезная. Следующий уровень - это сеть, доступность, потери

Speaker A

пакетов, задержки, состояния портов, наследие того самого SNMP. Поднимаемся на слой выше, и там начинается прикладной уровень. Это отдельная дисциплина под названием APM, мониторинг производительности приложений, время ответа, пропускная способность, доля ошибок и трассировка запроса через сервисы. Рядом идут базы данных со

Speaker A

своими метриками: запросы в секунду, медленные запросы, размер пуласоединений, лак репликации, а дальше контейнеры и kubernetis. И на самом верху находятся бизнес-метрики. Это могут быть регистрации, заказы, какая-нибудь выручка в минуту или конверсии. И тут есть один неочевидный момент. Технически здоровая система, где

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

этого. Пришли контейнеры и микросервисы, которых раньше не было. Раньше были просто серверы с именами, а теперь это сотни эфемерных контейнеров, которые постоянно перезапускаются. У них нет привычных имён, а есть только временные адреса, и их количество постоянно изменяется под нагрузкой. И как

Speaker A

опрашивать по списку хостов то, чего в этом списке ещё минуту назад не было, а через минуту уже не будет. Модельгиос, где вы заранее прописали машины и ходите по ним, здесь уже работать не будет. Но решение пришло и пришло достаточно

Speaker A

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

Speaker A

- это пул-модель. Прометеус сам ходит по нужным целям и соскребает с них метрики по HTTP на endpите/matrix.

Speaker A

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

Speaker A

Метрика - это не просто какая-то абстрактная нагрузка. Метрика - это число с набором пар, ключ, значение, метод запроса, код ответа и имя сервиса.

Speaker A

По этим лейблам потом можно группировать данные как угодно. И третье нововведение - это своя база под временные ряды TSDB, заточенная именно под метрики. Prтеу стал вторым проектом, который приняли в фонд CNCF после Кубернетиса. И это многое говорит о его роли в современной

Speaker A

инфраструктуре. Рядом с Прометеусом встала графана, которая с 2014 года стала фактическим стандартом для виртуализации метрик. Сами метрики живут в Прометеосе, а красивые дашборды графа нарисует поверх.

Speaker A

И под этот новый сервисоориентированный мир родилась вторая методология зеркальная к use. Называется эта методология Red. Её придумал Том Уилки.

Speaker A

Здесь для каждого сервиса нужно смотреть три вещи. Первая из них - рейд, то есть сколько запросов в секунду. Вторая, errors, сколько из них с ошибкой. И третье, duration, то есть сколько времени занимает запрос. И в целом можно сказать, что это взгляд со стороны

Speaker A

пользователя, а не со стороны железа. Если мы сравним с UE, то определяет, какому ресурсу плохо, а Red определяет, плохо ли нашим пользователям. Обе эти методологии нужны, они друг друга дополняют. С ростом сложности сам мониторинг тоже претерпел изменения даже

Speaker A

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

Speaker A

Этот подход будет работать ровно до того момента, пока мы заранее знаем, что может сломаться. Но когда у нас система состоит из огромного количества микросервисов, то может сломаться то, что мы не предвидели, и сломаться это может странными способами. Observability

Speaker A

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

Speaker A

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

Speaker A

для графиков и алёртов, но у них есть предел. Метрика говорит, что стало плохо, но не говорит, что именно случилось с конкретным запросом. И тут мы переходим ко второму столпу. Это логи, то есть записи о событиях. Что произошло в конкретный момент, с какой

Speaker A

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

Speaker A

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

Speaker A

каждом шаге. И трейсы отвечают на вопрос, где в цепочке был затык. А стандартом всего этого дела стал Open Temметри, проект, родившийся в мае 2019 года из слияния двух более ранних: Openensus от Google и Open Tracing. А его смысл заключается в том, чтобы быть

Speaker A

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

Speaker A

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

Speaker A

приводит к той или иной проблеме? И до недавнего времени, чтобы это узнать, нужно было вручную запускать специальные программы профайлеры. А тут, получается, мы это делаем непрерывно и почти бесплатно по ресурсам. Работает непрерывное профилирование через технологию ядра Linux под названием

Speaker A

EBPF, которая позволяет снимать стек вызовов всей системы вообще без изменения кода приложений и без перезапуска сервисов. И профили, как вы уже могли понять, отвечают на вопрос, почему именно этот код тормозит. Ну а чтобы совсем было понятно, можно привести вот такой вот пример. Допустим,

Speaker A

некая команда ловила периодическое замедление в конкретном контейнере. При этом воспроизвести его они не могли.

Speaker A

Обычные сигналы ничего не показывали, поставили профилирование и увидели процессор еле не эти контейнеры, а посторонний процесс, который в их контейнер воткнул сам облачный провайдер. И этот процесс отжирал 10-15% процессорного времени. Ни метрики, ни логи, ни трейсы этого бы не показали,

Speaker A

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

Speaker A

Называется она кардинальность. Напомню, метрика в Прометеусе - это число плюс набор лейблов. Например, время ответа с лейблами метод равно get и код равно 200. Каждая уникальная комбинация лейблов - это отдельный временной ряд, который Прометеус хранит в памяти. И

Speaker A

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

Speaker A

А теперь представьте, что вы решили добавить в метрику Label User ID, чтобы видеть каждого пользователя отдельно.

Speaker A

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

Speaker A

значений например идентификатор запроса, email, полный URL с параметрами. И ровно поэтому в лейблы кладут то, у чего мало значений, и почему реально в будущем мы будем группировать. Метод, код, имя сервиса регион можно использовать в качестве лейбла. А вот уникальные идентификаторы

Speaker A

так класть нельзя. И для этого как раз-таки есть логи и трейсы. И вот мы понимаем, как собирать огромное количество сигналов. И теперь встаёт вопрос, как по ним понять, что система работает исправно или же пора что-то чинить. Для этого придумали специальные

Speaker A

аббревиатуры которые кстати даже иногда спрашивают на собеседованиях. И звучат они как SLI, SL и SLA. Давайте пойдём по порядку. SLI - это индикатор, то есть измеряемый показатель здоровья.

Speaker A

Например, SLI может быть доля успешных запросов от всех пользователей. Просто число, которое можно посчитать. Сло цель, то есть внутренняя планка по конкретному показателю. Например, 99,9% успешных запросов за 30 дней. Это то, к чему команда стремится сама для себя. А

Speaker A

SL - это соглашение, то есть контракт с клиентом, где за нарушение планки прописаны штрафы. Сла всегда мягче, чем внутренне СЛО, чтобы был запас. И из этих показателей вырастает идея бюджета ошибок, потому что если наша цель 99,9%, значит оставшиеся 0,1%

Speaker A

мы официально можем сломать. Это зашито в бюджет. И этот бюджет можно осознанно тратить на риск, на выкадку новых фич.

Speaker A

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

Speaker A

Но собрать метрики мало, надо ещё правильно на них реагировать. И тут есть отдельная культура. Главная проблема реального мониторинга не в нехватке алёртов, а в их избытке. Когда система шлёт огромное количество уведомлений ежедневно, из которых почти все неважные, дежурный инженер просто

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

Rate, то есть скорость выгорания. Burnate показывает, как быстро вы проедаете бюджет ошибок. Если он равен единице, это означает, что вы потратите весь бюджет ровно к концу периода. То есть это норма. Если же ошибки летят так, что бюджет должен сгореть в

Speaker A

несколько раз быстрее срока, то это очень плохо и нужно немедленно реагировать. А если бюджет утекает чуть-чуть быстрее нормы, то достаточно завести задачу на разбор этого инцидента на будущее. И ещё один момент, когда инцидент всё же случился и его починили,

Speaker A

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

Speaker A

стекамониторинга. Мы не будем глубоко погружаться в каждый, но просто посмотрим, что нужно и из чего собирают системы на практике. Для стандартом является Прометеус. Рядом с ним стоит Viктория Matrix, совместимая с ним база, которая известна тем, что ест кратно

Speaker A

меньше памяти процессора, поэтому её особенно любят там, где огромные объёмы. Если одного Прометеуса не хватает, то поверх ставят хранилище вроде Мимира или Таноса для долгого и масштабного хранения. Визуализация почти всегда графана. Она умеет подключать огромное количество источников и стала

Speaker A

практическим монополистом среди дашбордов. Для логов есть два лагеря. Классика - это стек Elastic Search Lockstash Kibana, у которого после смены лицензии появился открытый Fork Open Search. Но есть и другой, более лёгкий подход к логированию на базе графана Локи, который называют Прометеусом для

Speaker A

логов. Он дешёвый, потому что индексирует не весь текст, а только лейблы. Для трейсов используют Джаггер и графана темпа. При этом существует отдельный класс платформ, всё в одном. В качестве примера можно привести DataDG как самого крупного игрока. Такие платформы удобные, но платные. И если

Speaker A

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

Speaker A

И здесь знакомые всем Zabкс и Nagios. И на этом, в принципе, всё. Если ролик понравился, ставьте лайк, подписывайтесь на канал и заходите в наш Telegram.

Speaker A

Ссылка находится в описании. Всем спасибо за просмотр. Всем пока-пока. M.

Topics:мониторингDevOpsPrometheusGrafanaнаблюдаемостьмикросервисыконтейнерыметрикилогированиеинфраструктура

Frequently Asked Questions

Что такое методология USE в мониторинге?

Методология USE анализирует три ключевые метрики для каждого ресурса: Utilization (загрузка), Saturation (напряжённость) и Errors (ошибки), помогая понять состояние железа и ресурсов.

Почему традиционные модели мониторинга не подходят для микросервисов?

Микросервисы и контейнеры динамичны, имеют эфемерные адреса и постоянно меняются, поэтому модели с фиксированным списком хостов неэффективны. Prometheus решает эту проблему пул-моделью сбора метрик.

В чем отличие мониторинга от наблюдаемости (observability)?

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

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →