모니터링 방법

Private Cloud용 Edge v4.18.05

이 문서에서는 온프레미스에서 지원하는 구성요소의 모니터링 기법을 설명합니다. Apigee Edge 배포입니다

개요

Edge는 서비스에 대한 세부정보를 가져오고 있습니다. 다음 표에는 적격한 각 검사에서 수행할 수 있는 검사 유형이 나와 있습니다. 서비스:

서비스 JMX:*
메모리 사용량		 관리 API:
서비스 확인		 Mgmt API:
사용자/조직/ 배포 상태		 관리 API:
axstatus		 데이터베이스 확인 apigee-service 상태
관리 서버
메시지 프로세서
Postgres
Qpid
라우터
추가 정보 추가 정보 추가 정보 추가 정보 추가 정보 추가 정보
* JMX를 사용하려면 먼저 JMX를 사용 설정해야 합니다. 자세한 내용은 JMX 사용 설정을 참조하세요.

JMX 및 Management API 모니터링 포트

각 구성요소는 서로 다른 포트에서 JMX 및 Management API 모니터링 호출을 지원합니다. 이 다음 표에는 각 서버 유형에 대한 JMX 및 Management API 포트가 나와 있습니다.

구성요소 JMX 포트 Management API 포트
관리 서버 1099 8080
라우터 1100 8081
메시지 프로세서 1101 8082
Qpid 1102 8083
Postgres 1103 8084

JMX 사용

관리 서버, 메시지 프로세서, Qpid 및 Postgres의 모니터링 프로세스가 모두 JMX를 사용합니다 하지만 JMX는 기본적으로 Cassandra에만 사용 설정되고 모든 다른 Edge 구성요소에 적용됩니다. 따라서 각 구성 요소에 대해 개별적으로 JMX를 사용 설정해야 모니터링할 수 있습니다

JMX 인증은 기본적으로 사용 설정되어 있지 않습니다. 모든 서비스 계정에 대해 JMX 인증을 다른 구성요소를 지원합니다

JMX 사용 설정

JMX는 Cassandra에만 기본적으로 사용 설정되고 다른 모든 Edge에는 기본적으로 사용 중지되어 있습니다. 구성할 수 있습니다. 이 섹션에서는 다른 Edge 구성요소에 JMX를 사용 설정하는 방법을 설명합니다.

JMX를 사용 설정하려면 다음 안내를 따르세요.

  1. 구성요소의 구성 파일을 수정합니다. 이 파일은 다음 위치에 있습니다. opt/apigee/edge-component_name/bin/start 프로덕션 단계 이러한 구성 파일은 다른 머신에 있을 것입니다

    각 서버의 다음 파일 위치 중에서 선택하세요.

    • 관리 서버: /opt/apigee/edge-management-server/bin/start
    • 메시지 프로세서: /opt/apigee/edge-message-processor/bin/start
    • Postgres: /opt/apigee/edge-postgres-server/bin/start
    • Qpid: /opt/apigee/edge-qpid-server/bin/start
    • 라우터: /opt/apigee/edge-router/bin/start

    예를 들어, 서버에 있는 관리 서버 구성 파일은 /opt/apigee/edge-management-server/bin/start

  2. 다음 com.sun.management.jmxremote 옵션을 exec에 추가합니다. 줄을 시작합니다. 
    -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=port_number \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false

    여기서 port_number는 서비스의 JMX 포트입니다. 서비스의 JMX를 가져오려면 다음 단계를 따르세요. JMX 및 Management API 모니터링 포트를 참고하세요.

    예를 들어 관리 서버에서 JMX를 사용하도록 설정하려면 다음을 관리 서버 구성 파일:

    exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts \
  -Djava.security.auth.login.config=$conf_path/jaas.config \
  -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path \
  -Ddata.dir=$data_dir \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=1099 \
  -Dcom.sun.management.jmxremote.local.only=false \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  $* $debug_options com.apigee.kernel.MicroKernel

    이 예시에서는 관리 서버에 대해 포트 1099를 지정합니다. 앞서 언급했듯이 각 서비스에 자체 포트 번호가 있습니다.

    구성 파일에서 수정된 행은 다음과 같습니다.

    exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts -Djava.security.auth.login.config=$conf_path/jaas.config -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path -Ddata.dir=$data_dir -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false $* $debug_options com.apigee.kernel.MicroKernel
  3. 구성 파일을 저장합니다.
  4. restart 명령어로 구성요소를 다시 시작합니다.

    예를 들어 관리 서버를 다시 시작하려면 다음 명령어를 실행합니다.

    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

