AEM 6의 작업 대시보드는 시스템 운영자가 AEM 시스템 상태를 한 눈에 모니터링할 수 있도록 해줍니다. 또한 AEM의 관련 측면에 대한 자동 생성 진단 정보를 제공하고 자체 포함된 유지 관리 자동화를 구성 및 실행하여 프로젝트 운영 및 지원 사례를 크게 줄일 수 있습니다. 작업 대시보드는 사용자 정의 상태 확인 및 유지 관리 작업으로 확장할 수 있습니다. 또한 JMX를 통해 외부 모니터링 도구에서 작업 대시보드 데이터에 액세스할 수 있습니다.
작업 대시보드:
로 이동하여 액세스할 수 있습니다 도구 - 작업 AEM 시작 화면에서 클릭합니다.
작업 대시보드에 액세스하려면 로그인한 사용자가 "운영자" 사용자 그룹의 일부여야 합니다. 자세한 내용은 사용자, 그룹 및 액세스 권한 관리.
상태 보고서 시스템은 Sling 상태 검사를 통해 AEM 인스턴스의 상태에 대한 정보를 제공합니다. OSGI, JMX, HTTP 요청(JSON의 방식)이나 Touch UI를 통해 이 작업을 수행합니다. 구성 가능한 특정 카운터의 측정 및 임계값을 제공하며 경우에 따라 문제를 해결하는 방법에 대한 정보를 제공합니다.
아래에 설명된 몇 가지 기능이 있습니다.
다음 상태 보고서 특정 제품 영역에 대해 양호한 또는 나쁜 상태를 나타내는 카드 시스템입니다. 이러한 카드는 JMX 및 기타 소스의 데이터를 집계하고 처리된 정보를 MBean으로 다시 노출하는 Sling 상태 확인의 시각화입니다. 또한 이러한 MBeans는 JMX 웹 콘솔아래에 있는 org.apache.sling.healthcheck 도메인.
상태 보고서 인터페이스는 도구 - 작업 - 상태 보고서 AEM 시작 화면의 메뉴 또는 다음 URL을 통해 직접 메뉴:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
카드 시스템은 다음 세 가지 가능한 상태를 노출합니다. 확인, 경고 및 중요. 상태는 규칙 및 임계값의 결과이며, 카드 위로 마우스를 이동한 다음 작업 표시줄에서 톱니바퀴 아이콘을 클릭하여 구성할 수 있습니다.
AEM 6에는 두 가지 유형의 상태 검사가 있습니다.
An 개별 상태 확인 상태 카드에 해당하는 단일 상태 확인입니다. 개별 상태 검사는 규칙이나 임계값을 사용하여 구성할 수 있으며 식별된 상태 문제를 해결하기 위한 하나 이상의 힌트와 링크를 제공할 수 있습니다. 예를 들어 "오류 로그" 검사를 살펴보겠습니다. 인스턴스 로그에 ERROR 항목이 있으면 상태 확인의 세부 사항 페이지에서 해당 항목을 찾습니다. 페이지 맨 위에는 진단 도구 섹션의 "로그 메시지" 분석기에 대한 링크가 표시되어 이러한 오류를 자세히 분석하고 로거를 다시 구성할 수 있습니다.
A 복합 상태 검사 은 여러 개별 수표의 정보를 집계하는 수표입니다.
복합 상태 확인은 태그 필터링. 기본적으로 동일한 필터 태그가 있는 모든 단일 검사는 복합 상태 확인으로 그룹화됩니다. 종합 상태 확인에는 모든 단일 검사가 합계에서 OK 상태도 있음을 확인한 경우에만 OK 상태가 있습니다.
작업 대시보드에서 개별 및 복합 상태 확인의 결과를 시각화할 수 있습니다.
개별 상태 검사를 만들려면 다음 두 단계를 수행합니다. sling 상태 확인 구현 및 대시보드의 구성 노드에서 상태 확인에 대한 항목 추가
Sling 상태 검사를 만들려면 Sling HealthCheck 인터페이스를 구현하는 OSGI 구성 요소를 만듭니다. 이 구성 요소를 번들 내에 추가합니다. 구성 요소의 속성은 상태 확인을 완전히 식별합니다. 구성 요소가 설치되면 상태 확인에 대해 JMX MBean이 자동으로 생성됩니다. 자세한 내용은 Sling 상태 확인 설명서 추가 정보.
OSGI 서비스 구성 요소 주석으로 작성된 Sling Health Check 구성 요소의 예:
@Component(service = HealthCheck.class,
property = {
HealthCheck.NAME + "=Example Check",
HealthCheck.TAGS + "=example",
HealthCheck.TAGS + "=test",
HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean"
})
public class ExampleHealthCheck implements HealthCheck {
@Override
public Result execute() {
// health check code
}
}
다음 MBEAN_NAME
속성은 이 상태 확인에 대해 생성된 mbean의 이름을 정의합니다.
상태 검사를 만든 후 작업 대시보드 인터페이스에서 액세스할 수 있도록 새 구성 노드를 만들어야 합니다. 이 단계에서는 상태 확인의 JMX Mbean 이름( MBEAN_NAME
Analytics JavaScript용 URL 섹션을 참조하십시오. 상태 확인에 대한 구성을 만들려면 CRXDE를 열고 노드(유형)를 추가합니다 nt:구조화되지 않음)을 클릭하여 제품에서 사용할 수 있습니다. /apps/settings/granite/operations/hc
새 노드에서 다음 속성을 설정해야 합니다.
이름: sling:resourceType
String
granite/operations/components/mbean
이름: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
위의 리소스 경로는 다음과 같이 생성됩니다. 상태 확인의 mbean 이름이 "test"인 경우 경로 끝에 "test"를 추가합니다. /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
따라서 최종 경로는 다음과 같습니다.
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
다음을 확인합니다. /apps/settings/granite/operations/hc
경로에는 다음 속성이 true로 설정되어 있습니다.
sling:configCollectionInherit
sling:configPropertyInherit
이 프로세스는 구성 관리자에게 새 구성을 기존 구성과 병합하도록 지시합니다 /libs
.
복합 상태 확인의 역할은 일련의 공통 기능을 공유하는 여러 개의 개별 상태 검사를 집계하는 것입니다. 예를 들어 보안 복합 상태 확인은 보안 관련 확인을 수행하는 모든 개별 상태 검사를 그룹화합니다. 복합 검사를 만드는 첫 번째 단계는 OSGI 구성을 추가하는 것입니다. 작업 대시보드에 표시하려면 단순 확인과 동일한 방법으로 새 구성 노드를 추가해야 합니다.
OSGI 콘솔의 웹 구성 관리자로 이동합니다. 액세스 https://serveraddress:port/system/console/configMgr
이라는 항목을 검색합니다. Apache Sling 복합 상태 검사. 찾은 후에는 두 가지 구성을 이미 사용할 수 있습니다. 하나는 시스템 확인 이고 다른 하나는 보안 확인을 위한 것입니다.
구성 오른쪽의 "+" 단추를 눌러 구성을 만듭니다. 아래와 같이 새 창이 나타납니다.
구성을 만들고 저장합니다. 새 구성으로 Mbean이 만들어집니다.
각 구성 속성의 목적은 다음과 같습니다.
hc.tags
).Apache Sling Composite 상태 확인의 새로운 각 구성에 대해 새 JMX Mbean이 만들어집니다.**
마지막으로 생성된 복합 상태 확인의 항목을 작업 대시보드 구성 노드에 추가해야 합니다. 절차는 개별 상태 확인과 동일합니다. 유형의 노드 nt:구조화되지 않음 는 /apps/settings/granite/operations/hc
. 노드의 리소스 속성은 다음 값으로 정의됩니다. hc.mean.name 를 반환합니다.
예를 들어, 구성을 만들고 hc.mbean.name 값 디스크 사용로 지정하는 경우 구성 노드는 다음과 같습니다.
이름: Composite Health Check
nt:unstructured
다음 속성을 사용합니다.
이름: sling:resourceType
String
granite/operations/components/mbean
이름: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
기본적으로 대시보드에 이미 있는 복합 검사 아래에 논리적으로 속하는 개별 상태 검사를 만들면 해당 복합 검사 아래에 자동으로 캡처되고 그룹화됩니다. 따라서 이러한 검사에 대한 구성 노드를 만들 필요가 없습니다.
예를 들어, 개별 보안 상태 검사를 만드는 경우 "보안" 태그로 설정되고, 작업 대시보드의 보안 검사 복합 체크 아래에 자동으로 나타납니다.
zHealthcheck 이름 | 설명 |
쿼리 성능 | 이 상태 검사가 단순해졌습니다 AEM 6.4및 는 이제 최근에 리팩터링한 내용을 확인합니다 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck. |
관찰 큐 길이 | 관찰 큐 길이는 모든 이벤트 리스너 및 백그라운드 관찰자에 대해 반복되며, 이들을 비교합니다
각 큐의 최대 길이는 별도의 구성(Oak 및 AEM)에서 가져오며, 이 상태 확인에서는 구성할 수 없습니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
쿼리 순회 제한 | 쿼리 순회 제한은
이 건강검진의 Mbean은 org.apache.sling.healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
동기화된 시계 | 이 수표는 문서 노드 클러스터. 다음 상태를 반환합니다.
이 건강검진의 Mbean은 org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClicks,type=HealthCheck. |
비동기 색인 | 비동기 인덱스 검사:
위기 및 경고 상태 임계값은 모두 구성할 수 있습니다. 이 건강검진의 Mbean은 org.apache.sling.healthcheck:name=asyncIndexHealthCheck,type=HealthCheck. 참고: 이 상태 확인은 AEM 6.4에서 사용할 수 있으며 AEM 6.3.0.1로 지원됩니다. |
큰 Lucene 색인 | 이 확인에서는
임계값은 구성할 수 있으며 상태 확인에 대한 MBean은 다음과 같습니다 org.apache.sling.healthcheck:name=largeIndexHealthCheck,type=HealthCheck. 참고: 이 검사는 AEM 6.4에서 사용할 수 있으며 AEM 6.3.2.0으로 지원됩니다. |
시스템 유지 관리 | 시스템 유지 관리는 모든 유지 관리 작업이 구성된 대로 실행 중인 경우 확인을 반환하는 복합 검사입니다. 주의 사항:
이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck. |
복제 큐 | 이 검사는 복제 에이전트를 반복하여 해당 대기열을 확인합니다. 큐 맨 위에 있는 항목의 경우 이 확인은 에이전트가 복제를 다시 시도한 횟수를 확인합니다. 에이전트가 복제 작업을 다시 시도하는 경우 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck. |
Sling 작업 |
Sling 작업 은 JobManager에서 큐에 있는 작업 수를 확인하고 와 비교합니다
maxNumQueueJobs 임계값 및:
큐에 있는 최대 작업 매개 변수 수만 구성할 수 있으며 기본값은 1000입니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=slingJobs,type=HealthCheck. |
성능 요청 | 이 수표는
이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck. |
오류 로그 | 이 확인은 로그에 오류가 있는 경우 경고 상태를 반환합니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
디스크 공간 | 디스크 공간 확인에서
두 임계값은 모두 구성할 수 있습니다. 검사는 세그먼트 저장소가 있는 인스턴스에서만 작동합니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
스케줄러 상태 확인 | 이 검사는 인스턴스에 60초 이상 실행되는 Quartz 작업이 있는 경우 경고를 반환합니다. 허용되는 기간 임계값은 구성할 수 있습니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
보안 확인 | 보안 확인은 여러 보안 관련 검사의 결과를 집계하는 종합입니다. 이러한 개별 상태 확인은 보안 검사 목록 설명서 페이지입니다. 이 검사는 인스턴스가 시작될 때 보안 연기 테스트로 유용합니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=securitychecks,type=HealthCheck |
활성 상태 번들 | 활성 번들은 모든 번들의 상태를 확인하고
무시 목록 매개 변수는 구성할 수 있습니다. 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck. |
코드 캐시 확인 | Java™ 7에 있는 CodeCache 버그를 트리거할 수 있는 몇 가지 JVM 조건을 확인하는 상태 확인입니다.
다음 이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=codeCacheHealthCheck,type=HealthCheck. |
리소스 검색 경로 오류 | 경로에 리소스가 있는지 확인합니다
이 상태 확인에 대한 MBean은 org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
기본적으로 기본 제공 AEM 인스턴스의 경우 상태 확인은 60초마다 실행됩니다.
을 구성할 수 있습니다 기간 사용 OSGi 구성 쿼리 상태 확인 구성 (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics)
상태 확인 대시보드는 Granite JMX Mbeans를 통해 Nagios와 통합할 수 있습니다. 아래 예제는 AEM을 실행하는 서버에서 사용된 메모리를 보여 주는 검사를 추가하는 방법을 보여줍니다.
모니터링 서버에 Nagios를 설정하고 설치합니다.
다음으로, NRPE(Nagios Remote Plugin Executor)를 설치합니다.
시스템에 Nagios 및 NRPE를 설치하는 방법에 대한 자세한 내용은 Nagios 설명서.
AEM 서버의 호스트 정의를 추가합니다. 구성 관리자를 사용하여 Nagios XI 웹 인터페이스를 통해 이 작업을 수행할 수 있습니다.
다음은 Nagios Core를 사용하는 경우 호스트 구성 파일의 예입니다.
define host {
address 192.168.0.5
max_check_attempts 3
check_period 24x7
check-command check-host-alive
contacts admin
notification_interval 60
notification_period 24x7
}
AEM 서버에 Nagios 및 NRPE를 설치합니다.
설치 check_http_json 플러그인을 사용하여 두 서버에 연결할 수 있습니다.
두 서버에서 일반 JSON 확인 명령을 정의합니다.
define command{
command_name check_http_json-int
command_line /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
}
AEM 서버에서 사용된 메모리에 대한 서비스를 추가합니다.
define service {
use generic-service
host_name my.remote.host
service_description AEM Author Used Memory
check_command check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes>
}
새로 만든 서비스에 대해 Nagios 대시보드를 확인합니다.
또한 작업 대시보드는 상태 확인 대시보드에서 오는 경고의 근본 원인을 찾고 문제를 해결하는 데 도움이 되는 진단 도구에 액세스하고 시스템 운영자에게 중요한 디버그 정보를 제공합니다.
가장 중요한 기능 중 하나는 다음과 같습니다.
로 이동하여 진단 도구 화면에 액세스할 수 있습니다 도구 - 작업 - 진단 AEM 시작 화면에서 클릭합니다. 다음 URL에 직접 액세스하여 화면에 액세스할 수도 있습니다. https://serveraddress:port/libs/granite/operations/content/diagnosis.html
로그 메시지 사용자 인터페이스에 기본적으로 모든 오류 메시지가 표시됩니다. 더 많은 로그 메시지를 표시하려면 적절한 로그 수준으로 로거를 구성합니다.
로그 메시지는 인메모리 로그 Appender를 사용하므로 로그 파일과 관련이 없습니다. 따라서 이 UI에서 로그 수준을 변경해도 기존 로그 파일에 로그인되는 정보가 변경되지 않습니다. 이 UI에서 로거를 추가 및 제거하면 메모리 로거에만 영향을 줍니다. 또한 로거 구성을 변경하면 in memory logger의 향후에 반영됩니다. 이미 기록되어 있고 더 이상 관련이 없는 항목은 삭제되지 않지만 나중에 유사한 항목이 기록되지 않습니다.
UI의 왼쪽 위 톱니바퀴 단추에서 로거 구성을 제공하여 기록되는 항목을 구성할 수 있습니다. 여기에서 로거 구성을 추가, 제거 또는 업데이트할 수 있습니다. 로거 구성은 로그 수준 (경고 / 정보 / 디버그) 및 필터 이름. 다음 필터 이름 은 기록되는 로그 메시지의 소스를 필터링하는 역할을 합니다. 또는 로거가 지정된 수준의 모든 로그 메시지를 캡처해야 하는 경우 필터 이름은 " 여야 합니다.루트". 로거의 수준을 설정하면 지정된 메시지보다 크거나 같은 수준의 모든 메시지 캡처가 트리거됩니다.
예:
모든 파일을 캡처할 계획이라면 오류 messages - 구성이 필요하지 않습니다. 기본적으로 모든 ERROR 메시지가 캡처됩니다.
모든 파일을 캡처할 계획이라면 오류, 경고 및 정보 messages - 로거 이름을 다음으로 설정해야 합니다. "루트" 및 로거 레벨을 다음과 같이 지정할 수 있습니다. 정보.
특정 패키지(예: com.adobe.granite)에서 오는 모든 메시지를 캡처할 계획이라면, 로거 이름을 다음으로 설정해야 합니다. "com.adobe.granite". 로거 레벨은 다음과 같이 설정됩니다. 디버그 (이렇게 하면 모든 오류, 경고, 정보, 및 디버그 메시지)를 사용할 수 있습니다.
지정된 필터를 통해 ERROR 메시지만 캡처하도록 로거 이름을 설정할 수 없습니다. 기본적으로 모든 ERROR 메시지가 캡처됩니다.
로그 메시지 사용자 인터페이스는 실제 오류 로그를 반영하지 않습니다. UI에서 다른 유형의 로그 메시지를 구성하지 않는 한 오류 메시지만 표시됩니다. 특정 로그 메시지를 표시하는 방법은 위의 지침을 참조하십시오.
진단 페이지의 설정은 로그 파일에 기록되는 설정과 반대로 영향을 주지 않습니다. 따라서 오류 로그에 INFO 메시지가 표시될 수 있지만 로그 메시지 UI에 표시되지 않을 수 있습니다. 또한 UI를 통해 특정 패키지에서 오류 로그에 영향을 주지 않고 DEBUG 메시지를 포착할 수 있습니다. 로그 파일을 구성하는 방법에 대한 자세한 내용은 로깅.
AEM 6.4 사용를 사용하면 유지 관리 작업이 정보 수준에서 더 많은 정보 형식으로 즉시 로그아웃됩니다. 이 워크플로우를 통해 유지 관리 작업의 상태를 더 잘 파악할 수 있습니다.
타사 도구(예: Splunk)를 사용하여 유지 관리 작업 활동을 모니터링하고 반응하는 경우 다음 로그 문을 사용할 수 있습니다.
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
요청 성능 페이지에서는 처리된 가장 느린 페이지 요청을 분석할 수 있습니다. 이 페이지에는 컨텐츠 요청만 등록됩니다. 특히, 다음 요청이 캡처됩니다.
/content
/etc/design
".html"
확장페이지가 표시됩니다.
기본적으로 가장 느린 20개의 페이지 요청이 캡처되지만 구성 관리자에서 제한을 수정할 수 있습니다.
[질의 성능] 페이지에서는 시스템에서 수행한 가장 느린 질의를 분석할 수 있습니다. 이 정보는 JMX Mbean의 저장소에서 제공합니다. 잭래빗에서 com.adobe.granite.QueryStat
JMX Mbean은 이 정보를 Oak 저장소에서 org.apache.jackrabbit.oak.QueryStats.
페이지가 표시됩니다.
지정된 쿼리의 경우 Oak는 아래에 저장소에 정의된 Oak 인덱스를 기반으로 가장 좋은 실행 방법을 알아내려고 합니다 oak:index 노드 아래에 있어야 합니다. 쿼리에 따라 Oak에서 다른 인덱스를 선택할 수 있습니다. Oak가 쿼리를 실행하는 방법을 이해하는 것은 쿼리를 최적화하는 첫 번째 단계입니다.
설명 쿼리는 Oak가 쿼리를 실행하는 방법을 설명하는 도구입니다. 로 이동하여 액세스할 수 있습니다 도구 - 작업 - 진단 AEM 시작 화면에서 클릭합니다. 그런 다음 쿼리 성능 그리고 쿼리 설명 탭.
기능
쿼리 UI 설명 을 입력한 후 쿼리를 입력하고 설명 버튼:
질의 설명 섹션의 첫 번째 항목은 실제 설명입니다. 설명은 쿼리를 실행하는 데 사용된 인덱스 유형을 보여줍니다.
두 번째 항목은 실행 계획입니다.
시간 제한 실행 시간 포함 쿼리를 실행하기 전 상자에 쿼리를 실행한 시간도 표시됩니다. 다음 노드 수 포함 옵션은 노드 수를 보고합니다. 보고서에서는 응용 프로그램 또는 배포의 인덱스를 최적화하는 데 사용할 수 있는 자세한 정보를 제공합니다.
인덱스 관리자의 목적은 인덱스 유지 관리 또는 상태 보기와 같은 인덱스 관리를 용이하게 하는 것입니다.
시작 화면에서 도구 - 작업 - 진단 로 이동한 다음 를 클릭하여 액세스할 수 있습니다 색인 관리자 버튼을 클릭합니다.
다음 URL에서 직접 액세스할 수도 있습니다. https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
UI를 사용하여 화면의 왼쪽 위 모서리에 있는 검색 상자에 필터 기준을 입력하여 테이블의 인덱스를 필터링할 수 있습니다.
이 작업은 시스템 상태 및 구성에 대한 유용한 정보가 포함된 zip 다운로드를 트리거합니다. 아카이브에 인스턴스 구성, 번들 목록, OSGI, Sling 지표 및 통계가 포함되어 있어 파일이 클 수 있습니다. 를 사용하여 큰 상태 파일의 영향을 줄일 수 있습니다 다운로드 상태 ZIP창을 엽니다. 다음 위치에서 창에 액세스할 수 있습니다.AEM > 도구 > 작업 > 진단 > 다운로드 상태 ZIP.
이 창에서 내보낼 항목(로그 파일 및 스레드 덤프)과 현재 날짜를 기준으로 다운로드에 포함된 로그 일 수를 선택할 수 있습니다.
이 작업은 시스템에 있는 스레드에 대한 정보가 포함된 zip의 다운로드를 트리거합니다. 상태, 클래스 로더 및 stacktrace와 같은 각 스레드에 대한 정보가 제공됩니다.
힙의 스냅샷을 다운로드하여 나중에 분석할 수 있습니다. 이 작업은 큰(수백 MB) 파일의 다운로드를 트리거합니다.
자동 유지 관리 작업 페이지는 주기적 실행을 위해 예약된 권장 유지 관리 작업을 보고 추적할 수 있는 위치입니다. 작업은 상태 점검 시스템과 통합됩니다. 인터페이스에서 작업을 수동으로 실행할 수도 있습니다.
작업 대시보드의 유지 관리 페이지로 이동하려면 AEM 시작 화면에서 로 이동합니다. 도구 - 작업 - 대시보드 - 유지 관리또는 이 링크를 직접 따르십시오.
https://serveraddress:port/libs/granite/operations/content/maintenance.html
작업 대시보드에서 다음 작업을 사용할 수 있습니다.
일별 유지 관리 기간의 기본 시기는 오전 2시부터 오전 5시까지입니다. 주별 유지 관리 창에서 실행되도록 구성된 작업은 토요일 오전 1시부터 오전 2시 사이에 실행됩니다.
두 유지 관리 카드의 톱니바퀴 아이콘을 눌러 시간을 구성할 수도 있습니다.
AEM 6.1 이후, 기존 유지 관리 창을 매월 실행하도록 구성할 수도 있습니다.
개정 정리 수행에 대한 자세한 내용은 이 전용 문서 보기.
Lucene 이진 파일 정리 작업을 사용하여 lucene 바이너리를 제거하고 실행 중인 데이터 저장소 크기 요구 사항을 줄일 수 있습니다. Lucene의 이진 이탈은 성공에 대한 이전 종속성 대신 매일 매립됩니다 데이터 저장소 가비지 수집 를 실행합니다.
유지 관리 작업은 Lucene 관련 수정 가비지를 줄이기 위해 개발되었지만 작업을 실행할 때 일반적인 효율성 향상이 있습니다.
다음 위치에서 Lucene 이진 파일 정리 작업에 액세스할 수 있습니다. AEM > 도구 > 작업 > 유지 관리 > 일별 유지 관리 창 > Lucene 바이너리 정리.
데이터 저장소 가비지 수집에 대한 자세한 내용은 전용 설명서 페이지.
워크플로우는 유지 관리 대시보드에서 제거할 수도 있습니다. 워크플로우 삭제 작업을 실행하려면 다음을 수행합니다.
워크플로우 유지 관리에 대한 자세한 내용은 이 페이지.
감사 로그 유지 관리에 대해서는 별도의 설명서 페이지.
버전 삭제 유지 관리 작업을 스케줄링하여 이전 버전을 자동으로 삭제할 수 있습니다. 이 작업을 수행하면 를 수동으로 사용할 필요가 최소화됩니다 버전 삭제 도구. 에 액세스하여 버전 삭제 작업을 예약하고 구성할 수 있습니다 도구 > 공정 > 유지 관리 > 주간 유지 관리 창 및 다음 단계를 수행합니다.
클릭 추가.
선택 버전 삭제 를 클릭합니다.
버전 삭제 작업을 구성하려면 기어 아이콘을 클릭합니다.
AEM 6.4 사용를 눌러 다음과 같이 버전 삭제 유지 관리 작업을 중지할 수 있습니다.
유지 관리 작업을 중지하면 이미 진행 중인 작업 추적을 손실하지 않고 실행을 일시 중지하는 것입니다.
저장소 크기를 최적화하려면 버전 삭제 작업을 자주 실행해야 합니다. 제한된 트래픽 양이 있는 경우 업무 시간 외에 작업을 예약해야 합니다.
사용자 지정 유지 관리 작업은 OSGi 서비스로 구현할 수 있습니다. 유지 관리 작업 인프라는 Apache Sling의 작업 처리를 기반으로 하므로 유지 관리 작업은 Java™ 인터페이스를 구현해야 합니다 [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
. 또한 다음과 같이 몇 가지 서비스 등록 속성을 유지 관리 작업으로 인식해야 합니다.
서비스 속성 이름 |
설명 | 예 |
유형 |
granite.maintenance.isStoppable | 사용자가 작업을 중지할 수 있는지 여부를 정의하는 부울 속성입니다. 작업이 정지 상태를 선언하면 실행 중에 정지 여부를 확인한 다음 그에 따라 조치를 취해야 합니다. 기본값은 false입니다. | true | 선택 사항 |
granite.maintenance.mandatory | 작업이 필수이고 주기적으로 실행해야 하는지 여부를 정의하는 부울 속성입니다. 작업이 필수이지만 현재 활성 스케줄 창이 아닌 경우 상태 점검(Health Check)은 이 오류를 보고합니다. 기본값은 false입니다. | true | 선택 사항 |
granite.maintenance.name | 작업에 대한 고유한 이름 - 이 이름은 작업을 참조하는 데 사용되며 단순한 이름입니다. | MyMaintenanceTask | 필수 |
granite.maintenance.title | 이 작업에 대해 표시되는 제목 | 내 특별 유지 관리 작업 | 필수 |
job.topics | 유지 관리 작업의 고유한 주제입니다. Apache Sling 작업 처리에서는 유지 관리 작업을 실행하기 위해 이 주제와 함께 작업을 시작하고, 이 주제에 대해 작업이 등록되면 실행됩니다. 항목은 com/adobe/granite/maintenance/job/ |
com/adobe/granite/maintenance/job/MyMaintenanceTask | 필수 |
위의 서비스 속성 외에 process()
의 방법 JobConsumer
인터페이스는 유지 관리 작업에 대해 실행해야 하는 코드를 추가하여 구현해야 합니다. 제공된 JobExecutionContext
를 사용하여 상태 정보를 출력하고, 사용자가 작업을 중지했는지 확인하고 결과를 만들 수 있습니다(성공 또는 실패).
모든 설치에서 유지 관리 작업을 실행해서는 안 되는 상황(예: 게시 인스턴스에서만 실행)의 경우, 추가 @Component(policy=ConfigurationPolicy.REQUIRE)
. 그런 다음 저장소에 따라 해당 구성을 실행 모드로 표시할 수 있습니다. 자세한 내용은 OSGi 구성.
다음은 지난 24시간 동안 수정된 구성 가능한 임시 디렉터리에서 파일을 삭제하는 사용자 지정 유지 관리 작업의 예입니다.
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
|
experiencemanager-java-maintenancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
서비스가 배포되면 Operations Dashboard UI에 표시됩니다. 사용 가능한 유지 관리 일정 중 하나에 추가할 수 있습니다.
이 작업은 /apps/granite/operations/config/maintenance/에 해당 리소스를 추가합니다schedule
/taskname
. 작업이 실행 모드에 종속되어 있는 경우 이 유지 관리 작업에 대해 활성화되어야 하는 실행 모드 값이 있는 해당 노드에 granite.operations.conditions.runmode 속성을 설정해야 합니다.
다음 시스템 개요 대시보드 AEM 인스턴스의 구성, 하드웨어 및 상태에 대한 높은 수준의 개요를 표시합니다. 시스템 상태 상태는 투명하며 모든 정보는 하나의 대시보드에서 집계됩니다.
다음을 수행할 수도 있습니다 이 비디오 보기 시스템 개요 대시보드를 소개합니다.
시스템 개요 대시보드에 액세스하려면 다음 위치로 이동합니다. 도구 > 작업 > 시스템 개요.
아래 표에서는 시스템 개요 대시보드에 표시되는 모든 정보를 설명합니다. 표시할 관련 정보가 없는 경우(예: 백업이 진행 중이 아닌 경우 중요한 상태 검사가 없습니다) 각 섹션에 "항목 없음" 메시지가 표시됩니다.
또한 JSON
대시보드 정보를 요약하는 파일로서 다운로드 대시보드 오른쪽 상단 모서리에 있는 단추. 다음 JSON
endpoint /libs/granite/operations/content/systemoverview/export.json
그리고 curl
외부 모니터링을 위한 스크립트
섹션 | 표시되는 정보는 무엇입니까 | 중요한 것은 언제입니까 | 링크 대상 |
상태 검사 |
|
시각적으로 표시되어 있습니다.
|
|
유지 관리 작업 |
|
시각적으로 표시되어 있습니다.
|
|
시스템 |
|
N/A | N/A |
인스턴스 |
|
N/A | N/A |
저장소 |
|
N/A | N/A |
분산 에이전트 |
|
시각적으로 표시되어 있습니다.
|
배포 페이지 |
복제 에이전트 |
|
시각적으로 표시되어 있습니다.
|
복제 페이지 |
워크플로 |
위에 표시된 각 상태에 대해 400밀리초로 제한됩니다. 400밀리초에서 해당 지점까지 가져온 항목 수가 표시됩니다. |
해석되지 않음:
|
워크플로우 실패 페이지 |
Sling 작업 | Sling 작업 수 - 주어진 상태의 작업 수(있는 경우):
|
해석되지 않음:
|
N/A |
예상 노드 수 | 예상 개수:
노드 수 합계는 nodeCounterMBean에서 가져온 반면 나머지 통계는 IndexInfoService에서 가져옵니다. |
N/A | N/A |
백업 | "온라인 백업 진행 중"이 표시되는 경우 | N/A | N/A |
색인 생성 | 디스플레이:
인덱싱 또는 쿼리 스레드가 스레드 덤프에 있는 경우 |
N/A | N/A |