ru:https://highload.today/blogs/my-chto-devopsy-chtoby-vse-nastraivat-kak-bez-problem-provesti-otladku-php-prilozheniya/ ua:https://highload.today/uk/blogs/metod-kachechki-dlya-debagingu-zberigannya-logiv-ta-inshe-shho-varto-znati-dlya-nalagodzhennya-php-zastosunku/
logo
Досвід      09/09/2022

«Ми що, девопси, щоб все налаштовувати?»: як без проблем провести налагодження PHP-застосунку

Олексій Корнієнко BLOG

PHP developer в NIX

Із необхідністю налагодження програм періодично стикається кожен PHP-розробник. Як показує практика, далеко не кожен має достатньо знань для виконання такого завдання. Деякі навіть більш-менш досвідчені фахівці не завжди розуміють суть налагодження застосунку, навіщо це потрібно та які підходи існують. Без цих знань вирішити проблеми, які час від часу виникають на будь-якому проєкті, буде просто неможливо. Тому, якщо ви PHP-розробник, пропоную вам вже зараз розібратися в цій темі.

У цій статті я детально розкрию поняття налагодження і дебагінгу, поясню, для чого можуть знадобитися логи, профілювання та кілька інших методів. Також опишу найпопулярніші інструменти налагодження. І все це — на наближеному до реального проєкту прикладі.

Зміст

1. Що таке налагодження
2. Додавання логів — як це працює
3. Що завжди потрібно логувати
4. Комунікація між сервісами
5. Opentracing / Opentelemetry — базовий інструмент для роботи з логами
6. Способи зберігання логів
7. Де можна використовувати дебаг можливості PhpStorm
8. «Метод качечки» для дебагінгу
9. Цікаві можливості PhpStorm
10. Навіщо вам профілювання?
11. Куди рухатися далі

Що таке налагодження

Почну з аналогії, далекої від IT, але дуже показової в нашій темі. На ранніх етапах розвитку люди з будь-якими захворюваннями зверталися до шаманів із проханням вилікувати їх. Ті могли провести певний обряд і запропонувати випити зілля з якоїсь трави чи корінця. Допомогло — чудово! А якщо ні — пробуємо далі. Так, перебираючи зілля, можна з часом зрозуміти, що долає конкретну хворобу.

Мені ця історія нагадує розробника, який не вміє користуватися інструментами налагодження.

Він може писати код, який начебто працює, але не в змозі розібратися з проблемою та зрозуміти, що ж відбувається у його проєкті.

Порівняйте шаманів із сучасними лікарями. Сьогодні у них багато приладів для первинної та вторинної оцінки організму. Фахівці збирають безліч даних про стан пацієнта і на підставі результатів аналізів намагаються зрозуміти, як зараз працює організм, які показники в нормі, а які — ні.

Все це стає основою для постановки діагнозу та варіантів лікування. У розробників усе так само.

Девелопер використовує інструменти налагодження для аналізу поведінки програми, читання логів, вимірювання параметрів тощо. Це дає можливість визначити місце виникнення проблеми та вирішити, як її «лікувати».

Курс QA Manual (Тестування ПЗ мануальне) від Powercode academy.
Навчіться знаходити помилки та контролювати якість сайтів та додатків.
Записатися на курс

Щоб краще уявити собі організацію цього процесу на практиці, розберемо поширений приклад. Припустимо, ви розробили онлайн-майданчик для запуску інтернет-магазинів. На сайті підприємці реєструють свої сторінки, викладають товари, приймають замовлення.

Таких сервісів у наш час багато, ви їх знаєте й самі. Спочатку все добре: ваш майданчик працює, продаж іде, бізнес заробляє гроші. Але одного дня користувачі системи, ті самі підприємці, просять додати новий функціонал — відправку на email звітів про щоденні продажі із переліком товарів і сум. Не виглядає, як складне завдання, правда ж? У такому разі розробники можуть запропонувати подібну схему реалізації функціоналу:

Малюнок 1. Схема процесу генерації та відправки звітів

Малюнок 1. Схема процесу генерації та відправки звітів