JMX 인증은 기본적으로 활성화되어 있지 않습니다. 모든 서비스 계정에 대해 JMX 인증을 모든 구성요소를 사용할 수 있습니다. JMX 인증 사용 설정에 설명되어 있습니다.

JMX 인증 사용 설정

JMX 인증은 기본적으로 사용 설정되어 있지 않습니다. 모든 서비스 계정에 대해 JMX 인증을 다른 구성요소를 지원합니다

JMX 인증을 사용 설정하려면 모든 사용자 인증 정보에서 다음 change_jmx_auth 작업을 노드:

/opt/apigee/apigee-service/bin/apigee-service component change_jmx_auth [options|-f config_file]

각 항목의 의미는 다음과 같습니다.

  • component는 다음 중 하나입니다. <ph type="x-smartling-placeholder">
      </ph>
    • edge-management-server
    • edge-message-processor
    • edge-postgres-server
    • edge-qpid-server
    • edge-router
  • options는 다음을 지정합니다. <ph type="x-smartling-placeholder">
      </ph>
    • -u username
    • -p password
    • -e [y|n] (사용 설정 또는 사용 중지)
  • config_file는 정의하는 구성 파일의 위치를 지정합니다. 다음과 같습니다. <ph type="x-smartling-placeholder">
      </ph>
    • JMX_USERNAME=username
    • JMX_ENABLED=y|n
    • JMX_PASSWORD=password (설정되지 않거나 -p의 경우 메시지가 표시됨)

명령줄 옵션 또는 구성 파일을 사용하여 사용자 이름을 정의할 수 있습니다. 활성화/비활성화합니다. 옵션 세트와 구성을 모두 지정하지 않은 경우 파일에서 참조됩니다.

다음 예는 다음 명령어를 사용하여 관리 서버에 JMX 인증을 활성화합니다. 선 옵션:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -u foo -p bar -e y

다음 예에서는 명령줄 옵션이 아닌 구성 파일을 사용합니다.

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -f /tmp/my-config-file

여러 노드에서 Edge를 실행하는 경우 모든 노드에서 명령어를 실행하여 동일하게 비밀번호를 입력합니다.

명령줄에서 JMX 인증을 사용하지 않으려면 '-e n'을 사용합니다. 옵션을 선택합니다. 예시:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server
    change_jmx_auth -e n

JConsole로 모니터링

JConsole (JMX 준수 툴)을 사용하여 상태 점검을 관리 및 모니터링하고 통계를 처리하세요. JConsole을 사용하면 서버가 노출하는 JMX 통계를 소비하고 사용할 수 있습니다. 자세한 내용은 JConsole 사용

JConsole은 다음 서비스 URL을 사용하여 JMX:

service:jmx:rmi:///jndi/rmi://IP_address:port_number/jmxrmi

각 항목의 의미는 다음과 같습니다.

  • IP_address는 모니터링할 서버의 IP 주소입니다.
  • port_number는 원하는 서버의 JMX 포트 번호입니다. 있습니다.

예를 들어, Management Server를 모니터링하려면 다음과 같은 명령을 실행합니다( 216.3.128.12인 경우).

