Looker 애플리케이션 모니터링이 꼭 필요한 것처럼 보이지 않을 수 있지만 고객 호스팅 인스턴스에서 설정하는 것은 매우 중요합니다. 드물지만 서버에서 문제가 발생하는 경우 이슈 발생 시점부터 적절한 모니터링 정보를 제공하지 않으면 Looker에서 문제를 해결하는 것이 훨씬 더 어렵거나 불가능한 경우가 많습니다.
애플리케이션 모니터링
URL
Looker 인스턴스가 실행 중인지 확인하는 간단한 두 가지 방법이 있습니다.
다음과 같이
/alive
를 Looker 인스턴스 URL에 추가합니다.https://instance_name.looker.com/alive
인스턴스가 웹 요청에 응답할 수 있으면 200 OK HTTP 상태 코드가 표시됩니다.
다음과 같이
/availability
를 Looker 인스턴스 URL에 추가합니다.https://instance_name.looker.com/availability
이 URL은 여러 기본 하위 시스템을 보다 철저하게 검사하며 정상일 경우 200 OK HTTP 상태 코드로 응답합니다.
JMX
JMX를 통해 Looker를 실행하는 Java 가상 머신을 모니터링할 수 있습니다.
Zabbix 및 Nagios와 같은 많은 모니터링 애플리케이션에서 JMX를 지원합니다. 자세한 내용은 모니터링 애플리케이션 문서를 참조하세요.
Looker 시작 스크립트 수정
JMX 모니터링을 사용 설정하려면 Looker 시작 스크립트를 수정해야 합니다. 기본적으로 이름은 다음과 같습니다.
/home/looker/looker/looker
Java 시작 매개변수를 찾습니다.
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
Looker 6.18부터 Looker JAR 파일은 Looker 코어 JAR 파일과 Looker 종속 항목 JAR 파일이라는 두 가지 개별 JAR 파일로 분할되었습니다. 시작 시 코어 JAR 파일은 자동으로 종속 항목 JAR 파일을 시작합니다. 핵심 JAR 파일에서 종속 항목 JAR 파일을 찾고 시작할 수 있도록 두 JAR 파일 모두 같은 디렉터리에 있어야 합니다.
기본적으로 --no-daemonise
시작 옵션은 설정되지 않습니다. --no-daemonise
옵션을 설정하지 않았으면 -Xms$JAVAMEM
으로 시작하는 줄 뒤에 섹션을 추가합니다.
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.port=9910 \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.ssl=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.local.only=false \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.authenticate=true \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.akuma.jvmarg.com.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
--no-daemonise
시작 옵션을 설정한 경우 -Xms$JAVAMEM
으로 시작하는 줄 뒤에 섹션을 추가합니다.
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9910 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.local.only=false \
-Dcom.sun.management.jmxremote.authenticate=true \
-Dcom.sun.management.jmxremote.access.file=${HOME}/.lookerjmx/jmxremote.access \
-Dcom.sun.management.jmxremote.password.file=${HOME}/.lookerjmx/jmxremote.password \
.lookerjmx
디렉터리 만들기
다음으로, Looker 사용자의 홈 디렉터리에 .lookerjmx
디렉터리를 만들고 권한을 설정합니다.
sudo su - looker
mkdir ~/.lookerjmx
chmod 700 ~/.lookerjmx
cd ~/.lookerjmx
JMX 파일 만들기
즐겨찾는 텍스트 편집기를 사용하여 jmxremote.access
라는 이름의 새 디렉터리에 다음 내용으로 파일을 만듭니다(사용자 환경에 맞게 조정할 수 있음).
monitorRole readonly
controlRole readwrite \
create javax.management.monitor.*,javax.management.timer.* \
unregister
다음으로 자체 보안 비밀번호를 사용하여 다음 내용으로 동일한 디렉터리에 jmxremote.password
라는 파일을 만듭니다.
monitorRole some_password_here
controlRole some_password_here
권한 설정
Looker 사용자를 제외한 모든 사용자가 비밀번호 파일을 읽을 수 있도록 파일 권한을 부여하면 Java(및 Looker)가 시작되지 않습니다.
chmod 400 jmxremote.*
Looker 다시 시작
JMX를 사용 설정하려면 Looker를 다시 시작해야 합니다. *루트가 아닌 Looker 사용자로* 실행해야 합니다.
cd ~/looker
./looker restart
이제 Looker 인스턴스는 개발자가 제공한 비밀번호를 통해 포트 9910에서 원격 JMX 모니터링용으로 구성되었습니다. 모니터링 서버가 이 포트에 대한 네트워크 액세스 권한을 부여받을 수 있도록 방화벽 설정이나 네트워크 ACL을 수정해야 할 수도 있습니다.
호스트 모니터링
Looker 애플리케이션을 실행하는 모든 호스트에 대해 최소한 다음 성능 측정항목을 수집, 그래프화, 알림을 보내는 것이 좋습니다.
- CPU 사용률: 부하 및 사용된 CPU 비율
- 메모리 사용률: 사용된 총 스왑과 사용된 스왑
- 디스크 사용량
알림 기준
적절한 알림 기준을 설정하려면 먼저 기준을 설정합니다. 정상적인 로드로 실행되는 Looker 인스턴스로 성능 데이터를 수집합니다. 성능 그래프를 살펴보고 피크를 관찰합니다. 기준을 설정하는 데 소요되는 기간은 비즈니스 및 Looker 사용 패턴에 따라 다릅니다. 일부 기업에서는 매주 영업시간 중에 안정적이고 반복 가능한 패턴으로 Looker를 사용할 수 있습니다. 특정 시점(예: 월말에)에 Looker를 더 많이 사용하는 경우도 있습니다.
일반적으로 조치를 취할 수 있는 이벤트에 대해서만 알림을 전송해야 합니다. 조치가 필요하지 않은 경우 알림을 보내면 중요한 알림의 중요성이 가려집니다.
다음 기준점을 알림 시작점으로 사용할 수 있습니다. 다음 값이 15분을 초과되면 수동으로 개입해야 할 수 있습니다.
측정항목 | 경고 | 심각 | 설명 |
---|---|---|---|
CPU 부하 | 2 | 4 | 단일 코어 시스템의 경우 부하는 일반적으로 1 이하여야 합니다. 지속적인 높은 부하로 인해 성능이 저하됩니다. |
CPU 사용량 % | 80 | 90 | CPU 사용량이 많으면 성능이 저하됩니다. |
메모리 사용량 % | 60 | 70 | 메모리 사용량이 많으면 Java에 너무 많은 메모리가 할당되었음을 나타낼 수 있습니다. |
디스크 사용량 % | 80 | 90 | 디스크가 가득 차지 않았는지 확인합니다. |
기타 참고사항:
- 코어가 2개 이상 있는 시스템은 성능을 저하시키지 않고 높은 CPU 부하를 처리할 수 있습니다. 경험적으로 지속 부하는 프로세서 코어의 수보다 많지 않아야 합니다.
- 시스템 환경 성능이 저하되기 전에 사용 중인 총 CPU 시간 비율은 시스템의 CPU 코어 수에 따라 확장됩니다. 즉, CPU가 80% 사용되면 단일 코어 시스템의 성능이 저하될 수 있지만 16코어 호스트는 사용률이 95%에서도 사용 가능합니다.
- 호스트 하드웨어를 업데이트하거나 더 큰 인스턴스로 업그레이드하면 지속적으로 높은 CPU 사용률을 해결할 수 있습니다. 일부 경우에는 많은 예약된 Look 또는 긴 쿼리 파생 테이블 수를 줄이거나 더 효율적으로 사용하여 성능을 향상시킬 수 있습니다.
다음 단계
모니터링을 설정한 후에는 Looker 백업 설정하기