Насамперед тут є cron, який запускає команду PHP CLI, яка зі свого боку вибирає користувачів-підприємців і по кожному з них публікує повідомлення у чергу в RabbitMQ. Також передбачено обробник, він же консюмер черги RabbitMQ, який для кожного окремого користувача обирає всі дані про його замовлення, вираховує прибуток конкретного підприємця, формує текст повідомлення та відправляє його на пошту. Все працює коректно, користувачі задоволені.

Однак згодом одному підприємцю перестають надходити звіти. Ви можете звернутися до коду крон-команди та обробника в пошуку джерела проблеми і перевіряти базу даних, але це може нічого не дати.

У коді все виглядає правильним, і ситуацію можна описати класичною фразою «Має працювати…». Саме так і говорять при нестачі інструментарію для розуміння, як працює система.

Варіантів проблемних місць багато. Наприклад, email міг не рушити далі через проблеми з мережею. Також міг впасти обробник черги через помилку в коді. А ще обробник міг не отримати повідомлення від RabbitMQ, а крон-команда — не опублікувати повідомлення в чергу. І це не говорячи про збій у запуску крона. Як же бути?

Додавання логів — як це працює

Я раджу починати з додавання до системи логів, щоб вирішити чи попередити описану ситуацію. На малюнку 2 зображена схема, на якій я позначив синіми стрілками, де можна додати логи в згадану вище схему.

До речі, відсутність логів — це теж корисна інформація, яка допомагає оцінити якість побудови сервісу в цілому:

Малюнок 2. Схема процесу генерації та відправки звітів з урахуванням логів

Малюнок 2. Схема процесу генерації та відправки звітів з урахуванням логів

За допомогою додавання логів при старті крон-команди можна зрозуміти, чи вона запускається взагалі. У логах при публікації повідомлень видно, що воно точно було опубліковано в RabbitMQ і як мінімум доставлено. Логи про помилку публікації повідомлення вкажуть на проблему з підключенням до цієї частини системи через недоступність мережі або помилки в налаштуваннях. Також варто залогувати тривалість команди, оперативну пам’ять та CPU для виключення надто довгої роботи крона. Через це користувач просто не дочекається публікації та обробки повідомлення.

Варіантів, де вбудовувати логи, багато. Зазвичай я додаю запис логів на початку роботи PHP-команди: назва команди, час запуску команди та інша додаткова інформація. Також обов’язково додаю запис логів наприкінці роботи PHP-команди. Це дозволяє впевнитись, що вона закінчила працювати.

До логів про завершення роботи команди раджу додавати інформацію про обсяг використаної оперативної пам’яті, пікові використання процесорного часу і тривалість виконання самої команди. Це просто та наочно. А коли ви бачите, що і де відбувається, вирішити задачу вже трохи легше.

Більше того, для користувачів фреймворків Laravel або Symphony є готові інструменти для створення команд PHP CLI. Тобто все вже налаштовано та протестовано сотні разів. Вам залишається лише зрозуміти: чи проблема з налаштуванням таймінгу крона, чи ви сам крон забули кудись додати. Така ситуація може статися під час деплою на різні оточення, якщо у вас не налаштований автоматичний процес деплою. Описаний лог допоможе швидко знайти помилку та зрозуміти, чи програма розпочала роботу.

Онлайн-курс Pyton від Powercode academy.
Опануйте PYTHON з нуля та майте проект у своєму портфоліо вже через 4 місяця.
Приєднатися

Варто зазначити, що помилки також потрібно логувати. Такі логи можна записувати у try…catch-конструкції.

Сталася помилка? Логується повідомлення, де вона відбулася, в якому файлі та в якому рядку. Ще краще логувати весь trace помилки — тобто всі ексепшени, які передавалися нагору. Адже цей ланцюжок у фреймворках Symphony або Laravel може бути дуже довгим. Те саме слід робити й з обробником.

Насамперед потрібен лог про те, що обробник успішно почав читати повідомлення. Тут обов’язково додайте розпізнавальні знаки: обробник отримав повідомлення користувача з id=10. Так ви точно зрозумієте, що воно було прочитано.