service:jmx:rmi:///jndi/rmi://216.3.128.12:1099/jmxrmi

이 예에서는 Management Server JMX 포트인 포트 1099를 지정합니다. 기타 JMX 및 Management API 모니터링 포트를 참고하세요.

다음 표는 일반적인 JMX 통계를 보여줍니다.

JMX MBean JMX 속성

메모리

HeapMemoryUsage

NonHeapMemoryUsage

사용

Management API로 모니터링

Edge에는 서버에서 서비스 검사를 수행하는 데 사용할 수 있는 여러 API가 포함되어 있으며 사용자, 조직, 배포를 확인할 수 있습니다 이 섹션에서는 이러한 API를 설명합니다.

서비스 확인 실행

Management API는 문제를 모니터링하고 진단하기 위한 여러 엔드포인트를 제공합니다 이러한 엔드포인트에는 다음이 포함됩니다.

엔드포인트 설명
/servers/self/up

서비스가 실행 중인지 확인합니다. 이 API 호출은 인증할 수 있습니다

서비스가 실행 중인 경우 이 엔드포인트는 다음 응답을 반환합니다.

<ServerField>
  <Up>true</Up>
</ServerField>

서비스가 실행 중이 아니면 다음과 비슷한 응답을 받게 됩니다. (서비스 종류와 확인 방법에 따라 다름)

curl: Failed connect to localhost:port_number; Connection refused
/servers/self

다음을 포함한 서비스 정보를 반환합니다.

  • 구성 속성
  • 시작 시간 및 가동 시간
  • 빌드, RPM, UUID 정보
  • 내부 및 외부 호스트 이름과 IP 주소
  • 리전 및 포드
  • 서비스가 실행 중인지 여부를 나타내는 <isUp> 속성

이 API 호출을 사용하려면 Apigee 관리자 사용자 인증 정보로 인증해야 합니다.

이러한 엔드포인트를 사용하려면 다음을 사용하는 명령어로 curl와 같은 유틸리티를 호출합니다. 다음 구문을 사용합니다.

curl http://host:port_number/v1/servers/self/up
  -H "Accept: [application/json|application/xml]"
curl http://host:port_number/v1/servers/self -u username:password
  -H "Accept: [application/json|application/xml]"

각 항목의 의미는 다음과 같습니다.

  • host는 확인하려는 서버의 IP 주소입니다. 로그인한 경우 "localhost"를 사용할 수 있습니다. 그렇지 않으면 서버의 IP 주소도 지정합니다. 을 사용자 이름과 비밀번호로 설정합니다.
  • port_number는 확인하려는 서버의 Management API 포트입니다. 이것은 각 구성 요소 유형마다 다른 포트를 사용합니다. 예를 들어 관리 서버의 Management API 포트가 8080입니다. 사용할 Management API 포트 번호 목록은 다음을 참고하세요. JMX 및 Management API 모니터링 포트

응답 형식을 변경하려면 Accept 헤더를 다음과 같이 지정하면 됩니다. &quot;application/json&quot; 또는 'application/xml'입니다.

다음 예는 localhost (포트 8081)에서 라우터의 상태를 가져옵니다.

curl http://localhost:8081/v1/servers/self/up -H "Accept: application/xml"

다음 예는 216.3.128.12 (포트)에 있는 메시지 프로세서에 대한 정보를 가져옵니다. 8082).

curl http://216.3.128.12:8082/v1/servers/self -u sysAdminEmail:password
  -H "Accept: application/xml"

사용자, 조직, 배포 상태 모니터링

Management API를 사용하여 사용자, 조직, 배포 상태를 모니터링할 수 있습니다. 관리 서버 및 메시지 프로세서에 대한 프록시의 IP를 실제로 보냅니다.

curl http://host:port_number/v1/users -u sysAdminEmail:password
curl http://host:port_number/v1/organizations -u sysAdminEmail:password
curl http://host:port_number/v1/organizations/orgname/deployments -u sysAdminEmail:password

