Как выбрать между APM и комплексным инструментом мониторинга

Было время, когда APM был всем, что нужно. Старые монолитные веб-сервисы отслеживались с помощью инструментов мониторинга производительности приложений (APM). Эти средства предоставляют подробную информацию о том, как работает веб-служба, и могут предупреждать администраторов о потенциальных проблемах, прежде чем они станут широко распространенными. Таким образом, APM вывел нас из эпохи, когда ваши пользователи были первыми людьми, которые заметили серьезную проблему. Вместо этого наши инструменты мониторинга могли сказать нам, что проблемы назревают заранее.

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

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

Но вот несколько вопросов о таких инструментах, как Scout APM:

1. Привержены ли мы открытым стандартам?

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

2. Мы заперты в одном поставщике?

Недавний инцидент, связанный с попыткой DataDog подавить коммит OpenTelemetry, вызвал серьезную обеспокоенность по поводу поставщиков APM. Когда эти поставщики утверждают, что «принимают» открытые стандарты, действительно ли они говорят, что мы будем потреблять любые данные, которые вы хотите нам отправить, вы просто не можете взять свои данные куда-либо еще».

Эти политики немного напоминают нам о плохих старых временах SaaS, когда удаление ваших данных из CRM или офисного инструмента было почти невозможно. Как компаниям APM это сходило с рук так долго? Вероятно, потому, что переносимость в данном случае на самом деле не связана с переносимостью исторических данных. Подумайте об этом: при переносе мониторинга в другую службу, вероятно, не имеет значения, если вы принесете с собой данные о производительности за 2017 год.

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

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

3. Насколько монолитна наша архитектура?

В то время как APM хорошо работает в монолитной среде, и хорошо, если у вас работает 12 или около того разных сервисов, как только вы выйдете далеко за рамки этого, вы будете бороться. Смотрите «Ваша архитектура определяет вашу судьбу» далее в этой части

4. Сколько гибкости и настроек вам нужно?

Одним из первоначальных преимуществ APM был отличный опыт «из коробки». При установке Scout APM в приложение Rails вы получаете отличную карту вашего инструмента в течение нескольких часов. Но с любым инструментом APM этот опыт «из коробки» может начать чувствовать, что вы «заперты».

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

С помощью Open Telemetry, особенно с использованием OpenTelemetry Collector, вы можете отправлять, форматировать и просматривать данные из своих служб независимо от вашего варианта использования.

Ваша архитектура определяет вашу судьбу

Выбор TelemetryHub (и базового проекта OpenTelemetry, для которого построен TelemetryHub) намного проще, если у вас большое количество микрослужб. Сколько это большое число? К тому времени, когда у вас есть десятки микросервисов, кратное количеству разработчиков в вашей команде, пришло время подумать об OpenTelemetry.

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

Вот таблица ключевых различий между Scout APM и TelemetryHub