Автор статьи: Рустем Галиев
IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM
Привет, Хабр! Сегодня поговорим об основных практиках мониторинга в рамках SRE.
Если вы не можете найти никаких проблем, значит, их не существует! В контексте видимости систем можно предположить, что если мы не обнаружим никаких проблем, скорее всего, у нас есть слепое пятно.
Observability или же Наблюдаемость - одна из основ SRE
Мониторинг IT-систем, несомненно, является обязательным требованием для любого решения или сервиса. Это началось еще с операционной системой Unix. Если вы также стар, возможно, вы использовали такие инструменты, как top, vmstat или syslog, для мониторинга процессов, их производительности и использования ресурсов. Мы отслеживаем использование и скорость отклика ИТ-ресурсов (или служб), чтобы определить, доступна ли система, работающая поверх них и работает ли она с номинальными параметрами. С тех пор многое изменилось, поскольку системы стали более сложными и распределенными. Мониторинг расширился от локально выполняемых инструментов до удаленного набора измерений, также называемого телеметрией, чтобы минимизировать собственный след (или потребление ресурсов).
Сейчас же основа мониторинга это MELT: Metrics, Events, Logs, and Traces (метрики, события, логи и трассировка) и у него есть собственно методы или же Best Practices, которые мы можем применять. Наиболее популярные это USE, RED, LETS, STELA, но прежде чем прийти к ним, давайте разберемся с основной базой мониторинга и начнем с мониторинга инфраструктуры
В типичной системе, состоящей из инфраструктуры и приложений, незаменимые ИТ-ресурсы требуются уровню приложений для работы в соответствии с его архитектурой. SRE отвечают за управление этими ресурсами, поэтому им необходимо следить за тем, чтобы платформа мониторинга контролировала их. Другими словами, SRE несут прямую ответственность за эффективность наблюдаемости. В любом решении у нас есть как минимум следующие критически важные ресурсы: вычислительные ресурсы, сеть, хранилище, база данных и промежуточное ПО (middleware). Сейчас мы пройдемся по каждому из них.
Вычислительные ресурсы
Это, вероятно, ИТ-актив, который больше всего трансформировался с течением времени. Мы начали с физических серверов, для которых нам нужно было приобрести выделенное оборудование, подключить его к стойке центра обработки данных и включить питание. Хотя это все реже и реже можно увидеть, у нас все еще есть такие случаи. В этих сценариях нам необходимо отслеживать аппаратные компоненты и операционную систему, работающую на сервере. Многие аппаратные компоненты имеют датчики и обеспечивают измерения для программного обеспечения для мониторинга оборудования, такие как температура ЦП, скорость вращения вентилятора и напряжение батареи CMOS. На уровне операционной системы инструменты мониторинга могут предоставить подробное представление о ресурсах сервера, включая загрузку ЦП, использование диска, транзакции ввода-вывода, жизненно важные процессы, запущенные процессы, потоки на процесс и потребление памяти.
По мере развития вычислительных ресурсов у нас появились виртуальные машины (ВМ), которые в настоящее время широко используются во многих системах. Виртуальные машины — это не что иное, как процессы, работающие внутри хост-машины, которые контролируются и управляются гипервизором. Эти процессы имитируют виртуальный сервер, на котором есть все, что есть на «голом железе», за исключением аппаратной части. В этом случае мы не отслеживаем аппаратный уровень, так как за это отвечает поставщик облачных услуг. Если мы запускаем виртуальные машины в локальном центре обработки данных, нам необходимо отслеживать как сам гипервизор и операционную систему хоста, так и сами виртуальные машины. Виртуальные машины контролируются, как и любая операционная система.
Если мы пойдем дальше в модели внедрения облака, то у нас будут контейнеры в качестве вычислительного ресурса. Контейнеры — это виртуализированные процессы, которые имеют не только виртуальную операционную систему и аппаратное обеспечение, но и дополнительные системные и прикладные библиотеки. Они управляются таким инструментом, как Kubernetes (K8s). Способ, которым мы контролируем контейнеры, радикально отличается от виртуальных машин и физических серверов. Поскольку они предназначены для распределенных вычислений, где нагрузка разбивается на небольшие потоки, а каждый поток обрабатывается отдельным контейнером, мы обычно отслеживаем общий объем загрузки ЦП, использования памяти или других ресурсов, используемых всеми контейнерами вместе.
Сеть
Это группа ИТ-ресурсов, которую труднее всего выделить из-за ее сложности. Во-первых, сетевые устройства имеют различные сетевые функции и могут быть основаны на аппаратном обеспечении «белого» или «черного ящика». Поскольку сетевые технологии всегда отличались от остальных ИТ-технологий, неудивительно, когда мы слышим о чем-то вроде проектирования надежности сети (NRE). Хотя мы согласны с тем, что это интригующая идея иметь отдельную специализацию SRE для сетей, с появлением программно-определяемых сетей (SDN) кажется, что она может вообще не прижиться.
Мы можем начать с обсуждения различных типов сетевых устройств, которые могут существовать. Среди них есть маршрутизаторы, коммутаторы, концентраторы, мосты, шлюзы и репитеры. Это могут быть как физические, так и эмулированные устройства. Обычно в них включен простой протокол управления сетью (SNMP), поэтому мониторинг устройств может выполняться с помощью ловушек SNMP для получения важных событий от этих устройств.
Сеть использует множество сетевых протоколов для соединения устройств на нескольких уровнях. Рассматривая модель взаимодействия открытых систем (OSI), также известную как ISO/IEC 7498, вы можете увидеть семь уровней, включая физический, канальный, сетевой, транспортный, сеансовый, уровень представления и прикладной уровень. Для каждого уровня существуют отдельные протоколы в зависимости от производителя и типа соединения. Это создает большую комбинаторную проблему для систем сетевого мониторинга, которым необходимо обрабатывать большой и объемный функционал
По этой причине большинство сетевого оборудования уже имеет встроенные функции мониторинга. SNMP является отраслевым стандартом де-факто, и его также можно использовать для сбора данных сетевой телеметрии.
Со временем сетевой мониторинг перешел от простой проверки сетевых устройств и протоколов, которые делают возможным их работу в сети, к более масштабируемой, надежной, мультивендорной и элегантной возможности, называемой мониторингом производительности сети (NPM). В соответствии с этой концепцией, данные инструменты предоставляют очень интересные функции, среди которых:
Тепловая карта Wi-Fi, 4G или 5G: анализирует интенсивность и мощность сигнала Wi-Fi, 4G или 5G для области.
Сканирование сетевых устройств: обнаруживает сетевые устройства в определенной подсети с помощью SNMP (или другими способами) и обеспечивает их мониторинг.
Тестирование производительности сети: это включает в себя постоянное тестирование производительности, доступности и задержки сети для выявления ухудшения или сбоев. Это позволяет более активную позицию для крупных сетей.
Инструменты диагностики сети: предоставляет визуальные инструменты с аналитикой, помогающие сетевым инженерам или SRE устранять проблемы с производительностью сети.
Как и в случае с вычислительными ресурсами, виртуализация достигла сети. Многие устройства сетевого оборудования, такие как маршрутизаторы или балансировщики нагрузки, доступны как виртуализированные устройства или процессы, работающие внутри виртуальной машины. Они даже могут работать как контейнеры. Это называется виртуализацией сетевых функций (NFV). Параллельная технология виртуализации — это программно-определяемые сети (SDN), в которых программный сетевой контроллер направляет трафик в сети. Например, в SDN маршрутизация и брандмауэр выполняются программным обеспечением уровня управления над данными приложений, протекающими через эту сеть.
В настоящее время NFV и SDN являются обычным явлением, в основном в гибридных облачных средах. SRE должны понимать эти технологии и работать с надлежащим инструментом мониторинга производительности сети, который также нацелен на эти сетевые технологии.
Хранилище
Если вы в настоящее время не работаете в датацентре, вы не будете часто видеть настоящие устройства хранения. Вероятно, это одна из первых групп ресурсов, которая была виртуализирована и обновлена. В основном она предлагается в качестве услуги приложениям в локальной или облачной инфраструктуре.
Хранилище также развивалось быстрыми темпами, как и сети. Все началось с простых аппаратных компонентов (называемых жесткими дисками) внутри микрокомпьютеров, где требовалась постоянная память. Позже они стали самостоятельными устройствами с выделенным аппаратным обеспечением и встроенным программным обеспечением (прошивкой). Вначале у нас были физические диски. Позже эти диски превратились в виртуальные диски на основе формирования массивов физических дисков (технология Redundant Array of Independent Disks (RAID)), а теперь благодаря экстремальной виртуализации возможность хранения представляет собой программный объект внутри облачной платформы, находящийся в распоряжении приложения.
Мониторинг хранилища превратился из простого вопроса о том, сколько места осталось для приложений, в мониторинг производительности хранилища, где он оценивает следующие элементы:
Текущая мощность, текущее потребление и прогнозы на будущее;
Порты устройств, каналы, контроллеры, физические диски и группы дисков, работоспособность и производительность;
Пропускная способность физического диска, дискового массива и дискового ввода-вывода (I/O);
Вычисление запроса хостов.
Базы данных
Будь то система управления реляционной базой данных (RDBMS) или система управления нереляционной базой данных, они являются ресурсами, ответственными за обработку и управление структурами данных и моделями. Большинство приложений используют одну или несколько баз данных для хранения и извлечения данных с помощью запросов. Обычно используется база данных NoSQL, которая является еще одним термином для нереляционной базы данных.
Мы развертываем РСУБД или БД NoSQL для обслуживания приложения различными способами. Их можно установить на виртуальную машину, развернуть как контейнеры или использовать как службу в облачной среде (также известную как база данных как сервис (DBaaS)). В качестве еще одного ключевого ИТ-ресурса нам необходимо убедиться, что все базы данных находятся в списке целей мониторинга.
Инструменты мониторинга базы данных должны оценивать следующее:
Операторы SQL: РСУБД использует язык структурированных запросов (SQL) для записи и извлечения данных из таблиц. Эти операторы SQL расширяются до планов, и для расчета набора данных для извлечения и чтения из хранилища требуются вычислительные затраты. Медленные операторы могут привести к зависанию систем.
Блокировки базы данных: РСУБД может получать несколько операторов SQL для изменения одного и того же набора данных. Каждый раз, когда запрашивается изменение набора данных, происходит блокировка БД, чтобы гарантировать, что никакой другой процесс не сможет его изменить. Длинные блокировки очень дороги и могут сделать систему ненадежной.
Производительность базы данных: измеряется путем непрерывной оценки работоспособности и трафика запросов к базе данных, а также того, как базовое хранилище влияет на операции БД.
Middleware
Программное обеспечение промежуточного слоя обеспечивает нейтральную платформу среды выполнения приложений, которая обеспечивает переносимость приложений, абстрагируя базовую платформу и сетевые технологии от разработчиков приложений. Ресурсы промежуточного программного обеспечения известны своим разнообразием. Существуют десятки поставщиков и сотни различных программных продуктов и услуг. Один из способов их классификации выглядит следующим образом:
Платформы приложений. Этот сегмент содержит среды выполнения приложений и платформы, на которых работает бизнес-логика и уровни представления, включая такие технологии, как приложения и веб-серверы.
Гибридная интеграция: этот сегмент содержит технологии интеграции корпоративных приложений (EAI), такие как ПО промежуточного слоя, ориентированное на сообщения, управление бизнес-процессами и продукты промежуточного ПО для бизнеса (B2B).
Безопасность приложений: этот сегмент содержит инструменты управления идентификацией приложений, такие как серверы каталогов и диспетчеры доступа.
Аналитика больших данных: этот сегмент относится к продуктам промежуточного программного обеспечения, отвечающим за механизмы и инфраструктуру аналитики больших данных. Он включает в себя распределенную обработку больших данных и унифицированные инструменты аналитики.
Инженерные системы: этот сегмент содержит решения промежуточного программного обеспечения, основанные на комбинации специализированного оборудования со встроенным в него программным обеспечением промежуточного слоя. Он охватывает от простых однофункциональных устройств (обычно размером 1U-7U для монтажа в стойку) до сложных многофункциональных интегрированных систем (обычно занимающих целую стойку).
Инструменты DevOps: этот сегмент содержит продукты промежуточного программного обеспечения, используемые как часть инфраструктуры конвейера доставки DevOps.
Неудивительно, что программные продукты промежуточного программного обеспечения были перенесены на поставщиков облачных услуг с использованием модели «программное обеспечение как услуга» (SaaS). В этом сценарии гиперскейлер отвечает за управление промежуточным ПО и его мониторинг.
Каждая категория ПО промежуточного слоя имеет определенные требования к мониторингу. Рекомендуется проверять технические характеристики каждого продукта, чтобы ознакомиться с рекомендациями по мониторингу. Кроме того, существует несколько инструментов мониторинга, способных отслеживать функции и службы промежуточного программного обеспечения.
Мы охватили все цели мониторинга для уровня инфраструктуры, но как насчет приложений? APM!
На самом деле, про мониторинг на стороне приложений могу сказать не так много, ибо это все таки зона ответственности разработчиков. Им лучше знать, как мониторить то, что они разрабатывают. Этот тип мониторинга оценивает приложение с точки зрения пользователя. Он предоставляет хороший уровень подробной информации для выявления проблем, связанных с производительностью приложения. В APM можно выделить:
API-интерфейсы очень распространены в приложениях, использующих шаблон архитектуры микросервисов. Они предоставляют услуги другим приложениям через веб-интерфейс. Этот тип мониторинга гарантирует, что API работают должным образом с точки зрения производительности и точности данных.
Синтетический мониторинг пользователей основан на технологии ботов или других методах имитации конечного пользователя для имитации взаимодействия пользователя с приложением или веб-службой. Этот тип мониторинга предоставляет более точные данные о производительности функциональных возможностей приложения, поскольку он проверяет весь поток взаимодействия.
Мониторинг реального пользователя (RUM) или мониторинг цифрового опыта (DEM) отслеживает взаимодействие с пользователем внутри приложения и посредством его взаимодействия с пользовательским интерфейсом приложения (UI).
BAM - самый интересный вид мониторинга для бизнеса. Он отвечает за оценку ключевых показателей эффективности бизнеса (KPI) на основе систем мониторинга ИТ. BAM не может работать без предыдущих типов мониторинга, так как построен на их основе. Кроме того, деловая активность должна быть сопоставлена с базовыми ИТ-процессами, системами и транзакциями — например, сколько продаж происходит на портале электронной коммерции с течением времени.
Ну что касается основ того, что мы должны мониторить - разобрались, теперь к практикам и методикам
Задержка, ошибки, трафик и насыщение - LETS или же Goodle 4 Golden Signals
Это исходная версия Google с одним небольшим изменением порядка создания этой аббревиатуры:
Latency: задержка — это время, необходимое для ответа на запрос пользователя. Представьте, что вы заходите на портал интернет-банкинга. Первое, что вы поймете, это сколько секунд потребуется, чтобы показать вам портал после того, как вы нажмете на кнопку. Это KPI для систем, которые обслуживают пользователей. Любая деградация или медлительность сразу скажется на этом показателе. Кроме того, такие ошибки, как HTTP 404 (страница не найдена), имеют гораздо меньшую задержку, чем действительная страница. Требуется различать задержку для хороших и плохих ответов.
Errors: нам нужно знать не количество ошибок, которые получают пользователи отслеживаемой системы, а скорее соотношение ошибок (коды HTTP 50x) и успешных ответов (HTTP 20x). Это означает, что этот сигнал представляет процент успешных ответов по отношению к общему количеству запросов, и по этой причине его иногда называют сигналом частоты ошибок. Кроме того, сбой не ограничивается нежелательными HTTP-кодами. Вы можете определить условия, при которых ответ считается неудачным. Например, если успешный ответ отправляется пользователю через 1 минуту, он рассматривается как ошибка.
Traffic: этот сигнал сильно зависит от типа цели. Трафик имеет различные коннотации в зависимости от системы или подсистемы. Для пользовательских веб-интерфейсов хорошим примером этого золотого сигнала является количество HTTP-запросов в секунду. Это напрямую влияет на то, насколько загружена ваша система и сколько действий происходит в единицу времени. Иногда это также называют утилизацией.
Saturation: это измерение текущей нагрузки системы. Хитрость здесь заключается в том, чтобы узнать точку останова на основе доступных ИТ-ресурсов. Если ваша система ограничена ЦП, то вы не хотите достигать 100% его использования, так как это наверняка приведет к ухудшению качества обслуживания. Следовательно, сигнал насыщения основан на загрузке процессора. Однако современные приложения живут на гиперскейлерах, где возможно автоматическое масштабирование. В этих случаях пропускная способность сети является ограничением, поэтому индикатор насыщения основан на том, какая часть доступной пропускной способности используется.
Насыщение, трафик, частота ошибок, задержка и доступность (STELA)
STELA добавляет еще один золотой сигнал – availability. Хотя доступность системы можно определить по любому из четырех золотых сигналов, многие SRE считают это хорошей практикой. Вы начинаете с тестирования сигнала доступности, и если это не удается, вы не измеряете другие золотые сигналы, так как это было бы пустой тратой ресурсов.
Метод USE — это методология, созданная Бренданом Греггом, которая использует контрольные списки для оценки производительности системы. Это очень интересно для мониторинга ИТ-ресурсов, особенно вычислительных узлов.
Utilisation - насколько загружен или утилизирован ресурс
Saturation - Если еще проще это насколько насыщен ресурс, т.е. если ресурс утилизирован на 100, то тут измеряется количество запросов к ресурсу находящихся в очереди
Errors - ошибки
Метод RED — это методология, созданная Томом Уилки, которая определяет три показателя, которые следует измерять для всех микросервисов в среде. Метрики мониторинга, определенные этим методом, следующие:
Rate: количество запросов в секунду.
Request: количество неудачных запросов в секунду.
Duration: время, которое занимает каждый запрос на каждой фазе.
Хотя эти методы не основаны на золотых сигналах, они коррелированы. Принцип наблюдаемости начинается с определения правильного места для проведения мониторинговых измерений. Для этого SRE полагаются на LETS, STELA, RED и USE
Почему GitHub падал несколько раз подряд за неделю? Есть ли достойная и более надежная альтернатива? И при чем здесь PagerDuty? Приглашаю вас на бесплатный урок курса SRE: "Варианты реализации отказоустойчивой архитектуры". Рассмотрим доступные способы создания надежных систем. Также обсудим, какие компромиссы приходится принимать, и какой стратегии придерживаться. Готовьте ваши вопросы и приходите на открытый урок!
