Как системы APM отслеживают и собирают информацию о взаимодействиях машин?

Затем у вас также есть ненавязчивый мониторинг, который помогает вы проактивно проверяете свои приложения с помощью записанных сценариев и отслеживаете время отклика, чтобы получать предупреждения о проблемах и замедлениях. Многие инструменты APM в этой области (теперь Gomez - AppDynamics, Catchpoint, SolarWinds APM, Ipswitch APM и т. Д.).

Если у вас есть среда, размещенная в Citrix или Microsoft, где изображение приложения доставляется в пользовательский интерфейс клиента, вам следует ищите сценарии с возможностями распознавания изображений, которые используют фактический пользовательский интерфейс клиентского подключения. Затем выполняется мониторинг путем сравнения экрана с изображениями базовых ответов, созданными во время разработки тестового сценария. Может, стоит взглянуть на http://www.tevron.com/load-testing-citratest-vu-load-testing-methodology.aspx

Продукты APM инструментируют каждый язык по-разному, они используют комбинацию API-интерфейсов (например, API-интерфейсы профилирования), а также внедрение кода в приложение с помощью других методов. Это предоставляет все виды показателей, и вы можете наблюдать за соединениями (точка входа и точка выхода) приложения, чтобы вы могли определить, подключается ли приложение где-то еще. Вы также можете перехватывать и хранить такие вещи, как вызовы SQL или HTTP и т. Д., На основе декодирования вашего протокола в коде.

Теперь к вашему главному вопросу, как работает AppDynamics. Каждый инструмент APM делает это по-своему, если они вообще это делают. У Dynatrace и AppDynamics разные модели трассировки. У каждого есть свои плюсы и минусы. AppDynamics вставляет идентификатор транзакции в полезную нагрузку протокола, это делается безобидным способом, но нисходящее соединение, если у него есть агент, может взять эти данные и связать их обратно с транзакцией. Если агента нет, это не нарушит работу приложения. Dynatrace отправляет намного больше данных о своих трассировках вышестоящему сборщику, который по-другому сшивает транзакцию. Один распределенный (крупномасштабный, но трудно реконструировать протоколы), а другой проще сшить, но требует большой обработки и пропускной способности сети.

Мониторинг APM используется для измерения времени отклика. Все мы из первых рук знаем, что ничто не раздражает конечных пользователей больше, чем неожиданно медленное время отклика. Фактически, медлительность, возможно, является более серьезной проблемой, чем простои и недоступность приложений. Исследования веб-сайтов электронной коммерции показывают, что замедление работы происходит в десять раз чаще, чем простои, и эти совокупные замедления в два раза больше влияют на чистую прибыль интернет-магазина. Это означает, что обеспечение того, чтобы ваше приложение было запущено и работало, важно, но этого недостаточно. В дополнение к базовому мониторингу доступности - например, к тестированию IP-протоколов и сетевых сервисов с помощью автоматизированного программного обеспечения, которое может выдавать предупреждения в реальном времени, как только функциональность выходит из строя или падает ниже установленных пороговых значений, - комплексный подход к APM должен учитывать ряд дополнительных факторов во внимание, как объяснялось в предыдущем разделе, чтобы помочь повысить общую надежность и скорость вашего приложения. Я знал, что приложения, использующие Selenium, проверяют время отклика и получают информацию, когда транзакция неверна.