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

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

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

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

Я не узнаю о том, что моё приложение сломано благодаря тому, что клиент сообщит об ошибке напрямую. Такие клиенты не сообщают о багах или ошибках; они просто перестают пользоваться приложением и ищут другую команду, которая работает более слаженно.

За более чем десять лет работы разработчиком ПО я много времени тратил на поиск лучших инструментов для повышения моей продуктивности.

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

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

Что такое инструменты для мониторинга приложений?

Обычно инструменты для мониторинга приложений состоят из двух частей:

1. Агент
2. Платформа аналитики

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

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

▍ Чем они не являются

Очевидно, что это упрощённое описание, под которое может попасть огромное количество инструментов.

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

Вот чему я научился из своего опыта.

Инструменты управления логами

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

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

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

Монитор аптайма

Инструменты мониторинга аптайма можно считать усложнённым «пингом».

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

Эта информация полезна для понимания того, как работает облачная инфраструктура до получения доступа к ней конечных пользователей (балансировщик нагрузки, CDN, сеть и так далее); инструменты не предоставляют никакой информации о происходящем внутри приложения.

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

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

Мониторинг серверов и мониторинг приложений

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

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

Однако мониторинг сервера и мониторинг приложения выполняют две совершенно разные задачи.

Мониторинг сервера сфокусирован на инфраструктуре; кроме того, по сути, он предоставляется бесплатно любым приличным поставщиком облачных услуг.

Google GCP, AWS и DigitalOcean по умолчанию совершенно бесплатно (если не считать затрат на работу самой ВМ) предоставляют пользователям самые важные метрики, например, загрузку CPU, объём накопителя, полосу пропускания и так далее.


Понимание момента, когда ВМ нужно масштабировать вверх (или вниз) — важная потребность, однако показатель загрузки CPU в 100% может значить что угодно и ничего не значить:

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

Как говорилось выше, при мониторинге сервера агент устанавливается на уровне сервера, то есть «снаружи» приложения. Однако практически невозможно изучать приложение снаружи, чтобы понять, что происходит внутри кода.

Мониторинг приложения сфокусирован на приложении.

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

Какую задачу решает инструмент мониторинга приложения?

Инструмент мониторинга приложения предоставляет метрики и алерты для выявления багов и узких мест в приложении без необходимости ожидания отчётов о проблемах от клиентов.

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

Они работают в качестве часового и позволяют визуально исследовать то, как работает код, выполняя 90% анализа полностью автономно.

Почему мониторинг приложений важен?

Он важен, потому что довольные клиенты — это платящие клиенты.

Можно сказать, что создать приложение — это самое простое; это может сделать каждый.

Настоящая работа начинается с построения взаимопонимания с клиентом и превращения его потребностей в главный приоритет.

Если вы поставите интересы клиента на первое место, он останется преданным фанатом вашего приложения. И наоборот: одна из самых плохих вещей для бизнеса — ПО с ошибками и багами.

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

Мониторинг чего можно выполнять в приложении?

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

Каждый цикл исполнения обычно называется «транзакцией». В процессе транзакции приложение может выполнять множество различных задач, например, SQL-запросов, чтения/записи файлов, вызовов внешних систем, алгоритмов и так далее.

Мы называем этот список задач Timeline, и визуально вы можете исследовать его на изображении ниже:


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

Я действительно верю, что чёткая и простая информация — самое важное для принятия оптимальных решений.

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

Telegram-канал с полезностями и уютный чат