로그 항목 찾기
사용자가 예상치 못한 동작을 보고하는 경우, 문제를 해결할 수 있는 충분한 정보를 제공하지 않는 경우가 있습니다. 이럴 때 로그가 귀중한 리소스가 됩니다. 하지만 로그에는 모든 사용자에 대한 메시지가 포함되어 있어 관심 있는 로그 메시지를 찾기가 어렵습니다. 이때 타임스탬프가 도움이 될 수 있습니다. 로그는 위에서 아래로 시간순으로 작성되며 가장 최근 로그 메시지가 맨 아래에 표시됩니다.
이 시간 순서는 도움이 되지만, 오랜 기간의 메시지가 포함된 파일에서 로그 메시지를 찾기가 어려울 수 있습니다. 따라서 로그는 주기적으로 분류되어 Mendix Cloud에 날짜별로 저장됩니다. 이렇게 하면 로그 메시지를 빠르게 찾을 수 있습니다.
로그 파일을 분석할 때는 어떤 표준 시간대가 사용되고 있는지 확인하는 것이 중요합니다. 사용자의 표준 시간대와 서버의 표준 시간대가 서로 다르게 설정되어 있을 수 있습니다. 로그 메시지를 찾기 시작할 때 로그에 적용되는 표준 시간대와 오류를 보고한 사용자가 어느 표준 시간대를 사용하는지 확인해야 합니다.
평소와 같은 업무
정보 로그 수준에서 볼 수 있는 대부분의 메시지는 "평소와 같은 업무"로 분류할 수 있습니다. 애플리케이션은 현재 상황을 매우 상세하게 보고하고 있을 뿐입니다. Mendix 애플리케이션을 시작할 때마다 이러한 메시지의 예를 볼 수 있습니다. 대부분은 이해하기 쉬우며, 일부는 조금 더 노력이 필요하지만 난해해 보이는 것은 없습니다. 로그 수준인 디버그 및 추적도 마찬가지입니다. 아래 스크린샷에서 추적 수준의 로그 메시지 예시를 볼 수 있습니다. 이러한 메시지는 MicroflowEngine에 의해 전송됩니다.
선택한 메시지를 두 번 클릭하여 검사하면 타임스탬프, 이 메시지의 로그 수준, 메시지를 생성한 로그 노드 등 모든 관련 정보를 제공하는 세부 정보 창이 표시됩니다. 메시지 자체는 처음에는 생소할 수 있지만 읽어보면 의미가 있다는 것을 알 수 있습니다. 중괄호 안에 JSON 데이터가 포함된 이 메시지는 활동이 실행 중임을 나타냅니다.
해당 JSON 데이터를 자세히 살펴보면 이 로그 메시지를 MyFirstModule 모듈의 마이크로플로우에 있는 활동과 연관시킬 수 있다는 것을 금방 알 수 있습니다. CreateAndChange 유형인 것 같습니다. 마이크로플로우 도구 상자에는 CreateAndChange라는 활동은 없지만 Create object라는 활동은 있습니다. 그리고 이 로그 메시지를 생성한 마이크로플로우를 보면 실제로 여기에 사용된 것이 Create object 활동이라는 것을 알 수 있습니다.
{
"current_activity":
{
"caption":"Create Employe(name)",
"type":"CreateAndChange"
},
"name":"MyFirstModule.ACT_Employee_CreateNew",
"type":"Microflow"
}
보시다시피 정상적인 작업에서는 로그 메시지를 비교적 쉽게 해석할 수 있습니다.
오류 발생
오류가 발생하면 오류 메시지를 해석하기가 더 어려울 수 있습니다. 메시지를 쉽게 읽을 수 있는 정도는 시스템의 어느 부분에서 로그 메시지를 생성하는지에 따라 달라집니다. Mendix 개발자가 작성한 시스템의 일부인 경우에는 메시지가 무슨 일이 일어났는지 이해할 수 있는 충분한 컨텍스트를 제공할 가능성이 높습니다. 그러나 개발자가 어떤 맥락에서 메시지가 표시될지 미리 알 수 있는 것은 아닙니다. 따라서 애플리케이션 모델, 데이터베이스 엔진, 런타임과 같은 Mendix 용어를 잘 이해하는 것이 중요합니다.
이러한 모든 것들이 로그 메시지를 이해하는 데 도움이 되지만, 때때로 Mendix에서 작성한 코드에서 오류가 발생하지 않는 경우도 있습니다. Mendix의 개발자들은 이러한 오류를 모두 잡아내어 사용자에게 유용한 것으로 변환하기 위해 노력하지만, 때로는 오류가 너무 특이해서 Mendix에 해당하는 오류가 없을 때도 있습니다. 이러한 경우 로그 메시지에 오류를 진단하는 데 도움이 되는 추가 정보가 표시됩니다.
발생할 수 있는 오류 메시지의 유형은 크게 세 가지로 분류할 수 있습니다:
- 멘딕스 오류 메시지: 이 오류 메시지는 플랫폼 개발자가 작성했습니다. 일반적으로 Mendix 관련 컨텍스트를 제공하기 때문에 이해하기 쉽습니다.
- 모듈 오류 메시지: 이러한 메시지는 직접 또는 마켓플레이스에서 가져온 모듈의 개발자가 작성했습니다. 이러한 메시지는 Mendix를 사용하여 개발하는 사람들이 작성한 것이므로 충분한 컨텍스트를 제공하기 때문에 이해하기 쉬운 경우가 많습니다.
- 라이브러리 오류 메시지: Mendix와 Mendix 마켓플레이스의 대부분의 모듈은 라이브러리를 사용하여 개발됩니다. 예를 들어 런타임은 라이브러리를 사용하여 외부 API에 연결하고 Excel 가져오기 모듈은 라이브러리를 사용하여 Excel 파일을 읽습니다. 드물지만 라이브러리 개발자가 오류 메시지를 표시하는 경우도 있습니다. 개발자는 자신의 라이브러리가 Mendix 애플리케이션에서 사용된다는 사실을 전혀 몰랐기 때문에 이러한 메시지는 가장 적은 양의 컨텍스트를 제공하며 이해하기 가장 어려울 수 있습니다.
다음 강의에서는 Mendix 애플리케이션에서 생성되는 대부분의 오류 메시지에서 찾을 수 있는 정보에 대해 자세히 알아보겠습니다.
스택 추적
때때로 로그 메시지에 스택 추적이라는 것이 포함될 수 있습니다. 이것은 컴퓨터 프로그래밍 세계에서 유래한 개념입니다. 소프트웨어의 오류를 분석하는 데 사용됩니다. 스택 추적에는 오류가 발생했을 때 메모리에 있던 모든 함수 목록이 포함됩니다.
메인 마이크로플로우가 서브 마이크로플로우를 호출하고, 서브 마이크로플로우가 다시 메인 마이크로플로우를 호출하는 식의 구조를 상상해 보세요. 새로운 마이크로플로우가 호출될 때마다 Mendix는 현재 마이크로플로우를 목록에 넣어 하위 마이크로플로우가 완료되면 어디로 이동해야 할지 알 수 있도록 합니다. 이 목록을 스택이라고 합니다. 이후의 각 마이크로플로우 호출 활동은 현재 마이크로플로우의 이름을 스택에 추가합니다. 이 작업이 완료되면 Mendix는 하위 마이크로플로로 이동합니다. Mendix가 메인 마이크로플로로 돌아올 때마다 하위 마이크로플로의 이름이 스택에서 제거됩니다. 하위 마이크로플로우 중 하나에서 오류가 발생하면 스택이 로그 메시지에 추가되므로 오류가 발생한 마이크로플로우와 해당 지점까지 호출된 마이크로플로우의 체인을 확인할 수 있습니다.
프로그래밍에서 스택 추적은 정확히 같은 방식으로 작동합니다. 차이점은 이러한 스택 추적이 상당히 길고 이해하기 어렵다는 점입니다. 또한 Mendix 내의 스택 추적은 마이크로플로우에만 국한되지 않습니다. 아래에서 전체 스택 추적의 예를 볼 수 있습니다. 이 이미지의 요점은 크기를 설명하는 것이니 자세한 내용은 걱정하지 마세요. 이 강의의 다음 파트에서 스택 추적의 중요한 세부 사항에 대해 알아보겠습니다.
스택 추적이 발생하면 처음 10~20줄에 집중해야 합니다. 무엇이 잘못되었는지 파악하는 데 사용할 수 있는 중요한 정보를 제공합니다. 대부분의 경우 이 정보만으로도 해결책을 찾을 수 있습니다. 하지만 이 정보로 문제를 해결할 수 없는 경우 스택 추적 사본을 저장해 두세요. 다른 Mendix 개발자나 Mendix 지원팀이 오류를 분석할 때 매우 유용하게 사용할 수 있습니다!
앞서 언급했듯이 스택 추적의 처음 몇 줄이 오류를 해결하는 데 도움이 됩니다. 스택 추적에는 항상 예외가 있습니다. 아래 예제에서는 예외가 MicroflowException인 것을 볼 수 있습니다. 이는 데이터베이스 엔진이나 보안 엔진이 아닌 마이크로플로우에서 오류가 발생했음을 알려줍니다. 예외 뒤에는 오류 메시지가 나오는데, 이 경우 나머지 서비스를 호출하는 동안 오류가 발생했음을 알려줍니다. 스택 추적은 오류가 발생한 위치도 알려줍니다. 모듈 이름, 마이크로플로우 이름을 볼 수 있으며 활동 이름도 알려줍니다. 그 다음에는 내부적으로 호출된 함수 목록(이 경우에는 하나의 함수만)이 표시됩니다. 이 특정 경우에는 또 다른 예외가 표시되며 이번에는 404라는 메시지가 표시됩니다: 찾을 수 없음으로 무언가를 찾지 못했음을 나타냅니다.
방금 수행한 분석에 따르면 REST 서비스를 호출하는 데 오류가 발생했다는 결론을 내릴 수 있습니다. 이 오류는 REST 서비스를 찾을 수 없다는 것입니다. 다음 단계는 Call REST 활동의 웹 주소가 올바르게 설정되었는지 확인하는 것입니다.
스택 추적을 이해하는 것이 항상 쉬운 것은 아니지만, 로그 메시지의 이 부분에 포함된 정보는 문제를 해결할 때 매우 유용한 경우가 많습니다. 이러한 유형의 메시지를 분석하는 작업에 대비하기 위해 다음 모듈에서는 몇 가지 일반적인 오류에 대해 설명합니다.
일반적인 오류
로그 메시지를 읽는 기술은 메시지를 생성한 오류의 근본 원인이 무엇인지 이해하는 데 크게 의존합니다. Mendix의 맥락에서 가능한 모든 오류 메시지와 그 해석을 포함하는 전체 목록을 제공할 방법은 없지만, 알아두어야 할 몇 가지 일반적인 문제가 있습니다.
널 포인터
컴퓨터는 주어진 명령에 오류가 없기를 기대합니다. 컴퓨터에게 "이 날짜에 하나 추가"라고 말하면 컴퓨터는 날짜를 수신할 것으로 예상합니다. 어떤 이유로든 날짜가 수신되지 않으면 컴퓨터는 사용자에게 알려줍니다. 그 방법은 "널 포인터" 또는 "널"을 받았다고 불평하는 것입니다.
보안 오류
기본적으로 마이크로플로우에서는 엔티티 액세스 규칙을 고려하지 않습니다(마이크로플로우에 대한 액세스 권한이 있거나 없는 경우). 그러나 보안 강화를 위해 마이크로플로우 내에서 엔티티 액세스를 적용하는 경우 엔티티에 대한 액세스 규칙이 올바르게 설정되지 않은 경우 오류가 발생할 수 있습니다. 예를 들어, 사용자가 갑자기 변경이나 커밋을 할 수 없게 되어 오류가 발생하고 진행 중인 프로세스가 중단될 수 있습니다.
수학적 오류
수학적 오류는 계산을 수행하거나 데이터를 비교할 때 예상치 못한 결과가 반환될 때 발생합니다. 계산을 할 때는 값이 비어 있지 않은지 확인해야 합니다. 데이터를 비교할 때는 방정식의 양쪽에 비교할 데이터가 있는지 확인해야 합니다.
Java 메모리 부족 오류
앱이 예상대로 실행되지 않는다면 가비지 컬렉션이 모든 개체를 수집하는 데 많은 시간이 걸리면서 공간을 거의 확보하지 못하고 있기 때문일 수 있습니다.
자동 커밋된 개체
사용자가 세션을 종료한 후 볼 수 있는 로그 항목 중 하나는 해당 세션에 속한 개체의 자동 커밋에 대한 설명입니다. 즉, 사용자가 다른 여러 개의 연결된 개체가 있는 개체를 만들고 해당 연결된 개체만 커밋했지만 첫 번째 개체는 커밋하지 않았음을 의미합니다. 그러면 첫 번째 개체에 대한 연결이 데이터베이스에 저장되었으므로 첫 번째 개체는 자동 커밋 상태를 받습니다.
세션이 종료되는 순간 첫 번째 개체가 삭제됩니다. 이렇게 하면 삭제 동작이 제대로 설정되지 않은 경우 고아가 발생하거나 사용자가 예상한 것과는 다르게 연결된 개체가 삭제됩니다.
앱이 해당 마이크로플로우의 중단점에서 일시 중지되지 않으므로 시작 후 마이크로플로우를 직접 디버깅할 수 없습니다. 시작 후 마이크로플로우를 디버깅하려면 이를 비활성화한 다음 앱의 다른 곳에서 수동으로 트리거해야 합니다(예: 버튼에 연결하여).
