애플리케이션 디버깅에는 항상 문제가 있습니다. Node.js의 비동기 워크 플로는 이 어려운 프로세스에 복잡성을 추가합니다. 

비동기 스택 추적에 쉽게 액세스하기 위해 V8 엔진에 일부 업데이트가 있었지만 대부분의 경우 애플리케이션의 기본 스레드에서 오류가 발생하여 디버깅이 약간 어렵습니다. 또한 Node.js 애플리케이션이 충돌 할 때 일반적으로 코어 덤프를 분석하기 위해 복잡한 CLI 도구에 의존해야 합니다.

https://blog.heroku.com/debug-node-applications 

이 기사에서는 Node.js 애플리케이션을 디버그 하는 더 쉬운 방법을 살펴 보겠습니다.

Logging 

물론 로깅 없이는 완전한 개발자 툴킷은 없습니다. 우리는 로컬 개발의 코드 전체에 console.log 문을 배치하는 경향이 있지만 이는 프로덕션에서 실제로 확장 가능한 전략이 아닙니다. 실제 오류에서 중요한 정보를 식별하려면 필터링 및 정리를 수행하거나 일관된 로깅 전략을 구현해야 할 수 있습니다.

대신 적절한 로그 지향 디버깅 전략을 구현하려면 Pino 또는 Winston과 같은 로깅 도구를 사용하십시오. 이를 통해 로그 수준 (INFO, WARN, ERROR)을 설정하여 자세한 로그 메시지를 로컬로 인쇄 할 수 있고 프로덕션 용으로 심각한 메시지 만 인쇄 할 수 있습니다. 이러한 로그를 수집기 또는 LogStash, Papertrail 또는 Slack과 같은 다른 엔드 포인트로 스트리밍 할 수도 있습니다.

Node Inspect 및 Chrome DevTools 작업 

로깅은 응용 프로그램이 우리가 예상 한 방식으로 작동하지 않는 이유를 이해하는 데 지금까지만 도움이 됩니다. 정교한 디버깅 세션의 경우 중단 점을 사용하여 코드가 실행되는 순간에 어떻게 동작하는지 검사 할 수 있습니다.

이를 위해 Node Inspect를 사용할 수 있습니다. Node Inspect는 Node.js와 함께 제공되는 디버깅 도구입니다. 실제로는 프로그램을 위한 Chrome DevTools의 구현 일 뿐이며 중단 점을 추가하고 단계별 실행을 제어하고 변수를 보고 호출 스택을 따를 수 있습니다.

Node Inspect를 시작하는 몇 가지 방법이 있지만 가장 쉬운 방법은 --inspect-brk 플래그를 사용하여 Node.js 애플리케이션을 호출하는 것입니다.

$ node --inspect-brk $your_script_name

프로그램을 시작한 후 Chrome 브라우저에서 chrome : // inspect URL로 이동하여 Chrome DevTools로 이동합니다. Chrome DevTools를 사용하면 브라우저에서 JavaScript를 디버깅 할 때 일반적으로 기대할 수 있는 모든 기능을 사용할 수 있습니다. 더 좋은 도구 중 하나는 메모리를 검사하는 기능입니다. 힙 스냅 샷과 프로필 메모리 사용량을 생성하여 메모리가 할당되는 방식을 이해하고 잠재적으로 메모리 누수를 막을 수 있습니다.

지원되는 IDE 사용 

특정 방식으로 프로그램을 시작하는 대신 많은 최신 IDE는 노드 애플리케이션 디버깅도 지원합니다. Chrome DevTools에있는 많은 기능 외에도 로그 포인트 생성 및 여러 디버깅 프로필 생성과 같은 자체 기능을 제공합니다. 이러한 IDE에 대한 자세한 내용은 검사기 클라이언트에 대한 Node.js 가이드를 확인하세요.

NDB 사용 

또 다른 옵션은 Node.js 용 독립형 디버거 인 ndb를 설치하는 것입니다. 격리 된 로컬 디버거와 마찬가지로 브라우저에서 사용할 수 있는 동일한 DevTools를 사용합니다. 또한 DevTools에서 사용할 수 없는 몇 가지 추가 기능이 있습니다. 제자리에서 편집을 지원하므로 코드를 변경하고 디버거 플랫폼에서 직접 업데이트 된 논리를 지원할 수 있습니다. 이것은 빠른 반복을 수행하는 데 매우 유용합니다.

Post-Mortem Debugging 

메모리 액세스 오류와 같은 치명적인 오류로 인해 애플리케이션이 충돌한다고 가정합니다. 드물지만, 특히 앱이 네이티브 코드에 의존하는 경우 발생합니다.

이러한 종류의 문제를 조사하려면 llnode를 사용할 수 있습니다. 프로그램이 충돌하면 llnode를 사용하여 JavaScript 스택 프레임 및 개체를 C / C ++ 측의 개체에 매핑하여 검사 할 수 있습니다. 이를 사용하려면 먼저 프로그램의 코어 덤프가 필요합니다. 이렇게 하려면 process.exit 대신 process.abort를 사용하여 코드에서 프로세스를 종료해야 합니다. process.abort를 사용하면 노드 프로세스가 종료시 코어 덤프 파일을 생성합니다.

llnode가 제공 할 수 있는 것을 더 잘 이해하기 위해 여기에 몇 가지 기능을 보여주는 비디오가 있습니다.

유용한 노드 모듈 

위의 모든 것 외에도 추가 디버깅을 위해 권장 할 수 있는 몇 가지 타사 패키지도 있습니다.

debug 

이 중 첫 번째는 간단히 디버그라고 합니다. 디버그를 사용하면 함수 이름 또는 전체 모듈을 기반으로 로그 메시지에 특정 네임 스페이스를 할당 할 수 있습니다. 그런 다음 특정 환경 변수를 통해 콘솔에 인쇄 할 메시지를 선택적으로 선택할 수 있습니다.

예를 들어 다음은 sequelize, express : application 및 express : router와 같은 전체 애플리케이션 및 미들웨어 스택에서 여러 메시지를 로깅 하는 Node.js 서버입니다.

DEBUG 환경 변수를 express : router로 설정하고 동일한 프로그램을 시작하면 express : router로 태그가 지정된 메시지 만 표시됩니다.

이러한 방식으로 메시지를 필터링 하면 코드 로깅을 대폭 변경할 필요 없이 애플리케이션의 단일 세그먼트가 어떻게 작동하는지 파악할 수 있습니다.

trace and clarify 

함께 연결되는 두 개의 추가 모듈은 추적 및 명확화입니다.

trace는 호출되는 비동기 메서드 (Node.js가 기본적으로 제공하지 않는 로드맵)에 대해 훨씬 더 자세한 정보를 제공하여 비동기 스택 추적을 보강합니다. clarify는 Node.js 내부에 특정한 스택 추적에서 모든 정보를 제거하여 도움을 줍니다. 이를 통해 응용 프로그램에만 해당하는 함수 호출에 집중할 수 있습니다.

이러한 모듈은 프로덕션 환경에서 실행하는 데 권장되지 않습니다! 로컬 개발 환경에서 문제를 디버깅 할 때만 활성화해야 합니다.