Окремо хочу згадати пошту та іншу комунікацію зі сторонніми сервісами. Я рекомендую обгортати код в try…catch і писати в кінці траю, що повідомлення успішно відправлене. В кетчі можна логувати, якщо щось не було відправлено. Скажімо, через мережеву помилку або проблеми з конфігурацією.

Далі я ще розповім більш детально про місця, де логування вкрай важливе. А зараз повернемося до нашого прикладу й оцінимо ситуацію після додавання логів.

Уявімо, що ми бачимо в сховищі логів лише лог старту крон-команди. Тобто крон запускається, але немає логів про початок опрацювання інформації для користувача, який прийшов зі скаргою. Багатьох розробників ситуація може поставити в глухий кут. У такому разі допоможуть дебаг-логи.

Один із їхніх видів я відніс би до категорії мастхев — йдеться про дебаг-логи для роботи з базою та з можливістю вмикання і вимикання цієї функції. Це дозволить писати запит, який відправляються до бази, та відповіді, які повертаються (останнє — опціонально). Адже результат може бути дуже громіздким, і його не завжди потрібно логувати. Хоча іноді корисно бачити логи з результатом: що повернулося з бази, а що потім віддала ORM.

Після впровадження таких логів ви, наприклад, можете побачити надсилання запиту до бази даних із додаванням умови, що поле deleted_at повинно бути null. Таке може трапитися при використанні функції для роботи з «м’яким» видаленням, яке вбудовано у фреймворк. На таку неочевидність досить легко натрапити. Часто фільтрація додається десь всередині фреймворку чи ORM, однак в коді побудови запиту це не буде описано. Тому в коді все виглядає зрозуміло, а насправді це не так.

Логи допоможуть локалізувати проблему. Вони виділяють у скоупі сервісів, команд та обробників той етап, на якому щось пішло не так. Дебаг-логи дозволяють детальніше подивитися на додаткову інформацію про роботу: з базою, мережею, з комунікаціями між сервісами тощо. Буває складно зрозуміти, який запит був побудований і відправлений до БД, та побачити реальну картину.

У вас може скластися враження, що логувати потрібно все. Передусім робити це треба свідомо. Ви можете залогувати так багато всього, що на запис логів буде витрачатися більше часу, ніж на роботу програми. При цьому зберігання логів у вигляді терабайтів тексту може коштувати стільки, що прибуток від проєкту зійде нанівець. Тому стежте за балансом логів у вашому сервісі. Та й взагалі писати логи в файли, як на мене, дуже погана практика. Для тих, хто досі так робить, раджу ознайомитися з 11-м фактором у методології створення SaaS-застосунків.

Що завжди потрібно логувати

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

  • Основні етапи бізнес-логіки
  • Курс UX/UI дизайнер сайтів і застосунків з Alice K.
    Курс від практикуючої UI/UX дизайнерки, після якого ви знатимете все про UI/UX дизайн .
    Реєстрація на курс

Потрібно розуміти, по якій саме гілці розгалуження виконувався код. Якщо в ньому дуже багато розгалужень і чимало логів треба додавати, то, мабуть, час вже задуматись над рефакторінгом.

  • Помилки

Потрібно логувати всі помилки, які можуть трапитися в коді: помилки роботи з базою, мережеві помилки тощо. Переконайтеся, що сервіс корректно логує runtime-помилки. Перевіряйте, чи корректно він записує помилки про недостатню кількість оперативної пам’яті або про виклик неіснуючої функції. Часто це вже реалізовано у сучасних фреймворках. Пам’ятайте: catch, який націлений на клас \Exception в PHP, не покриває весь перелік помилок. Тому краще використовувати інтерфейс \Throwable.

  • Послідовність дій

Якщо якась сутність обробляється почергово кількома обробниками чи крон-командами, її варто логувати. У логах обов’язково має бути весь ланцюжок. Так ви зрозумієте, де і яка команда відпрацювала для кожної сутності, а де вона навіть не стартувала.

  • Використані ресурси

