В чем разница между мониторингом, трассировкой и профилированием?

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

Вот как я использую эти слова. Другие могут иметь дополнительное или другое использование. В зависимости от работы, я буду использовать термины по-разному. Команды разработчиков и рабочие группы имеют разные потребности в использовании.

Мониторинг - это мониторинг. Обычно это постоянно и желательно автоматизировано. Инструменты с открытым исходным кодом, как Munin, Nagiosи MRTGпопадают в эту категорию. Там также много коммерческих инструментов. Я бы также включил sarнепрерывный запуск в этой категории, но его результаты обычно не контролируются. Инструменты мониторинга могут использоваться для запуска предупреждений, когда отслеживаемый ресурс падает выше или ниже уровня запуска. Многие инструменты мониторинга хорошо работают в гетерогенных средах.

Профилирование обычно выполняется для конкретной программы, чтобы увидеть, какой код использует больше всего ресурсов. Часто это время ЦП, но оно также может включать в себя память, ввод-вывод и время выполнения (настенное). Обычно используется для определения кода кандидата для оптимизации. Инструменты профилирования, как правило, зависят от языка и / или платформы.

Другой вид профилирования выполняется с использованием журналов и / или данных мониторинга. Это профилирование использования и может быть сделано по разным причинам. Я не нашел много инструментов для этого.

Я использую трассировку несколькими способами. Чаще всего я отслеживаю сетевые маршруты. В зависимости от настроек сети и брандмауэра различные инструменты могут использоваться с большим или меньшим успехом. У большинства из них есть traceroute в их имени или описании.

Программа отслеживания отслеживает выполнение программы. Обычно это делается в тестовой ситуации. Это может быть сделано несколькими способами (в моем порядке использования и опыта):

• Отслеживание вызовов с использованием инструментов, например, straceчтобы увидеть, как называется код. Это может быть полезно при определении того, почему программа не работает или не отвечает должным образом.
• Ведение журнала уровня трассировки, которое зависит от соответствующих операторов регистрации, включаемых в код. Большинство комплектов журналов поддерживают этот уровень детализации. Регистрация уровня трассировки имеет тенденцию иметь плохое покрытие кода. Я обычно добавляю его по мере необходимости и оставляю в коде для будущего использования.
• Трассировка покрытия кода записывает, какие части кода были выполнены в тестовом наборе. Это может быть полезно при определении пропущенных тестовых случаев. 100% покрытие кода получить сложно. 100% охват нормальных потоков должен быть достижимым.
• Камеральная проверка: отслеживание кода путем его чтения. Не очень полезный для больших программ, но хороший способ определить крайние случаи для модульных тестов и / или определить возможные проблемы, когда вероятный источник был сужен. Som = e IDE и редакторы упрощают отслеживание вызова кода реализации.
• Живая отладка; отслеживание выполнения кода во время его работы с использованием отладчика. Можно отследить выполнение инструкции по инструкции, но если проблема связана с синхронизацией, она может быть скрыта. Отладчики, которые могут связать код с текущей инструкцией, очень помогают, но могут потребовать сборки отладочной версии программы.

На сервере веб-приложений SAP мы можем определить эти три ключевых слова, как указано ниже:

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