여기서 port_number는 관리 서버의 경우 8080, 메시지의 경우 8082입니다. 프로세서.

이 호출을 수행하려면 시스템 관리 사용자 이름 및 비밀번호

서버는 '배포됨' 상태를 확인할 수 있습니다. 이 방법이 실패하면 다음을 수행합니다.

  1. 서버 로그에서 오류가 있는지 확인하세요. 로그는 다음 위치에 있습니다. <ph type="x-smartling-placeholder">
      </ph>
    • 관리 서버: opt/apigee/var/log/edge-management-server
    • 메시지 프로세서: opt/apigee/var/log/edge-message-processor
  2. 서버를 호출하여 서버가 제대로 작동하는지 확인합니다.
  3. ELB에서 서버를 삭제한 후 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service service_name restart

    여기서 service_name은 다음과 같습니다.

    • edge-management-server
    • edge-message-processor

apigee-service 명령어로 상태 확인

다음과 같은 경우 apigee-service 명령어를 사용하여 Edge 서비스 문제를 해결할 수 있습니다. 사용자 인증 정보를 제공합니다

apigee-service로 서비스 상태를 확인하려면 다음 안내를 따르세요.

  1. 서버에 로그인하고 다음 명령어를 실행합니다. 
    /opt/apigee/apigee-service/bin/apigee-service service_name status

    여기서 service_name은 다음 중 하나입니다.

    • 관리 서버: edge-management-server
    • 메시지 프로세서: edge-message-processor
    • Postgres: edge-postgres-server
    • Qpid: edge-qpid-server
    • 라우터: edge-router

    예를 들면 다음과 같습니다.

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status
  2. 서비스가 실행 중이 아니면 서비스를 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service service_name start
  3. 서비스를 다시 시작한 후에는 이전에 사용한 apigee-service status 명령어 또는 Management API 사용 Management API로 모니터링에 설명되어 있습니다.

    예를 들면 다음과 같습니다.

    curl -v http://localhost:port_number/v1/servers/self/up

    여기서 port_number는 서비스의 Management API 포트입니다.

    이 예에서는 서버에 로그인하여 'localhost'를 사용할 수 있다고 가정합니다. 를 있습니다. Management API를 사용하여 원격으로 상태를 확인하려면 IP 주소를 지정해야 합니다. API에 시스템 관리자의 사용자 이름과 비밀번호를 포함합니다. 있습니다.

Postgres 모니터링

Postgres는 상태를 확인하는 데 사용할 수 있는 여러 유틸리티를 지원합니다. 이러한 유틸리티는 다음 섹션에서 설명합니다.

Postgres에서 조직 및 환경 확인하기

Postgres 서버에 온보딩된 조직 및 환경 이름을 확인할 수 있습니다. 다음 curl 명령어를 실행합니다.

curl -v http://postgres_IP:8084/v1/servers/self/organizations

시스템에 조직 및 환경 이름이 표시됩니다.

애널리틱스 상태 확인

다음을 실행하여 Postgres 및 Qpid 분석 서버의 상태를 확인할 수 있습니다. curl 명령어:

curl -u userEmail:password http://host:port_number/v1/organizations/orgname/environments/envname/provisioning/axstatus

다음 예와 같이 시스템에 모든 애널리틱스 서버의 성공 상태가 표시됩니다. 표시:

{
  "environments" : [ {
    "components" : [ {
      "message" : "success at Thu Feb 28 10:27:38 CET 2013",
      "name" : "pg",
      "status" : "SUCCESS",
      "uuid" : "[c678d16c-7990-4a5a-ae19-a99f925fcb93]"
     }, {
      "message" : "success at Thu Feb 28 10:29:03 CET 2013",
      "name" : "qs",
      "status" : "SUCCESS",
      "uuid" : "[ee9f0db7-a9d3-4d21-96c5-1a15b0bf0adf]"
     } ],
    "message" : "",
    "name" : "prod"
   } ],
  "organization" : "acme",
  "status" : "SUCCESS"
}

