Яка різниця між моніторингом, відстеженням та профілюванням?

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

Це те, як я використовую ці слова. Інші можуть мати додаткові або різні звички. Залежно від роботи, я буду використовувати різні терміни. Команди розвитку та операційні групи мають різні потреби у використанні.

Моніторинг - моніторинг. Зазвичай він триває і, бажано, автоматизований. Відкриті інструменти джерела , як Munin, Nagiosі MRTGпотрапляють в цю категорію. Тут також багато комерційних інструментів. Я також включав би sarбіг постійно в цю категорію, але її результати зазвичай не контролюються. Інструменти моніторингу можуть використовуватися для запуску сповіщень, коли відстежуваний ресурс падає вище або нижче рівня тригера. Багато інструментів моніторингу добре працюють у неоднорідних середовищах.

Профілювання зазвичай проводиться в певній програмі, щоб побачити, який код використовує найбільше ресурсів. Часто це час процесора, але також може включати в себе пам'ять, введення / виведення та час виконання (wall) часу. Зазвичай використовується для ідентифікації коду кандидата для оптимізації. Інструменти профілювання, як правило, залежать від мови та / або платформи.

Інший вид профілювання проводиться за допомогою журналів та / або даних моніторингу. Це використання профілювання і може бути здійснено з різних причин. Я не знайшов багато інструментів для цього.

Я використовую трасування двома різними способами. Найчастіше я простежу мережеві маршрути. Залежно від налаштувань мережі та брандмауера, різноманітні інструменти можуть використовуватись з більш-менш успішним результатом. Більшість із них мають своє ім'я чи опис.

Простеження програми - це відстеження виконання програми. Як правило, це робиться в тестовій ситуації. Це можна зробити різними способами (в моєму порядку використання та досвіді):

• Відстежуйте дзвінки за допомогою інструментів, як straceщоб побачити, який код викликається. Це може бути корисно при визначенні того, чому програма не відповідає або не відповідає, як очікувалося.
• Журнал рівня трасування, який залежить від відповідних операторів журналу, що включаються до коду. Більшість пакетів журналів підтримують цей рівень деталізації. Журнал рівня слідів має слабке охоплення коду. Я, як правило, додаю його за потреби і залишаю в коді для подальшого використання.
• Відстеження кодового покриття записує, які частини коду виконані в тестовому наборі. Це може бути корисно при визначенні відсутніх тестових випадків. 100% покриття коду важко отримати. 100% охоплення нормальних потоків повинно бути досяжним.
• Перевірка на робочому столі: відстеження коду шляхом його читання. Не дуже корисно для великих програм, але хороший спосіб виявити кращі випадки для одиничних тестів, ан / або для виявлення можливих проблем, коли ймовірне джерело було звужене. Som = e IDE та редактори дозволяють порівняно легко слідкувати за викликом коду реалізації.
• Жива налагодження; відстеження виконання коду під час його роботи за допомогою відладчика. Можна відстежити виконання інструкцій за інструкцією, але якщо проблема є проблемою з тимчасовим терміном, вона може бути прихованою. Налагоджувачі, які можуть прив’язати код до поточної інструкції, дуже допомагають, але можуть вимагати побудови версії програми налагодження програми.

На сервері прикладних програм SAP ми можемо визначити ці три ключові слова як зазначені нижче

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