Я маю на увазі RAM та CPU. Це стосується обробників на кшталт консюмерів RabbitMQ або Kafka. Також раджу відстежувати крон-команду. При постійному додаванні логіки в команду PHP CLI, що спочатку працює кілька секунд, через рік вона може вийти на півгодини. При цьому команда стартуватиме кожні 5 хвилин — і все через невгамовне споживання пам’яті та процесорного часу.

  • Тривалість процесів

Тут усе просто: ці процеси справді допомагають побачити загальну картину.

Курс Frontend від Mate academy.
Frontend розробник може легко створити сторінки вебсайту чи вебдодаток. Тому після курсу ви станете затребуваним фахівцем у сфері, що розвивається.
Інформація про курс
  • Дебаг-інформація

Йдеться про роботу з базою, мережею тощо.

Комунікація між сервісами

Окремо хочу трохи розповісти про логування між сервісами. Це важливо у багатьох випадках. Наприклад, моноліт розпиляли на мікросервіси. Або ж моноліт є ядром, але в нього приходять запити, які перенаправляються в один сервіс, той перенаправляє до іншого — й утворюється довгий ланцюг. У таких випадках буває складно розібратися, чи дістався запит від однієї ланки до іншої. Приклад такої комунікації зображено нижче — на малюнку 3.

Для вирішення проблеми можна застосувати ідентифікатор процесу. Наприклад, UUID або випадковий рядок для визначення ідентифікатору. Необов’язково це будуть окремі сервіси. Можуть бути і підблоки в коді, якщо бізнес-логіка передбачає тисячі рядків і десятки класів. Тоді можна виділяти процеси ідентифікаторами блоку:

Малюнок 3. Схема комунікації між різними сервісами

Малюнок 3. Схема комунікації між різними сервісами

Я рекомендую передавати інформацію в кастомних заголовках, наприклад, через заголовок x-request-id. Коли другий сервіс прийматиме такий запит, він побачить у заголовку x-request-id та перевикористує його в логах. Знаючи один x-request-id, ви зможете дивитися ланцюжок логів навіть у разі комунікації з кількома сервісами по черзі.

Аналогічна ситуація з RabbitMQ та Kafka. Ви можете додавати до повідомлення, яке публікується, метаінформацію з x-request-id. Після отримання цього ідентифікатору консьюмером ви прочитаєте його та будете записувати наступні логи з використанням цього ідентифікатору — і весь ланцюжок дій збережеться. Це чудово допомагає розібратися, на якому етапі зупинися процес обробки повідомлення чи запиту.

Opentracing / Opentelemetry — базовий інструмент для роботи з логами

Оскільки логи потрібні в кожному проєкті, для роботи з ними зробили дуже зручні тулзи, які значно полегшують роботу. Opentelemetry (або Opentracing, як він раніше називався) має SDK для близько 10 мов програмування, в тому числі PHP. Ознайомитись із тим, як працювати з логами в Opentelemetry, можна за цим посиланням.

Способи зберігання логів

Найпростіший варіант — у сирому вигляді на сервері. Якщо у вас один сервер та невисоке навантаження на рівні одної-двох тисячі логів на день, то вам навряд чи знадобиться окреме сховище. Це легко реалізувати і в Laravel, і в Symphony.

Однак цей підхід перестає працювати при масштабуванні проєктів. Уявіть, що у вас налаштований в AWS автоскейлінг та кількість серверів залежить від навантаження. Або ще гірше: моноліт розділений на мікросервіси, через що є 10 інстансів із моноліту та 10 — для кожного сервісу. Зібрати все воєдино неможливо. Тому необхідно зберігати логи в інший спосіб, і їх тут існує декілька.

Малюнок 4. Варіанти збереження логів

Малюнок 4. Варіанти збереження логів

Перший — для роботи зі звичайними файлами є інструмент Filebeat. Він працює як демон на сервері, тобто це фоновий процесс. За допомогою стека ELK, Elasticsearch, Logstash та Kibana він допомагає зберігати та відображати логи. Сценарій роботи такий: Filebeat читає файли, трекає зміни та пуше у Logstash. Той зі свого боку зберігає все в індексі Elasticsearch. Далі ви через UI в Kibana можете працювати з індексами логів та робити за ними вибірки.

