Мониторинг и Диагностика
Работа в реальном мире подразумевает выявление момента, когда дела пошли наперекосяк, различия между исходными данными и конечным продуктом, отбрасывание ложных умозаключений, понимание, когда стоит отказаться от методов, которые в конечном итоге окажутся безуспешными; а также спокойную реакцию на обострение.Ричард Кук, Недостатки в оказании медицинской помощи и совершенствование безопасности пациента
Смысл измерений уже после релиза заключается в том, чтобы быть в курсе изменений и иметь возможность находить причины значимых перемен в метрике. Очень похоже на эксплуатацию, не правда ли? У сетевых приложений грань между работой над производительностью и эксплуатацией получается очень размытой.
Мониторинг
Как бы вы ее не называли, приборная панель, доска приборов или еще как-то, панель инструментов — это сигнализация вашей системы. Метрика на панели инструментов должна отражать ваше понимание того, как система функционирует и не функционирует.
В панели инструментов вы можете проверить некоторые теории касательно того, сбудутся ли их предсказания. Закончите предложение, заполняя пробелы:
Пока система функционирует нормально, график _______ никогда не _______.
На панели находятся ответы на вопросы, и они, скорее всего, будут такими фундаментальными показателями как трафик, использование процессора, объем обмена данными. Эти ответы, выраженные в виде графика на вашей панели, должны быть такими же, как и сигнализация: простыми, ясными и исключать ошибочные срабатывания. Сигнальная лампочка передает всего лишь один бит информации, но это очень важный бит, и он всегда взывает к действию.
Очень распространенная ошибка — загрузить панель кучей разнородной информации. Самый модный больничный монитор описывает менее чем десятью графиками настолько сложный объект как человек. Пока человек в порядке, график пульса никогда не меняется кардинально, колеблясь от 60 до 100. То же самое должно быть и у нас. Главная панель не должна ставить диагноз. Ее задача — показывать, что что-то произошло не так и давать подсказку, что нам делать дальше.
Я не хочу сказать, что у вас не может быть кучи разных графиков. Ничего тут такого нет. Например, показатели процессора и памяти каждого сервера. Просто их не должно быть *слишком *много, слишком много разнородных показателей, которые будут сбивать вас с толку.
Диагностика
Однажды вы проснетесь от сигнала. Уровень ответа сервера снизился до 10%. Для начала нужно определить, в каком месте концентрируется увеличение потребления ресурсов. Суть предположения в том, что аномалии должны выделяться на фоне нормальных процессов. Это предположение имеет смысл до поры до времени. Чем сложнее системы, тем чаще причина проблемы далеко не одна.
Хорошо собранные метаданные и гибкая система визуализации — ваши друзья навсегда. Вернитесь и посмотрите, что вызвало рост потребления ресурсов. Был ли это скачок или градиент? Запишите интервалы времени понемногу со всех сторон, чтоб использовать их позже. Потом сравните большой набор образцов в состоянии до и после, чтоб увидеть размер изменений. Сравнивайте графики по посещениям и по пользователям отдельно. Этого должно быть достаточно.
Продолжая измерения, начните их сортировать по датацентрам, по продуктам или по script_path. Если вам повезет, то вы сможете проследить зависимость. Если зависимость обнаружится при сортировке по датацентрам, то это, скорее всего, ошибка типа перегруженного сервера БД. Если дело в продуктах или script_path, то дело скорее в коде или настройках. Проверьте логи (вы же ведете логи, так?) и посмотрите, какие изменения вносились во время падения производительности.
Если вам не повезло, и никаких зависимостей нет, это значит, что мы смотрим не на тот уровень вложенности. До сих пор мы использовали обобщенное физическое время. Из чего же оно состоит? В системе, которую мы используем тут для примера, физическое время состоит из трех компонентов: процессорное время, время запросов к базе данных и время выборки кэша. Проводите измерения по всем этим показателям и ищите тот, который является причиной ошибки. Потом уже исследуйте конкретно этот показатель для выявления проблемы.
Этот процесс рекурсии измерений практически механический, но не до конца. Также не стоит пытаться придумать причины, по которым могла случиться эта проблема. Если вы уверены, в чем причина, действуйте наоборот: подумайте, что могло произойти еще, если система работает неправильно по причине, о которой вы догадываетесь. А потом пытайтесь это либо доказать, либо опровергнуть.
Я не верю в Фею Производительности.Джеф Ротшильд
Изменения могут быть как в одну сторону, так и в другую. Скажем, вы выпустили новую версию программы и среднее время загрузки улучшилось на 10%. Прекрасно, не так ли? Всем пять, и выпивка за мой счет? Нет, если вы этого не ожидали. Есть много причин, по которым могло это произойти, и хороших среди них не много.
Когда что-то «отваливается», это ускоряет систему. Некоторые запросы могут прекращаться раньше, чем нужно. Проверьте логи ошибок.
Если в логах нет ошибок, то, возможно, не вся информация передается. Проверьте общее количество передаваемых данных. Среднее количество байт, передаваемых за раз. Проверьте распространение.
Еще одной причиной может быть увеличение переходов по «легким» ссылкам. Внутренние проверки работоспособности – самая распространенная причина такого рода багов.
Покупали ли вы новые сервера?
Отключали старые?
Может просто какие-то сервера сломались?
Это просто примеры. Это не четкие правила на все случаи жизни. Мы не пытаемся тут изобрести один единственный путь диагностирования. То, чем мы занимаемся, больше походит на игру «Двадцать Вопросов». Два человека начинаются с разных точек отсчета, проходят уникальный путь и приходят к одним и тем же заключениям. Однородность процесса не имеет значения, если все сходится к одному. Самое важное — это иметь гибкий, многоуровневый режим измерения, который позволит проверять гипотезы и, как в игре «Двадцать Вопросов», быстро исключать огромные участки поля возможностей пока не найдешь то, что ищешь.
Думайте структурно
Со временем у вас накопится опыт решения таких задач. Каждый раз, решая проблему, используя нестандартные метрики, просмотры, фильтры, или что там у вас получилось, добавляйте этот метод на вооружение в свои инструменты диагностики, которые есть не что иное, как сборник известных решений задач. Вот несколько метрик, которые подойдут, пожалуй, всем.
Частота ошибок
Время задержки (среднее; срединный, малый и высокий процентиль)
Процессорное время / Инструкции
Вход и выход байтов по сети
Запросы в секунду
Активные пользователи
Активные сервера
Использование серверов (CPU, RAM, I/O)
Запросы к БД
Запросы к кэшу / неудачные запросы к кэшу
Ничего, если у вас уже и так заполнен весь дисплей, я точно пропустил еще кое-что. Все эти метрики должны быть представлены по каждой стране, датацентру, www отдельно от API и отдельно от мобильной версии. И еще полдюжины размерностей тоже добавьте.
Набросайте их все на листе бумаги и начинайте группировать в подчиненные друг другу структуры. Животные, овощи, минералы? Какие метрики ведут к каким по ходу диагностики? Как можно их связать? Если бы это была карта, какие бы объекты при ее увеличении стали больше? Какие метрики отвечают за точность других?
Когда ____________ работает нормально, график __________ может исключить ___________ как возможную причину.
Это «средство диагностирования» является чем-то между редчайшей высокоуровневой панелью управления и гибким, бесплатным для всех массивом данных, который мы построили в этой книге. Как минимум он уже содержит ссылки на просмотр данных с проверенной опытом информацией. Если у вас уже есть что-то подобное, в голове или в избранном, отберите тщательно и разошлите всем вашим коллегам. В него включена большая часть поведенческих особенностей вашей системы.
Корреляция не подразумевает причину, но она двусмысленно приподымает бровь, намекает жестом и как бы говорит вам: "Посмотри туда".Рэндал Мунро, xkcd.com/552
