학습 목표
이 모듈을 마치면 다음을 수행할 수 있습니다.
- 로그 파일에서 로그 메시지 찾기
- 애플리케이션의 정상적인 작동 중에 생성되는 메시지 유형과 이를 읽는 방법을 설명하십시오.
- 오류 메시지 해석
- 스택 추적 읽기
- Mendix에서 발생할 수 있는 일반적인 오류를 인식하세요
로그 수준에는 특정 계층 구조가 있었습니다. 로그 수준을 Critical 로 설정했을 때 표시되는 모든 메시지는 로그 수준을 Error 로 설정했을 때도 표시됩니다 . 로그 수준은 또한 특정 메시지의 심각도를 나타냅니다. 경험에 따르면 로그 수준이 높을수록 오류가 더 심각합니다.
아래 스크린샷에서 Trace 수준 의 로그 메시지 예를 볼 수 있습니다 . 이러한 메시지는 MicroflowEngine 에서 보냅니다.
선택한 메시지를 더블클릭 하여 검사하면 타임스탬프, 이 메시지의 로그 레벨, 메시지를 생성한 로그 노드와 같은 모든 관련 정보를 제공하는 세부 정보 창이 표시됩니다.
중괄호 안에 JSON 데이터가 포함된 메시지는 활동이 실행 중임을 나타냅니다.
JSON 데이터를 자세히 살펴보면 이 로그 메시지를 MyFirstModule 모듈의 Microflow에 있는 액티비티와 연관시킬 수 있다는 것을 금방 알 수 있습니다. CreateAndChange 유형인 것 같습니다 . CreateAndChange 라는 액티비티는 Microflow 도구 상자에 없지만 Create object 라는 액티비티가 있습니다 . 이 로그 메시지를 생성한 Microflow를 살펴보면 실제로 여기서 사용된 것은 Create object 액티비티라는 것을 알 수 있습니다.
{
"current_activity":
{
"caption":"Create Employe(name)",
"type":"CreateAndChange"
},
"name":"MyFirstModule.ACT_Employee_CreateNew",
"type":"Microflow"
}
스택 추적
때때로 로그 메시지에는 스택 추적이라는 것이 포함됩니다. 이는 컴퓨터 프로그래밍 세계의 개념입니다. 소프트웨어의 오류를 분석하는 데 사용됩니다. 스택 추적에는 오류가 발생했을 때 메모리에 있던 모든 함수 목록이 포함됩니다.
오류를 해결하는 데 도움이 되는 것은 Stack Trace의 처음 몇 줄입니다. 스택 추적에는 항상 Exception이 있습니다 . 아래 예에서 Exception이 MicroflowException인 것을 볼 수 있습니다.
이는 오류가 데이터베이스 엔진이나 보안 엔진이 아닌 Microflow에서 발생했음을 알려줍니다.
Exception 뒤에 오류 메시지가 나오는데, 이 경우 REST 서비스를 호출하는 동안 오류가 발생했음을 알려줍니다. Stack Trace는 또한 오류가 발생한 위치를 알려줍니다. 모듈 이름, Microflow 이름을 볼 수 있으며 활동 이름도 알려줍니다. 그 뒤에 내부적으로 호출된 함수 목록이 나오는데, 이 경우 함수가 하나만 있습니다. 이 특정한 경우에는 또 다른 예외가 표시되는데, 이번에는 404: Not Found라는 메시지가 나타나 무언가를 찾을 수 없음을 나타냅니다.
방금 한 분석을 바탕으로, REST 서비스를 호출하는 데 오류가 있었다는 결론을 내릴 수 있습니다. 그 오류는 REST 서비스를 찾을 수 없다는 것이었습니다. 좋은 다음 단계는 Call REST 활동의 웹 주소가 올바르게 설정되었는지 확인하는 것입니다.
스택 추적을 이해하는 것이 항상 쉬운 것은 아니지만, 로그 메시지의 이 부분에 포함된 정보는 종종 문제를 해결할 때 매우 귀중합니다.
일반적인 오류
로그 메시지를 읽는 기술은 메시지를 생성한 오류의 근본 원인이 무엇인지 이해하는 데 크게 의존합니다. Mendix의 맥락에서 모든 가능한 오류 메시지와 해석을 포함하는 포괄적인 목록을 제공할 방법은 없지만, 알아야 할 몇 가지 일반적인 문제가 있습니다.
1. Null Pointers
2. Security Errors
기본적으로 마이크로플로는 엔티티 액세스 규칙을 고려하지 않습니다
그러나 추가 보안을 위해 마이크로플로 내에서 엔티티 액세스를 적용하는 경우 엔티티의 액세스 규칙이 올바르게 설정되지 않은 경우 오류가 발생할 수 있습니다. 예를 들어, 사용자가 갑자기 변경이나 커밋을 할 수 없게 되어 오류가 발생하고 수행하려는 프로세스가 중단될 수 있습니다.
3. Mathematical Errors
계산을 하거나 데이터를 비교할 때 예상치 못한 결과가 반환되면 수학적 오류가 발생합니다. 계산을 할 때는 값이 비어 있지 않은지 확인해야 합니다. 데이터를 비교할 때는 방정식의 양쪽에 비교할 데이터가 있는지도 확인해야 합니다.
4. Java Out of Memory Errors
앱이 예상대로 실행되지 않는 경우, 가비지 수집이 모든 객체를 수집하는 데 많은 시간이 걸리고 확보하는 공간은 매우 적기 때문일 수 있습니다.
이는 대체로 짧은 시간 내에 많은 객체를 생성하거나, 때로는 빠른 속도로 연속해서 많은 객체를 생성하여 발생합니다.
5. Autocommitted Objects
사용자가 세션을 종료한 후에 볼 수 있는 로그 항목 중 하나는 해당 세션에 속한 객체의 자동 커밋을 설명합니다 . 즉, 사용자가 여러 개의 다른 연관된 객체로 객체를 생성하고 연관된 객체만 커밋했지만 첫 번째 객체는 커밋하지 않았다는 의미입니다. 그러면 첫 번째 객체는 자동 커밋 상태를 받는데, 그 이유는 해당 객체와의 연결이 데이터베이스에 저장되었기 때문입니다.
세션이 종료되는 순간, 첫 번째 객체가 삭제됩니다. 이는 고아(삭제 동작이 제대로 설정되지 않은 경우)가 발생하거나 연관된 객체가 삭제되는데, 이는 사용자가 기대하는 바가 아닙니다.
6. Application Breaks on Startup
모든 앱은 시작 후 마이크로플로를 가질 수 있습니다. 이 마이크로플로에서 무언가 잘못되면 예외를 throw하거나 false를 반환하여 앱이 실행되지 않게 됩니다.
애플리케이션이 시작되지 않았다는 것을 알려주는 로그 항목은 세부 정보가 없는 한 줄로 구성되어 있습니다. 그러나 이전 로그 항목에서 오류의 원인을 설명하는 세부 정보를 찾을 수 있을 것입니다. 상황을 재현하려면 microflow 디버깅 도구를 사용할 수 있습니다.
앱이 해당 마이크로플로우의 중단점에서 일시 정지하지 않으므로, 애프터-스타트업 마이크로플로우를 직접 디버깅할 수 없다는 점에 유의하세요. 애프터-스타트업 마이크로플로우를 디버깅하려면 이를 비활성화한 다음 앱의 다른 곳에서 수동으로 트리거해야 합니다(예: 버튼에 연결).
출처 : https://academy.mendix.com/link/paths/104/Track-Application-Behavior-with-Logging
'LowCode (Mendix) Advanced > Track Application Behavior with Logging' 카테고리의 다른 글
| Implementing Logging In Your Own App (2) | 2024.10.22 |
|---|---|
| The Components of a Log Message Explained (0) | 2024.10.21 |
| The Log Message (0) | 2024.10.21 |