Інший спосіб стане в нагоді, коли у вас забагато файлів та логів, що призводить до великих витрат часу на запис та роботу з файловою системою. Тут допоможе Syslog, який агрегує потік логів і засує їх у пам’ять пачками. У цій статті я не буду детально описувати, як працює ця тулза. За необхідності гугліть syslon-ng. Однак скажу головне: цей процес теж налаштовується зі стеком ELK.

Наступний кейс — логи від клієнтських програм. Варіантів реалізації безліч, але основне все те ж саме: Android, iOS та фронтенд можуть пушити логи в Elasticsearch, використовуючи Logstash.

Думаю, ви зрозуміли основний зміст цієї частини: ELK покриває широке поле завдань у роботі з логами та прискорює роботу. Хоча Kibana не ідеальна. В ній зустрічаються проблеми з розмежуванням пермісій між користувачами і ролями та по роботі з конкретним індексом (особливо, коли деякі користувачі можуть бачити певні логи). Тому завжди тримайте в голові альтернативи. Наприклад, Graylog. Він безпосередньо вирішує проблеми з пермісіями: хто та які логи може дивитися. В будь-якому випадку базим сховищем найчастіше буде Elasticsearch, а згадані тулзи замінять Kibana. Також рекомендую подивитися і в бік Opentelemetry, яка теж може виступати як сховище логів.

І тут дехто з розробників може спитати: ми що, девопси, щоб це все налаштовувати? Моя відповідь: так, іноді девелоперам доводиться розбиратися й у таких темах.

Онлайн-курс Frontend-разробник від Powercode academy.
Курс на якому ти напишеш свій чистий код на JavaScript, попрацюєш із різними видами верстки, а також адаптаціями проектів під будь-які екрани. .
Зарееструватися

Якщо у вас виникла проблема з інтеграцією логів та застосунків, а девопса на проєкті немає або саме зараз він недоступний, програміст зазвичай сам сетапить таку систему. Вважайте, що це додає вам більше розуміння, як працює ваша система.

Де можна використовувати дебаг-можливості PhpStorm

Повернемося до схеми на малюнку 2, але припустимо, що ми отримали лог не лише старту крон-команди, а й інші логи. Наприклад, у вас може бути щось подібне до цього:

Малюнок 5. Приклад можливих логів

Малюнок 5. Приклад можливих логів

Що ми бачимо: повідомлення для певного облікового запису продюситься, консьюмер починає обробляти інформацію з облікового запису, але з’являється помилка. Вона пов’язана з \RuntimeException, тому email не може бути відправлений на вказаний акаунт. Це вже корисно: бачимо місце збою і можемо заглиблюватися в код, приклад якого зображено нижче:

Малюнок 6. Приклад коду консьюмера

Малюнок 6. Приклад коду консьюмера

Тут є якісь try…catch, робота з репозиторієм і сервісами та багато іншого. Ви можете розбиратися в усьому, що називається, вручну, але я пропоную спростити собі життя. У цьому допоможуть Xdebug та PhpStorm. Враховуючи те, що проблема тут пов’язана з \RuntimeException, можна налаштувати PhpStorm на зупинку під час дебагінгу відразу в тому місці, де викидається помилка.

На малюнку 7 зображено вікно дебагу PhpStorm. Воно дозволяє подивитися, скажімо, Stack Trace і поставити брейкпойнти при запуску коду в дебаг-режимі. Навіщо їх ставити тут, якщо можна в коді ткнути біля номера? Але ж ми хочемо поставити брейкпойнт на ексепшен. Для цього заходьте до View Breakpoints, де буде перелік активних брейкпойнтів — і до них додавайте власний:

 Малюнок 7. Блок Debug в PhpStorm

Малюнок 7. Блок Debug в PhpStorm

Можете додати PHP Exception Breakpoints, як це показано далі:

Малюнок 8. Вікно налаштування брейкпойнтів

Малюнок 8. Вікно налаштування брейкпойнтів