PostgreSQL 데이터베이스

이 섹션에서는 특히 Postgres를 모니터링하는 데 사용할 수 있는 기법을 설명합니다. 데이터베이스입니다.

check_postgres.pl 스크립트 사용

PostgreSQL 데이터베이스를 모니터링하려면 표준 모니터링 스크립트인 check_postgres.pl 자세한 내용은 http://bucardo.org/wiki/Check_postgres.

스크립트를 실행하기 전에:

  1. 각 Postgres 노드에 check_postgres.pl 스크립트를 설치해야 합니다.
  2. perl-Time-HiRes.x86_64라는 Perl 모듈을 설치했는지 확인합니다. 고해상도 알람, 절전 모드, gettimeofday 및 인터벌 타이머를 구현합니다. 예를 들어 다음 명령어를 사용하여 설치할 수 있습니다.
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: CentOS v7에서 check_postgres.pl을 사용하기 전에 perl-Data-Dumper.x86_64RPM

check_postgres.pl 출력

check_postgres.pl를 사용하는 API 호출의 기본 출력은 Nagios입니다. 있습니다. 스크립트를 설치한 후 다음 사항을 확인하세요.

  1. 데이터베이스 크기를 확인합니다. 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -include=apigee -action database_size --warning='800 GB' --critical='900 GB'
  2. 데이터베이스에 수신되는 연결 수를 확인하고 허용되는 최대 연결 수와 비교 연결: 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends
  3. 데이터베이스가 실행 중이고 사용 가능한지 확인합니다. 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection
  4. 디스크 공간을 확인합니다. 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'
  5. Postgres 노드에 온보딩된 조직 및 환경 수를 확인합니다. 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action=custom_query --query="select count(*) as result from pg_tables where schemaname='analytics' and tablename like '%fact'" --warning='80' --critical='90' --valtype=integer

데이터베이스 검사 실행

PostgreSQL 데이터베이스에 적절한 테이블이 만들어졌는지 확인할 수 있습니다. PostgreSQL에 로그인 데이터베이스를 사용할 수 있습니다

psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee

그런 후 다음을 실행합니다.

\d analytics."org.env.fact"

postgres 프로세스의 상태 확인

다음 curl를 호출하여 Postgres 머신에서 API 검사를 수행할 수 있습니다. 명령어:

curl -v http://postgres_IP:8084/v1/servers/self/health

이 명령어는 postgres 프로세스가 활성 상태일 때 ACTIVE 상태를 반환합니다. 만약 Postgres 프로세스가 실행 중이 아니면 INACTIVE 상태를 반환합니다.

Postgres 리소스

Postgres 서비스 모니터링에 대한 자세한 내용은 다음을 참조하세요.

Apache Cassandra

JConsole 사용: 작업 통계 모니터링

JConsole과 다음 서비스 URL을 사용하여 JMX:

service:jmx:rmi:///jndi/rmi://IP_address:7199/jmxrmi

여기서 IP_address는 Cassandra 서버의 IP입니다.

JMX는 Cassandra에 기본적으로 사용 설정되며 Cassandra에 대한 원격 JMX 액세스에는 비밀번호

Cassandra JMX 통계

JMX MBean JMX 속성

ColumnFamilies/apprepo/environments

ColumnFamilies/apprepo/organizations

ColumnFamilies/apprepo/apiproxy_revisions

ColumnFamilies/apprepo/apiproxies

ColumnFamilies/audit/audits

ColumnFamilies/audit/audits_ref

PendingTasks

MemtableColumnsCount

MemtableDataSize

ReadCount

RecentReadLatencyMicros

TotalReadLatencyMicros

WriteCount

RecentWriteLatencyMicros

