AEM(Adobe Experience Manager) 자산 관점에서 모니터링은 다음 프로세스 및 기술에 대한 관찰과 보고를 포함해야 합니다.
시스템 CPU
시스템 메모리 사용
시스템 디스크 IO 및 IO 대기 시간
시스템 네트워크 IO
JMX MBean:
OSGi 콘솔 상태 검사
일반적으로 AEM Assets은 라이브 모니터링과 장기 모니터링이라는 두 가지 방법으로 모니터링할 수 있습니다.
개발 단계나 고로드 상황에서 라이브 모니터링을 수행하여 환경의 성능 특성을 파악해야 합니다. 일반적으로 라이브 모니터링은 도구 모음을 사용하여 수행해야 합니다. 다음은 권장 사항입니다.
시각적 VM:Visual VM을 사용하면 CPU 사용, Java 메모리 사용을 비롯한 자세한 Java VM 정보를 볼 수 있습니다. 또한 인스턴스에서 실행되는 코드를 샘플링하고 평가할 수 있습니다.
위쪽:맨 위에는 CPU, 메모리 및 IO 사용을 비롯한 사용 통계를 표시하는 대시보드가 표시되는 Linux 명령입니다. 인스턴스에서 일어나고 있는 일에 대한 높은 수준의 개요를 제공합니다.
위쪽:상단은 대화형 프로세스 뷰어입니다. Top이 제공할 수 있는 기능 외에 자세한 CPU 및 메모리 사용량을 제공합니다. 이 핫픽스는 yum install htop
또는 apt-get install htop
을 사용하여 대부분의 Linux 시스템에 설치할 수 있습니다.
위쪽:Iotop은 디스크 IO 사용을 위한 세부 대시보드입니다. 여기에는 디스크 IO를 사용하는 프로세스와 사용하는 양을 나타내는 막대와 미터가 표시됩니다. Iotop은 yum install iotop
또는 apt-get install iotop
을 사용하여 대부분의 Linux 시스템에 설치할 수 있습니다.
위쪽:이 보고서는 이더넷/네트워크 사용에 대한 자세한 정보를 표시합니다. 이 경우 이더넷을 사용하는 엔티티에 대한 통신 채널 통계별 정보와 이들이 사용하는 대역폭의 양을 표시합니다. 이벤트는 yum install iftop
또는 apt-get install iftop
을 사용하여 대부분의 Linux 시스템에 설치할 수 있습니다.
Java Flight 레코더(JFR):비프로덕션 환경에서 무료로 사용할 수 있는 Oracle의 상업용 도구입니다. 자세한 내용은 Java Flight Recorder를 사용하여 CQ 런타임 문제 진단을 참조하십시오.
AEM error.log 파일:AEM error.log 파일에서 시스템에 기록된 오류에 대한 세부 정보를 확인할 수 있습니다. 조사해야 하는 오류를 식별하려면 tail -F quickstart/logs/error.log
명령을 사용합니다.
워크플로우 콘솔:워크플로우 콘솔을 활용하여 뒤로 지연되거나 문제가 발생하는 워크플로우를 모니터링할 수 있습니다.
일반적으로 이러한 도구를 함께 사용하여 AEM 인스턴스의 성능에 대한 포괄적인 아이디어를 얻을 수 있습니다.
이러한 도구는 표준 도구이며 Adobe에서 직접 지원되지 않습니다. 추가 라이선스는 필요하지 않습니다.
AEM 인스턴스의 장기 모니터링은 라이브로 모니터링되는 것과 동일한 부분을 장기간 모니터링해야 합니다. 환경에 대한 경고를 정의하는 것도 포함됩니다.
Splunk™ 및 Elastic Search/Logstash/Kabana(ELK)와 같이 로그를 집계하는 데 사용할 수 있는 여러 가지 도구가 있습니다. AEM 인스턴스의 가동 시간을 평가하려면 시스템에 관련된 로그 이벤트를 파악하고 이를 기반으로 경고를 생성하는 것이 중요합니다. 개발 및 작업 방침에 대한 뛰어난 지식을 통해 로그 수집 프로세스를 조정하여 중요한 경고를 생성하는 방법을 보다 잘 이해할 수 있습니다.
환경 모니터링에는 다음 모니터링이 포함됩니다.
각 항목을 모니터링하려면 NewRelic™ 및 AppDynamics™와 같은 외부 도구가 필요합니다. 이러한 도구를 사용하여 시스템 활용도, 워크플로우 백업, 상태 점검 실패 또는 웹 사이트에 대한 인증되지 않은 액세스 등과 같이 시스템별 경고를 정의할 수 있습니다. Adobe은 다른 도구에 비해 특정 도구를 권장하지 않습니다. 사용자에게 적합한 툴을 찾고 이를 활용하여 설명한 항목을 모니터링할 수 있습니다.
내부 애플리케이션 모니터링에는 JVM, 컨텐츠 저장소 등 AEM 스택을 구성하는 애플리케이션 구성 요소를 모니터링하고 플랫폼에 내장된 사용자 정의 애플리케이션 코드를 통해 모니터링할 수 있습니다. 일반적으로 JMX Mbeans를 통해 수행되므로 SolarWinds™, HP OpenView™, Hyperic™, Zabbix™ 등과 같이 널리 사용되는 많은 모니터링 솔루션을 통해 직접 모니터링할 수 있습니다. JMX에 대한 직접 연결을 지원하지 않는 시스템의 경우 셸 스크립트를 작성하여 JMX 데이터를 추출하고 이러한 시스템에 기본적으로 이해하는 형식으로 표시할 수 있습니다.
JMX Mbeans에 대한 원격 액세스는 기본적으로 활성화되어 있지 않습니다. JMX를 통한 모니터링에 대한 자세한 내용은 JMX 기술을 사용한 모니터링 및 관리를 참조하십시오.
대부분의 경우 통계를 효과적으로 모니터링하려면 기준선이 필요합니다. 기준을 만들려면 미리 결정된 기간 동안 정상적인 작업 조건에서 시스템을 관찰한 다음 일반 지표를 식별합니다.
JVM 모니터링
Java 기반 애플리케이션 스택과 마찬가지로 AEM은 기본 Java 가상 시스템을 통해 제공된 리소스에 따라 달라집니다. JVM에 의해 노출되는 플랫폼 MXBeans를 통해 이러한 리소스 중 많은 수의 상태를 모니터링할 수 있습니다. MXBeans에 대한 자세한 내용은 플랫폼 MBean 서버 및 플랫폼 MXBeans 사용을 참조하십시오.
다음은 JVM에 대해 모니터링할 수 있는 몇 가지 기준 매개 변수입니다.
메모리
MBean: lava.lang:type=Memory
참고:이 콩에서 제공하는 정보는 바이트 단위로 표시됩니다.
스레드
java.lang:type=Threading
AEM 모니터링
또한 AEM은 JMX를 통해 통계 및 작업 세트를 표시합니다. 이러한 기능은 시스템 상태를 평가하고 사용자에게 영향을 주기 전에 잠재적인 문제를 식별하는 데 도움이 될 수 있습니다. 자세한 내용은 AEM JMX MBeans의 설명서를 참조하십시오.
다음은 AEM용으로 모니터링할 수 있는 몇 가지 기준선 매개 변수입니다.
복제 에이전트
MBean:com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
URL:/system/console/jmx/com.adobe.granite.replication:type=agent,id="<AGENT_NAME>"
인스턴스:작성자 및 모든 게시 인스턴스(플러시 에이전트의 경우) 1개
경보 임계값:QueueBlocked
값이 true이거나 QueueNumEntries
값이 기준선의 150%보다 큰 경우
경보 정의:시스템에 복제 대상이 다운되었거나 연결할 수 없음을 나타내는 차단된 큐가 있습니다. 네트워크 또는 인프라 문제로 인해 과도한 항목이 큐에 올라가 시스템 성능에 부정적인 영향을 줄 수 있는 경우가 많습니다.
참고:MBean 및 URL 매개 변수 <AGENT_NAME>
의 경우 모니터링할 복제 에이전트 이름으로 대체합니다.
세션 카운터
org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
상태 검사
작업 대시보드에서 사용할 수 있는 상태 확인에는 모니터링에 해당하는 JMX MBean이 있습니다. 그러나 사용자 정의 상태 검사를 작성하여 추가 시스템 통계를 표시할 수 있습니다.
다음은 즉시 사용 가능한 상태 검사로, 모니터링에 도움이 됩니다.
시스템 확인
org.apache.sling.healthcheck:name=systemchecks,type=HealthChec
k복제 큐
org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
응답 성능
org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
쿼리 성능
org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
활성 상태 번들
오류 로그
org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
모니터링 과정에서 문제가 발생하는 경우 AEM 인스턴스의 일반적인 문제를 해결하기 위해 수행할 수 있는 몇 가지 문제 해결 작업이 있습니다.
OutOfMemoryError
로그를 확인합니다. 자세한 내용은 메모리 문제 분석을 참조하십시오.access.log
및 error.log
파일을 검사합니다. 사용자 지정 코드 예외 항목을 나타낼 수 있는 패턴을 찾습니다. 모니터하는 이벤트 목록에 추가합니다.