У нашому випадку це \RuntimeException. Додаємо його та ставимо галочку Suspend execution для зупинки виконання, коли система натрапить на таку помилку. Залишається зберегти налаштування та запустити код.

Малюнок 9. Вікно налаштування брейкпойнтів з доданим \RuntimeException

Малюнок 9. Вікно налаштування брейкпойнтів з доданим \RuntimeException

На малюнку 10 ви можете побачити, що до тестового прикладу додано перевірку на довжину репорту для користувача. Це дуже зручно. У нижній лівій частині екрана PhpStorm видно весь трейс виклику послідовності до ексепшену.

Також можна переглянути доступні в області видимості змінні. Також є перевірка на довжину контенту: вона не повинна перевищувати 20 символів. А головне: ви бачите, де прихований ексепшен — і вже начебто готові вирішувати проблему з ненадсиланням повідомлень:

Малюнок 10. Приклад зупинки коду перед викидом помилки

Малюнок 10. Приклад зупинки коду перед викидом помилки

Постає питання: як зрозуміти, наскільки саме довжина контенту перевищує записане значення? Ми бачимо, що воно більше 20 символів, проте рахувати кожен із них незручно. Тут зверніть увагу на наявність strlen для змінної content і на те, що дебаг-інструменти PhpStorm дозволяють у рантаймі виконувати код. Тому просто виділяємо функцію strlen разом з аргументами та натискаємо на кнопку калькулятора, як це показано на малюнку 11.

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

Курс Power Skills For Tech від Enlgish4IT.
Зменшіть кількість непорозумінь на робочому місці та станьте більш ефективним у спілкуванні в мультикультурній команді. Отримайте знижку 10% за промокодом ITCENG.
Реєстрація на курс
Малюнок 11. Вікно виконання коду під час дебагінгу

Малюнок 11. Вікно виконання коду під час дебагінгу

У результаті будні розробника, який при налагодженні намагається по логах зрозуміти суть усіх процесів, ідеально описується мемом:

¯\_(ツ)_/¯

«Метод качечки» для дебагінгу

Дебагінг — це процес пошуку помилок у програмі. Для цього далеко не завжди потрібні дебагери та безпосередньо Xdebug. Іноді чудово може допомогти так званий «метод качечки». Я вважаю його одним із найкорисніших способів пошуку джерела проблеми в будь-якому проєкті.

Уявіть, що кодуєте складну бізнес-логіку, але з’являються помилки, збої в базі тощо. Ви звертаєтеся за порадою до колеги й описуєте йому ситуацію: потрібно ось це, я роблю такий-то запит до бази, отримую такі дані, потім роблю ось це… У певний момент вас осяює: ось тут при обробці запиту ви робите щось не так, як написано в тасці. Саме завдяки опису деталей проблеми та формулювання питання до колеги нерідко вдається самому знайти відповідь.

Чому цей спосіб називається «методом качечки»? Тому що тут вам не потрібен навіть колега — його замінить іграшкова качечка біля монітору, з якою ви подумки починаєте «обговорювати» проблему в проєкті.

Як не дивно, такий «дебаг» є дуже дієвим. Це доведено мною і багатьма моїми знайомими — спробуйте й самі.

Вивчення деталей реалізації процесу — це і є налагодження у широкому сенсі цього слова. Не має значення, що саме ви аналізуєте. Це може бути читання коду, перегляд логів чи опис степів у нотатках. Усі це стане в нагоді не тільки для виправлення проблем, але й при знайомстві з новим кодом, проєктом або командою.

За рахунок цього, а також підключення Xdebug та «методу качечки» ви швидше зрозумієте, що відбувається під капотом, розберетесь із логікою процесів та матимете повноцінне уявлення про сервіс. Як результат, зможете швидше та ефективніше створювати нові фічі.

Цікаві можливості PhpStorm

Цей інструмент приховує багато опцій налагодження програм. Я виділю кілька, на мій погляд, найбільш корисних:

  • Умовні брейкпойнти