TotalWriteLatencyMicros

TotalDiskSpaceUsed

LiveDiskSpaceUsed

LiveSSTableCount

BloomFilterFalsePositives

RecentBloomFilterFalseRatio

BloomFilterFalseRatio

nodetool을 사용하여 클러스터 노드 관리

nodetool 유틸리티는 Cassandra용 명령줄 인터페이스이며 kube-APIserver로 전송합니다 이 유틸리티는 /opt/apigee/apigee-cassandra/bin에서 찾을 수 있습니다.

모든 Cassandra 클러스터 노드에서 다음과 같은 호출을 수행할 수 있습니다.

  1. 일반 링 정보 (단일 Cassandra 노드도 가능): "위로" 'Normal'을 kube-APIserver입니다 
    nodetool -h localhost ring

    위 명령어를 실행하면 다음과 같이 출력됩니다. 

    Datacenter: dc-1
==========
Address            Rack     Status State   Load    Owns    Token
192.168.124.201    ra1      Up     Normal  1.67 MB 33,33%  0
192.168.124.202    ra1      Up     Normal  1.68 MB 33,33%  5671...5242
192.168.124.203    ra1      Up     Normal  1.67 MB 33,33%  1134...0484
  2. 노드에 대한 일반 정보 (노드당 호출) 
    nodetool -h localhost info

    위 명령어의 출력은 다음과 같습니다.

    ID                     : e2e42793-4242-4e82-bcf0-oicu812
Gossip active          : true
Thrift active          : true
Native Transport active: true
Load                   : 273.71 KB
Generation No          : 1234567890
Uptime (seconds)       : 687194
Heap Memory (MB)       : 314.62 / 3680.00
Off Heap Memory (MB)   : 0.14
Data Center            : dc-1
Rack                   : ra-1
Exceptions             : 0
Key Cache              : entries 150, size 13.52 KB, capacity 100 MB, 1520781 hits, 1520923 requests, 1.000 recent hit rate, 14400 save period in seconds
Row Cache              : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
Counter Cache          : entries 0, size 0 bytes, capacity 50 MB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Token                  : 0
  3. 중고 서버 상태 (제공 클라이언트 API) 
    nodetool -h localhost statusthrift

    위 명령어의 출력은 다음과 같습니다.

    running
  4. 데이터 스트리밍 작업 상태: cassandra 노드의 트래픽을 관찰합니다. 
    nodetool -h localhost netstats

    위 명령어의 출력은 다음과 같습니다.

    Mode: NORMAL
Not sending any streams.
Read Repair Statistics:
Attempted: 151612
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool Name                    Active   Pending      Completed   Dropped
Commands                        n/a         0              0         0
Responses                       n/a         0              0       n/a

nodetool에 관한 자세한 내용은 다음을 참고하세요. nodetool 유틸리티 정보

Cassandra 모니터링 (UI)

