응용 프로그램 개발을 위한 모범 사례 > ThingWorx 응용 프로그램 모니터링 > 모니터링 도구
모니터링 도구
ThingWorx Platform은 Java 기술로 개발되었습니다. 이 단원에서 설명한 진단 및 모니터링 도구는 JVM(Java Virtual Machine)에서 성능 메트릭과 기타 데이터를 수집하도록 설계되었습니다. 이러한 도구를 사용하면 JVM 레이어를 통해 ThingWorx 응용 프로그램을 모니터링할 수 있습니다. 이 도구는 JVM에서 다음 데이터를 가져옵니다.
• 메모리 작업 - 서버에 할당된 메모리 리소스가 충분한지 그리고 JVM GC(가비지 수집) 작업에 걸리는 시간을 확인합니다.
• 스레드 성능 - ThingWorx 응용 프로그램에서 성능 문제를 일으킬 수 있는 긴 트랜잭션 또는 스레딩 문제가 있는지 확인합니다.
PSM(PTC System Monitor)
PSM(PTC System Monitor)은 Dynatrace에 의해 구동되는 응용 프로그램 성능 모니터링 시스템입니다. PTC에는 ThingWorx 응용 프로그램의 모니터링 요구사항에 맞게 사용자 정의된 Dynatrace가 있습니다. PSM은 시스템 관리자에게 응용 프로그램의 작동 상태에 영향을 주는 문제를 감지, 진단 및 수정하는 도구를 제공합니다. 테스트 시스템과 및 생산 시스템을 모두 모니터링합니다. 이는 ThingWorx 응용 프로그램의 성능에는 영향을 주지 않습니다. 이 모듈은 유지 보수 계약의 일부로 제공되며 핵심 플랫폼 모니터링에 대한 추가 라이선스 구매가 필요하지 않습니다.
PSM은 JVM 수준에서 발생하는 스레드 수준 활동을 모니터링하고 이 활동을 PurePaths라는 독점 기술로 만듭니다. PSM PurePath에는 서버에서의 ThingWorx 서비스 실행 경로와 실행 시간에 대한 세부 정보가 포함되어 있습니다. 또한 실행된 SQL 문과 같은 컨텍스트 정보를 포함합니다.
PSM 기능
PSM을 사용하여 다음을 수행할 수 있습니다.
• 실패하기 전에 응용 프로그램의 가동 시간을 늘립니다.
◦ 허용치를 넘을 때(예: CPU를 많이 사용하는 경우) 알림을 보냅니다. 이렇게 하면 관리자가 시스템 전반적인 문제로 전환되기 전에 수정 작업을 수행하여 이러한 문제를 해결할 수 있습니다.
◦ 시스템 리소스 사용에 대한 기록 보기를 제공합니다. 이렇게 하면 시스템 리소스에 대한 미래의 용량 요구사항을 예상할 수 있습니다.
• 다음과 같이 모니터링 기능을 향상시킵니다.
◦ 단순하고 사용자 정의 가능한 대시보드를 사용하여 시스템 및 구성 요소의 상태를 요약합니다.
◦ 자세한 내용을 확인하기 위해 개별 트랜잭션, 사용자 및 서버 구성 요소에 대한 드릴 다운 기능을 제공합니다.
◦ 시스템 상태에 영향을 주는 문제에 대한 통합 인시던트 목록을 포함합니다.
• 실시간 데이터를 사용하여 진단 기능을 개선합니다.
◦ PurePath 기술을 사용하여 진단 데이터를 실시간으로 수집하고 기록 성능 메트릭을 기록합니다.
◦ 자세한 정보 설정이 추가로 포함된 문제 재현 및 PTC 기술 지원의 도움을 받은 문제 해결에 소요되는 시간을 절약합니다.
PSM은 ThingWorx 응용 프로그램에서 계속해서 실시간 데이터를 수집 및 기록하고 이 데이터를 더 오래 저장합니다. PSM에서 수집한 데이터를 사용하면 사용자 정의 응용 프로그램에 영향을 주는 다음 성능 메트릭을 지속적으로 모니터링할 수 있습니다. 이렇게 하면 성능 문제를 초래하는 이벤트를 개발 팀 또는 PTC 지원 서비스에서 재생할 수 있습니다.
• JVM 메모리 성능
• PurePath 시간 데이터를 사용하는 서비스 실행 시간
• 운영 체제 메모리, CPU 및 데이터베이스 질의 메트릭
• ThingWorx 로그 오류 및 기타 인시던트
직접 JVM 모니터링
직접 JVM 모니터링 도구는 Oracle 또는 ThingWorx Support Tool 확장 프로그램에서 제공합니다. 이러한 도구를 PSM과 함께 사용하면 자세한 성능 데이터를 얻을 수 있습니다. PSM을 사용하지 않는 경우에는 JVM에서 직접 데이터를 수집하는 것이 성능 문제를 식별하고 해결하는 좋은 대안이 됩니다. ThingWorx 응용 프로그램에 대해 다음 JVM 진단을 모니터링하는 것이 좋습니다.
• JVM의 기본 제공 기능인 가비지 수집 로깅을 사용하여 시간 경과에 따른 메모리 성능을 모니터링합니다.
• ThingWorx Support Tool 확장 프로그램을 사용하는 스레드 수준 수집 및 분석입니다.
ThingWorx 서버의 메모리 사용량 모니터링
JVM(Java Virtual Machine)은 GC(가비지 수집기)를 사용하여 원래대로 자체 메모리(힙)를 관리합니다. GC는 Java 힙에서 사용되지 않는 객체를 식별하고 제거합니다. GC에 의해 수집된 세부 정보를 로깅하여 ThingWorx 서버의 메모리 사용량을 모니터링할 수 있습니다.
GC 로그 파일을 사용하여 메모리 소비량의 추세를 식별할 수 있습니다. 이러한 추세에 따라 성능 향상을 위해 Apache Tomcat 서버의 최대 힙 매개 변수를 변경해야 하는지를 확인할 수 있습니다. 따라서 Apache Tomcat 서버에서 GC에 대한 로깅을 설정하는 것이 좋습니다.
JVM에는 런타임에 호출되는 플래그가 있습니다. 이러한 플래그는 GC 이벤트 유형, 이벤트 시작 시 소비된 메모리 양, GC 이벤트에 의해 해제된 메모리 양 및 GC 이벤트의 기간 등 GC 이벤트에 대한 통계를 작성하는 데 사용됩니다.
JVM을 시작할 때마다 GC 로그 파일을 덮어씁니다. 서버를 다시 시작하는 동안 로그 파일을 백업하는 것이 좋습니다. 이는 서버가 메모리 사용 때문에 다시 시작되었는지를 분석하는 데 도움이 됩니다.
GCEasy.io 및 Chewiebug GC Viewer와 같은 분석 도구를 사용하여 가비지 수집에서 로그를 분석할 수 있습니다.
Linux에 대한 가비지 수집 로깅을 설정하는 방법(setenv.sh)
Linux에 대한 가비지 수집기 로깅을 설정하려면 다음 단계를 수행합니다.
1. 텍스트 편집기에서 $CATALINA_HOME/bin/setenv.sh 스크립트를 엽니다.
setenv.sh 스크립트 파일은 일부 설치에서 사용 불가능할 수도 있습니다. 파일이 없으면 해당 위치에 새 setenv.sh 파일을 만듭니다.
2. 다음 텍스트를 큰따옴표로 묶어 JAVA_OPTS 변수 끝에 추가합니다.
-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
JAVA_OPTS이 setenv.sh 파일에 지정되어 있지 않거나 setenv.sh 파일이 새 파일인 경우 파일에 다음 줄을 추가합니다.
JAVA_OPTS=”-XX:+UseG1GC -Xloggc:/logs/gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails”
다음을 참고하십시오.
▪ -XX:+PrintGC 옵션은 덜 자세한 출력 로그를 반환합니다. 예를 들어, 출력 로그에 다음과 같은 세부 정보가 포함됩니다.
2017-10-10T13:22:49.363-0400: 3.096: [GC (Allocation Failure) 116859K->56193K(515776K), 0.0728488 secs]
▪ -XX:+PrintGCDetails 옵션은 자세한 출력 로그를 반환합니다. 예를 들어, 출력 로그에 다음과 같은 세부 정보가 포함됩니다.
2017-10-10T13:18:36.663-0400: 35.578: [GC (Allocation Failure) 2017-10-10T13:18:36.663-0400: 35.578: [ParNew: 76148K->6560K(76672K), 0.0105080 secs] 262740K->193791K(515776K), 0.0105759 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
3. setenv.sh 스크립트의 끝에 다음 줄을 추가합니다. 이 코드는 Apache Tomcat 서버를 시작하기 전에 기존 gc.out 파일을 gc.out.restart에 자동으로 백업합니다.
# Backup the gc.out file to gc.out.restart when a server is started.
if [ -e "$CATALINA_HOME/logs/gc.out" ]; then
cp -f "$CATALINA_HOME/logs/gc.out" "$CATALINA_HOME/logs/gc.out.restart"
fi
4. 파일의 변경 내용을 저장합니다.
5. 운영 체제에 적용할 수 있는 서비스 컨트롤러를 사용하여 Apache Tomcat 서비스를 다시 시작합니다.
Windows에 대한 가비지 수집 로깅을 설정하는 방법(Apache Service Manager)
Windows에 대한 가비지 수집기 로깅을 설정하려면 다음 단계를 수행합니다.
1. Windows 탐색기에서 <Tomcat_home>\bin을 찾습니다.
2. 이름에 w가 있는 실행 파일을 시작합니다. 예를 들어, Tomcat<version number>w.exe입니다.
3. Java 탭을 클릭합니다.
4. Java Options 필드에 다음 줄을 추가합니다.
-Xloggc:logs/gc_%t.out
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGC 옵션과 -XX:+PrintGCDetails 옵션 간 정보는 Linux에 대한 가비지 수집 로깅을 설정하는 방법(setenv.sh) 단원을 참조하십시오.
5. 적용을 클릭하여 변경 내용을 서비스 구성에 저장합니다.
6. 일반 탭에서 중지를 클릭합니다.
7. 시작을 클릭하여 Apache Tomcat 서비스를 다시 시작합니다.
새 가비지 수집 로그가 %CATALINA_HOME%\logs\gc_<Tomcat_Restart_Timestamp>.out 파일에 기록됩니다.
Support Tool 확장 프로그램을 사용하여 진단 데이터 수집
ThingWorx Support Tool 확장 프로그램은 ThingWorx 기술 지원을 위한 정보를 수집하는 데 사용됩니다. 이 정보는 ThingWorx 응용 프로그램의 문제를 해결하는 동안 사용됩니다. 확장 프로그램에서 다음 진단 데이터를 수집합니다.
• Java 스레드 덤프 - 특정 시간에 JVM(Java Virtual Machine)에서 실행 중인 모든 스레드에 대한 세부 정보입니다. 지정된 기간의 스레드 활동을 기록할 수 있습니다.
• Java 힙 덤프 - 특정 시간에 JVM(Java Virtual Machine)의 힙 공간에 있는 모든 객체에 대한 세부 정보입니다.
이 확장 프로그램을 ThingWorx 인스턴스에 설치하는 것이 좋습니다. 이 확장 프로그램은 support.ptc.com의 PTC 소프트웨어 다운로드 페이지에서 사용할 수 있습니다.
VisualVM 및 기타 JMX 모니터링 도구
VisualVM은 Java 응용 프로그램에 대한 데이터를 수집하는 모니터링 도구입니다. VisualVM을 사용하여 ThingWorx 응용 프로그램을 모니터링할 수 있습니다. 메모리 및 CPU 사용에 대한 정보를 수집합니다. 힙 덤프를 생성하고 분석하며 메모리 누수를 추적합니다. 로컬에서 또는 원격 시스템에서 실행되는 응용 프로그램에 대한 데이터를 수집할 수 있습니다.
VisualVM은 Java 응용 프로그램에 대한 정보를 그래픽으로 볼 수 있는 인터페이스를 제공합니다.
VisualVM은 Java JDK와 함께 사용할 수 있습니다. VisualVM의 연결 설정에 대한 자세한 내용은 ThingWorx 도움말 센터의 Apache Tomcat Java 옵션 설정 단원을 참조하십시오.
JMX(Java Management Extensions)를 사용하여 JVM과 통합되는 다른 도구에서도 유사한 모니터링 기능을 제공합니다.
VisualVM은 응용 프로그램의 성능에 영향을 주는 다음과 같은 주요 메트릭을 캡처합니다.
• JVM 메모리 성능
• 스레드를 실행하는 데 필요한 시간
• 운영 체제 메모리 및 CPU 메트릭
• 데이터베이스 연결 풀 모니터링
VisualVM은 약 20분 동안 실시간 데이터를 추적합니다.
ThingWorx 응용 프로그램 로그 모니터링
오류 또는 기타 비정상적인 작업에 대해 ThingWorx 응용 프로그램 로그를 정기적으로 모니터링해야 합니다. 오류는 ThingWorx와 함께 사용되는 사용자 정의 스크립트 또는 플랫폼 레이어에서 발생할 수 있습니다. 매일 오류 로그에서 메시지를 검토하는 것이 좋습니다.
오류에 대한 스택 추적을 쓰기 위한 LoggingSubsystem 옵션 구성
LoggingSubsystem의 스택 추적 사용 옵션이 오류 메시지 및 관련 스택 추적을 로그 파일에 씁니다. 기본적으로 LoggingSubsytem은 스택 추적(호출 스택)을 디스크에 쓰도록 구성되어 있지 않습니다. 예외 및 오류 메시지의 호출 스택을 ThingworxStorage/logs 폴더에 있는 ErrorLog.log 파일에 쓰도록 스택 추적 사용 옵션을 설정합니다. 오류를 디버깅하는 동안 스택 추적에 함수 호출에 대한 세부 정보를 포함하도록 이 옵션을 설정하는 것이 좋습니다.
응용 프로그램 로그 유지
로그 수준에 따라 로그에 표시되어야 하는 세부 단위가 결정됩니다. 문제를 적극적으로 해결하지 않는 한 응용 프로그램의 로그 수준을 정보 또는 경고와 같은 최소 자세한 정보 표시로 유지하는 것이 좋습니다. 로그 자세한 정보 표시를 디버그, 추적 또는 모두로 상향 지정할 때는 주의해야 합니다. 이는 ThingWorx 성능에 좋지 않은 영향을 미칠 수 있습니다. 플랫폼에서 사용 가능한 리소스가 부족한 경우 응용 프로그램의 예기치 않은 동작이 발생할 수 있습니다.
로그는 서버의 /ThingworxStorage/logs 폴더에 별도의 파일로 저장됩니다. 로그는 logs 폴더에 있는 archives 폴더에 보관됩니다. 로그 순환 규칙은 로깅 하위 시스템의 로그 보존 설정에 설정된 파일 크기 및 시간 구성을 기반으로 합니다. 이러한 설정은 런타임에 변경되고 적용될 수 있습니다.
시스템 > 하위 시스템 > LoggingSubsystem > 구성에서 다음 롤오버 구성을 지정할 수 있습니다.
• 파일 크기 - 로그 파일의 크기가 최대 파일 크기(단위: KB) 필드에 정의된 크기에 도달하거나 초과하면 로그 파일이 보관됩니다. 로그의 기본 파일 크기는 100000KB로 설정됩니다. 설정할 수 있는 최대 파일 크기는 1000000KB입니다.
• 시간 - 로그 이벤트가 트리거될 때 매일 자정에 파일이 롤오버됩니다. 로그가 archives 폴더로 이동합니다. 기본적으로 archives 폴더에 있는 로그가 7일 이상이 되면 삭제됩니다. 기본값은 최대 보관 일 수 필드에서 변경할 수 있습니다. 1일 ~ 90일을 지정할 수 있습니다.
로그 크기를 모니터링하는 것이 중요합니다. 파일을 먼저 백업하거나 오래된 정보가 포함된 파일을 삭제하여 일관성 있게 로그 파일을 제거합니다.