Уявіть, що в циклі є 1000 ітерацій, але треба зупинитися на 403-й, тому що саме в ній вибирається поганий ID і щось іде не так. Для цього в брейкпойнт потрібно натиснути правою кнопкою миші та вказати конкретну умову для зупинки процесу.

Англійська для початківців від Englishdom.
Для тих, хто тільки починає вивчати англійську і хоче вміти використовувати базову лексику і граматику.
Реєстрація на курс
  • Брейкпойнти з логуванням

Ці брейкпойнти можуть не зупинятися, а просто писати інформацію про проблеми. Таке рішення дозволить, наприклад, у Laravel та Symphony не додавати логи для дебагінгу, які знадобляться лише раз. Також подібна функція стане в нагоді при дебагінгу бібліотеки, де не особливо напишеш код. У такому разі доданий у коді брейкпойнт залогує потрібні текст та змінні.

  • Брейкпойнти для эксепшенів

Раніше в тексті я вже розглядав приклад, коли багато коду, але викидається незрозумілий ексепшен, і нічого немає. Тут вам і допоможе цей тип брейкпойнту.

  • Брейкпойнти, що не зупиняються

Завдяки таким брейкпойнтам, аби не переписувати код програми та бібліотеку, можна вставити фрагменти коду PHP, які трохи змінять логіку. Це ідеальне рішення, коли вам потрібно просто подивитися, що дасть інакше виконання коду.

  • Зміни значень змінних у рантаймі

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

  • Виконання фрагментів коду під час дебагінгу
  • Англійська для IT від Englishdom.
    В межах курсу можна освоїти ключові ІТ-теми та почати без проблем говорити з іноземними колегами.
    Дійзнайтеся більше

Подібно до процесу визначення довжини звіту.

Навіщо вам профілювання?

Цей мем — красномовна ілюстрація про розробників, які залазять якнайглибше в програму, намагаючись зрозуміти, що з нею відбувається. Один із етапів такого занурення — профілювання. Аби розібратися, що це і де використовується, звернемося до прикладу.

Нижче наведена помилка через проблеми з пам’яттю (малюнок 14). Ви ще не знаєте, де вона і чому виникла. У логах картинка проста, але не очевидна: повідомлення продюсується, обробник починає роботу, але все падає по пам’яті:

Малюнок 14. Приклад логів

Малюнок 14. Приклад логів

Допоможе профілювання програми. Почати його можна зі звичайного профайлера, вбудованого у PHP-дебагер (його треба лише налаштувати в php.ini). Для візуалізації процесу раджу використовувати KCachegrind. Далі зображено репорт у цій тулзі за профайлінгом:

Малюнок 15. Приклад відкритого звіту профілювання в KCachegrind

Малюнок 15. Приклад відкритого звіту профілювання в KCachegrind

Тут багато можливостей для відображення зібраної інформації. Наприклад, можна вибрати дані пам’яті або процесорного часу. У моєму випадку після запуску тестового консьюмера коду на початку траю видно роботу з репозиторієм, який займає 99,75% пам’яті. Це одразу вказує на проблему.

Причини та варіанти рішення можуть бути різні. Припустимо, за контекстом програми може вибиратися дуже багато записів. Доводиться конфігурувати доктрину, щоб вона не перекладала все в сутності. Чи можна зробити ліміти та чанкування вибірки або використовувати курсори. Але це вже деталі реалізацій. Головне, що варто запам’ятати: профілювання показало нам місце підвищеного споживання пам’яті. Причому я це запускав на кейсі, коли ми отримуємо помилку. Незважаючи на те, що програма була перервана, отриманої до падіння інформація все одно достатньо для ухвалення рішення.

Крім цього, профайлер може будувати дерево викликів (малюнок 16). Тут зображено відсоток використання пам’яті та CPU і показано, що і де було викликано. Цей функціонал стане в нагоді не лише для пошуку збоїв, але й при вивченні коду нового для вас консьюмера з десятками вкладених сервісів.

Малюнок 16. Приклад дерева викликів у KCachegrind

Малюнок 16. Приклад дерева викликів у KCachegrind

Куди рухатися далі