datastax opscenter URL(http://www.datastax.com/products/opscenter)을 참조하세요.

Cassandra 리소스

http://www.datastax.com/docs/1.0/operations/monitoring을 참조하세요.

Apache ZooKeeper

주키퍼 상태 확인

  1. ZaKeeper 프로세스가 실행 중인지 확인합니다. 주키퍼는 PID 파일을 opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid
  2. 주키퍼 포트를 테스트하여 포트 2181 및 포트 80에 TCP 연결을 설정할 수 있는지 확인 3888입니다.
  3. ZooKeeper 데이터베이스에서 값을 읽을 수 있는지 확인합니다. 주키퍼를 사용하여 연결 클라이언트 라이브러리 (또는 /opt/apigee/apigee-zookeeper/bin/zkCli.sh)에서 값을 읽고 값을 읽습니다. 삭제할 수 있습니다
  4. 상태를 파악합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

4자로 된 주키퍼 단어 사용

동물원은 netcat (nc) 또는 telnet을 사용하여 포트 2181에 연결합니다.

ZooKeeper 명령어에 대한 자세한 내용은 Apache ZaKeeper 명령어 참조를 확인하세요.

예를 들면 다음과 같습니다.

  • srvr: 서버의 전체 세부정보를 나열합니다.
  • stat: 서버 및 연결된 클라이언트에 관한 간략한 세부정보를 나열합니다.

다음 명령어를 주키퍼 포트로 실행할 수 있습니다.

  1. 4자로 된 명령어 ruok를 실행하여 서버가 오류가 아닌 상태로 실행 중인지 테스트합니다. 가 성공하면 'imok'를 반환합니다. 
    echo ruok | nc host 2181

    반환:

    imok
  2. 네 글자로 된 명령어 stat를 실행하여 서버 성능과 연결된 상태를 나열합니다. 클라이언트 통계: 
    echo stat | nc host 2181

    반환:

    Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT
Clients:
/0:0:0:0:0:0:0:1:33467[0](queued=0,recved=1,sent=0)
/192.168.124.201:42388[1](queued=0,recved=8433,sent=8433)
/192.168.124.202:42185[1](queued=0,recved=1339,sent=1347)
/192.168.124.204:39296[1](queued=0,recved=7688,sent=7692)
Latency min/avg/max: 0/0/128
Received: 26144
Sent: 26160
Connections: 4
Outstanding: 0
Zxid: 0x2000002c2
Mode: follower
Node count: 283
     드림
  3. netcat (nc)을 사용할 수 없는 경우 python을 사용할 수 있습니다. 파일 만들기 이름이 zookeeper.py이며 다음을 포함합니다. 
    import time, socket,
sys c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
c.connect((sys.argv[1], 2181))
c.send(sys.argv[2])
time.sleep(0.1)
print c.recv(512)

    이제 다음 Python 줄을 실행합니다.

    python zookeeper.py 192.168.124.201 ruok
python zookeeper.py 192.168.124.201 stat

LDAP 수준 테스트

OpenLDAP을 모니터링하여 특정 요청이 제대로 제공되는지 확인할 수 있습니다. 포함 즉, 올바른 결과를 반환하는 특정 검색이 있는지 확인해야 합니다.

  1. ldapsearch (yum install openldap-clients)를 사용하여 항목 쿼리 시스템 관리자 역할입니다. 이 항목은 모든 API 호출을 인증하는 데 사용됩니다. 
    ldapsearch -b "uid=admin,ou=users,ou=global,dc=apigee,dc=com" -x -W -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -LLL

    그러면 LDAP 관리자 비밀번호를 입력하라는 메시지가 표시됩니다.

    Enter LDAP Password:

    비밀번호를 입력하면 양식에 응답이 표시됩니다.

    dn:
uid=admin,ou=users,ou=global,dc=apigee,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
uid: admin
cn: admin
sn: admin
userPassword:: e1NTSEF9bS9xbS9RbVNXSFFtUWVsU1F0c3BGL3BQMkhObFp2eDFKUytmZVE9PQ=
 =
mail: opdk@google.com
  2. 다음 명령어를 사용하여 관리 서버가 여전히 LDAP에 연결되어 있는지 확인합니다. 
    curl -u userEMail:password http://localhost:8080/v1/users/ADMIN

    반환:

    {
  "emailId" : ADMIN,
  "firstName" : "admin",
  "lastName" : "admin"
}

또한 OpenLDAP 캐시를 모니터링하여 디스크 액세스 수를 줄일 수 있습니다. 시스템의 성능을 개선할 수 있습니다 애플리케이션의 캐시 크기를 모니터링한 후 OpenLDAP 서버는 디렉터리 서버의 성능에 큰 영향을 줄 수 있습니다. 여기에서 로그를 볼 수 있습니다. 파일 (opt/apigee/var/log)을 사용하여 캐시에 대한 정보를 가져옵니다.