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

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

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

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

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

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

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

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

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

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