Looker 모니터링

Looker 애플리케이션 모니터링이 꼭 필요한 것처럼 보이지 않을 수 있지만 고객 호스팅 인스턴스에서 설정하는 것은 매우 중요합니다. 드물지만 서버에서 문제가 발생하는 경우 이슈 발생 시점부터 적절한 모니터링 정보를 제공하지 않으면 Looker에서 문제를 해결하는 것이 훨씬 더 어렵거나 불가능한 경우가 많습니다.

애플리케이션 모니터링

URL

Looker 인스턴스가 실행 중인지 확인하는 간단한 두 가지 방법이 있습니다.

1. 다음과 같이 /alive를 Looker 인스턴스 URL에 추가합니다.

   https://instance_name.looker.com/alive

   인스턴스가 웹 요청에 응답할 수 있으면 200 OK HTTP 상태 코드가 표시됩니다.

2. 다음과 같이 /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분을 초과되면 수동으로 개입해야 할 수 있습니다.

기타 참고사항:

• 코어가 2개 이상 있는 시스템은 성능을 저하시키지 않고 높은 CPU 부하를 처리할 수 있습니다. 경험적으로 지속 부하는 프로세서 코어의 수보다 많지 않아야 합니다.
• 시스템 환경 성능이 저하되기 전에 사용 중인 총 CPU 시간 비율은 시스템의 CPU 코어 수에 따라 확장됩니다. 즉, CPU가 80% 사용되면 단일 코어 시스템의 성능이 저하될 수 있지만 16코어 호스트는 사용률이 95%에서도 사용 가능합니다.
• 호스트 하드웨어를 업데이트하거나 더 큰 인스턴스로 업그레이드하면 지속적으로 높은 CPU 사용률을 해결할 수 있습니다. 일부 경우에는 많은 예약된 Look 또는 긴 쿼리 파생 테이블 수를 줄이거나 더 효율적으로 사용하여 성능을 향상시킬 수 있습니다.

다음 단계

모니터링을 설정한 후에는 Looker 백업 설정하기