Итак, я обычно понимаю, как такие вещи, как New Relic, используют приложение .NET - API-интерфейс CLR Profiler имеет смысл. Но я не могу понять, как такие вещи, как AppDynamics, понимают корреляции между серверами и инструментами, которые на самом деле не основаны на .NET ... Может ли кто-нибудь пролить свет на то, как эти вещи работают внутри?
Кроме того, у вас также есть ненавязчивый мониторинг, который помогает вам проактивно проверять свои приложения с помощью записанных сценариев и отслеживать время отклика, чтобы получать уведомления о проблемах и замедлениях. Многие инструменты APM в этой области (теперь Gomez AppDynamics, Catchpoint, SolarWinds APM, Ipswitch APM и т. Д.).
Если у вас есть среда, размещенная в Citrix или Microsoft, где изображение приложения доставляется в пользовательский интерфейс клиента, вам следует искать сценарии с возможностями распознавания изображений, которые используют фактический пользовательский интерфейс подключения клиента. Затем осуществляется мониторинг путем сравнения экрана с изображениями базовых ответов, созданными во время разработки тестового сценария. Может, захочется взглянуть на http://www.tevron.com/load-testing-citratest-vu-load-testing-methodology.aspx
Мониторинг APM используется для измерения времени отклика. Все мы из первых рук знаем, что ничто не раздражает конечных пользователей больше, чем неожиданно медленное время отклика. Фактически, медлительность, возможно, более серьезная проблема, чем простои и недоступность приложений. Исследования веб-сайтов электронной коммерции показывают, что замедление работы происходит в десять раз чаще, чем простои, и это совокупное замедление в два раза больше влияет на чистую прибыль интернет-магазина. Это означает, что обеспечение того, чтобы ваше приложение было запущено и работало, важно, но этого недостаточно. В дополнение к базовому мониторингу доступности - например, к тестированию IP-протоколов и сетевых сервисов с помощью автоматизированного программного обеспечения, которое может выдавать предупреждения в реальном времени, как только функциональность выходит из строя или падает ниже установленных пороговых значений, - комплексный подход к APM должен учитывать ряд дополнительных факторов. во внимание, как объяснялось в предыдущем разделе, чтобы помочь повысить общую надежность и скорость вашего приложения. Мне известны приложения, использующие Selenium для проверки времени отклика и получения информации о некорректной транзакции.
Продукты APM инструментируют каждый язык по-разному, они используют комбинацию API-интерфейсов (например, API-интерфейсы профилирования), а также внедрение кода в приложение с помощью других методов. Это предоставляет все виды показателей, и вы можете наблюдать за соединениями (точка входа и точка выхода) приложения, чтобы вы могли определить, подключается ли приложение где-то еще. Вы также можете перехватывать и хранить такие вещи, как вызовы SQL или HTTP и т. Д., На основе декодирования вашего протокола в коде.
Теперь к вашему основному вопросу, как работает AppDynamics. Каждый инструмент APM делает это по-своему, если они вообще это делают. У Dynatrace и AppDynamics разные модели трассировки. У каждого есть свои плюсы и минусы. AppDynamics вставляет идентификатор транзакции в полезную нагрузку протокола, это делается безобидным способом, но нисходящее соединение, если у него есть агент, может взять эти данные и связать их обратно с транзакцией. Если агента нет, это не нарушит работу приложения. Dynatrace отправляет гораздо больше данных о своих трассировках вышестоящему сборщику, который по-другому сшивает транзакцию. Один распределенный (крупномасштабный, но трудно реконструировать протоколы), а другой проще сшить, но требует большой обработки и пропускной способности сети.