현재 Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 방문하세요.

Looker 모니터링

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

Looker를 실행하는 자바 가상 머신은 JMX를 통해 모니터링될 수 있습니다.

Zabbix 및 Nagios와 같은 많은 모니터링 애플리케이션이 JMX를 지원합니다. 자세한 내용은 모니터링 애플리케이션의 문서를 참조하세요.

Looker 시작 스크립트 수정

JMX 모니터링을 사용 설정하려면 Looker 시작 스크립트를 수정해야 합니다. 기본적으로 이름은 다음과 같습니다.

/home/looker/looker/looker

자바 시작 매개변수를 찾습니다.

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

이제 입력한 비밀번호를 사용하여 포트 9910에서 원격 JMX 모니터링에 Looker 인스턴스가 구성됩니다. 모니터링 서버가 이 포트에서 네트워크 액세스를 허용하도록 방화벽 설정 또는 네트워크 ACL을 수정해야 할 수 있습니다.

호스트 모니터링

Looker 애플리케이션을 실행하는 모든 호스트에 대해 최소한 다음 성능 측정항목을 수집, 그래프화, 알림을 보내는 것이 좋습니다.

CPU 사용률: 사용된 부하 및 CPU 사용률
메모리 사용률: 사용된 총 스왑 및 사용된 스왑
디스크 사용량

알림 기준

적절한 알림 기준을 설정하려면 먼저 기준을 설정하세요. 일반적인 로드에서 실행되는 Looker 인스턴스로 성능 데이터를 수집합니다. 성능 그래프를 살펴보고 최고 사용률을 관찰합니다. 기준을 설정하는 데 걸리는 시간은 비즈니스 및 Looker 사용 패턴에 따라 다릅니다. 일부 회사는 매주 영업시간에 안정적이고 반복 가능한 패턴으로 Looker를 사용할 수 있습니다. 특정 시점(예: 월말에)에 Looker를 더 많이 사용하는 경우도 있습니다.

일반적으로 알림은 실행 가능한 이벤트에 대해서만 전송되어야 합니다. 수행해야 할 작업이 없을 때 알림을 보내면 중요한 알림의 중요성이 숨겨집니다.

다음 기준점을 알림 시작점으로 사용할 수 있습니다. 다음 값을 15분 이상 초과하면 직접 개입해야 할 수 있습니다.

측정항목	경고	심각	설명
CPU 부하	2	4	일반적으로 단일 코어 시스템의 부하는 1 이하여야 합니다. 부하가 지속되면 성능이 저하됩니다.
CPU 사용량 %	80	90	CPU 사용량이 높으면 성능이 저하됩니다.
메모리 사용량 %	60	70	메모리 사용량이 높으면 자바에 메모리가 너무 많이 할당될 수 있습니다.
디스크 사용량 %	80	90	디스크가 가득 찼는지 확인합니다.

기타 참고사항:

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

다음 단계

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