Інструменти налагодження потрібно використовувати комплексно. Логування звужує область пошуку проблеми, а дебагінг, профілювання та інші методи допомагають розібратися в деталях. Їхнє спільне застосування дасть реально відчутну вигоду та прискорить пошук рішення.

Однак це ще не все. Те, що ви прочитали у цій статті — короткий екскурс у тему відладки. Щоб впевнено опанувати цей скіл, раджу поступово вивчати й інші інструменти дебагінгу, а їх чимало. Зорієнтую вас, куди можна рухатися далі, та порекомендую звернути увагу на такі тулзи:

  • Sentry — потужний інструмент для трекінгу різних ексепшенів у застосунку.
  • Курс English For Tech course від Enlgish4IT.
    Лише 7 тижнів по 20-30 хвилин щоденного навчання допоможуть вам подолати комунікативні бар'єри. Отримайте знижку 10% за промокодом ITCENG.
    Дійзнайтеся більше
  • New Relic — має різні можливості для відладки та моніторингу застосунку, а також широку функціональність — аж до профілювання коду.
  • Xhprof — змінює профайлер PHP таким чином, щоб профілювати не весь процес, а конкретний метод. Це корисно у великих фреймворках із роздутою ієрархією та великою кількістю вкладених класів.
  • Prometheus та GrafanaLabs — ці інструменти для різних метрик здебільшого потрібні для продакшену. Вони можуть зберігати та відображати значення різних показників. Наприклад, кількість повідомлень за секунду, кількість оброблюваних консьюмером із RabbitMQ або Kafka повідомлень, величина RPC застосунку, бізнес-метрики тощо. При цьому метрики матимуть гарну, наочну візуалізацію.
  • Blackfire — досить популярний у великих проєктах, хоча й платний інструмент дебагінгу.
  • Graylog — може покращити пошук логів та має деякі функції, відсутні в Kibana.
  • Datadog — застосовується для моніторингу сервісів, підтримує роботу з різними видами метрик та логів.
  • Charles — можна використовувати як проксі для трекінгу всього трафіку. Його можна вбудувати в застосунок і спостерігати за трафіком, який надсилається. Більше підходить для налагодження клієнтів та комунікації фронтенду з бекендом.
  • WireShark — цей сніфер нагадує Charles, але має більше функцій. Наприклад, дозволяє сканувати локальну мережу в комп’ютері навіть без налаштування проксі. Таким чином ви зможете підключитися до налаштованої в Docker мережі та зрозуміти, які запити і де саме проходять. Те, що треба, в роботі з великою кількістю міжсервісних повідомлень, сирими запитами у взаємодії з базою та формуванні HTTP-протоколу. Ви зможете спуститися по всіх рівнях OSI та подивитися, що відбувається — аж до пакетів, котрі відправляються. Втім, це потрібно при дебагінгу мережі, і в моїй практиці знадобилося лише раз. Однак усе це корисно знати тим, хто прагне розвиватися як профі.

Курс English For IT: Communication від Enlgish4IT.
Почни легко працювати та спілкуватися з мультикультурними командами та міжнародними клієнтами. Отримайте знижку 10% за промокодом ITCENG.
Інформація про курс

Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.

Англійська для IT від Englishdom.
В межах курсу можна освоїти ключові ІТ-теми та почати без проблем говорити з іноземними колегами.
Дійзнайтеся більше

Цей матеріал – не редакційний, це – особиста думка його автора. Редакція може не поділяти цю думку.

Топ-5 найпопулярніших блогерів березня

PHP Developer в ScrumLaunch
Всего просмотровВсього переглядів
2229
#1
Всего просмотровВсього переглядів
2229
Founder at Shallwe, Python Software Engineer (Django/React)
Всего просмотровВсього переглядів
111
#2
Всего просмотровВсього переглядів
111
Career Consultant в GoIT
Всего просмотровВсього переглядів
93
#3
Всего просмотровВсього переглядів
93
CEO & Founder в Trustee
Всего просмотровВсього переглядів
92
#4
Всего просмотровВсього переглядів
92
Рейтинг блогерів

Найбільш обговорювані статті

Топ текстів

Ваша жалоба отправлена модератору

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: