Несколько месяцев назад Heroku представила метрики log-runtime-метрики, которые вы можете включить из командной строки для вставки метрик загрузки процессора и использования памяти в ваши события журнала с интервалом в 20 секунд.
Как и все данные журнала в необработанном формате, массово не полезно видеть, как метрики сбрасываются в ваши журналы каждые 20 секунд. Однако это не совсем то, что имел в виду Героку. В то же время они представили метрики log-runtime-метрики, Heroku также выпустила эксперимент с открытым исходным кодом log2viz, который дает вам аналитику в реальном времени, извлеченную из ваших логов. Log2Viz дает вам представление о том, что происходит в вашем приложении с точки зрения производительности за последние 60 секунд. Например, я могу узнать время отклика своего приложения и использование памяти, а также любые неприятные системные ошибки Heroku, которые могли произойти. Я должен признать, что это довольно аккуратно, и Log2Viz является отличным инструментом для демонстрации возможностей объединения аналитики в реальном времени и журналов, которые содержат полезные данные.
Что если вы хотите оглянуться назад на свои результаты за последние 20 минут, час или неделю? Что делать, если вы хотите в режиме реального времени просматривать общее использование памяти, а не только средние значения? Что если вы хотите соотнести время отклика со скачками потребления ресурсов, чтобы выяснить, откуда возникают ваши узкие места в производительности? Заинтересованы? Просто добавьте Logentries в ваше приложение Heroku и продолжайте читать, чтобы узнать как!
Лог-время выполнение-метрика
Метрики log-runtime-метрики Heroku вставляют статистику по динамкости об использовании памяти, использовании подкачки и средней загрузке в поток журнала приложения. Средние значения загрузки процессора сообщаются с интервалами за последние 1 мин., Последние 5 мин. и последние 15 минут (аналогично запуску top или uptime на вашем linux / osx box), в то время как статистика памяти и подкачки дает представление о том, сколько ОЗУ, кеша и диска используется.
Отслеживание всплесков с течением времени
Хотя средняя нагрузка 1,0 может подойти для вашего приложения, средняя нагрузка 10,0, например, может привести к проблемам с производительностью системы и, если она будет продолжительной, может привести к ухудшению времени отклика. Извлечение на уровне поля Logentries позволяет легко отмечать и отслеживать скачки в ваших показателях производительности. Используя извлечение на уровне поля, вы можете работать со значениями поля при поиске, использовании тегов или настройке оповещений. Например, отслеживание, когда средние скачки нагрузки достигают 10 или более, можно выполнить с помощью следующего поискового запроса.
Log Event: 2013-10-14 00:13:58.557715+00:00 heroku web.1 – - source=web.1 dyno=heroku.906 sample#load_avg_1m=10.01 sample#load_avg_5m=10.03 sample#load_avg_15m=10.02 Search Query: load_avg_5m>10
Создание тега с поисковым запросом, определенным выше, позволит вам определить в журналах, когда этот порог был превышен.
Затем создайте график, чтобы визуализировать, где средние скачки нагрузки превышают 10,0 с течением времени:
Вы можете легко сделать то же самое для любой метрики времени выполнения журнала Heroku, например, отслеживать пики в памяти, использование диска или подкачки.
Соотносится с временем ответа
В конечном счете вы, вероятно, больше всего будете заботиться о том, что ваши пользователи испытывают с точки зрения времени отклика. Существуют определенные ограничения по времени ответа, которые пользователи могут счесть приемлемыми, прежде чем уйти.
Например, отслеживание всплесков времени отклика наряду с пиковыми значениями средней нагрузки может помочь вам понять, имеет ли смысл запускать дополнительный динамометр или два.
Для этого вы можете создать тег так же, как описано выше. Например, тег, созданный ниже, идентифицирует любой запрос приложения из моего приложения Heroku, который занимал более 300 мс.
Log Event: 2013-10-15 02:46:50.264118+00:00 heroku router – - at=info method=GET path=/ host=calm-sea-7595.herokuapp.com fwd=”x.x.x.x.hsd1.ma.comcast.net” dyno=web.1 connect=3ms service=375ms status=200 bytes=4174
Затем добавьте это к графику, чтобы отслеживать пики времени отклика и пики средней нагрузки …
Получать уведомления, когда время ответа нарушает то, что вы считаете приемлемым
В качестве последнего шага вы можете получить уведомление, когда время ответа нарушает то, что вы считаете приемлемым. Вы можете прочитать 70-страничное руководство по настройке оповещений , однако вместо этого вы можете настроить оповещение в 4 простых шага:
(1) выберите событие, о котором вы хотите получать оповещения (например, любой запрос, который занимает более 300 мс)
(2) определить, как часто это должно происходить, прежде чем вы захотите узнать об этом — например, достаточно ли одного раза — или это должно происходить несколько раз, прежде чем вы начнете беспокоиться?
(3) как бы вы хотели, чтобы это оповещение было доставлено? Например, по электронной почте или прямо на ваше мобильное устройство.
(4) и, наконец, чтобы ваш почтовый ящик не был заполнен, вы бы предпочли получать только одно письмо каждый час на этом …
