프라이빗 클라우드용 Edge v. 4.16.05
이 문서에서는 Apigee Edge의 온프레미스 배포에서 지원하는 구성요소의 모니터링 기술을 설명합니다.
JMX 인증 사용 설정 및 JMX 비밀번호 설정
관리 서버, 메시지 프로세서, Qpid, Postgres의 모니터링 프로세스는 모두 JMX를 사용합니다. JMX는 기본적으로 사용 설정되며 원격 JMX 액세스에는 비밀번호가 필요하지 않습니다.
JMX 인증을 사용 설정하기 위해 각 구성요소에는 인증을 사용 설정/사용 중지하고 JMX 사용자 인증 정보를 설정하는 데 사용하는 change_jmx_auth 작업이 있습니다.
JMX 인증을 사용 설정하려면 다음 명령어를 사용합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service comp change_jmx_auth optionsOrConfigFile
각 항목의 의미는 다음과 같습니다.
- comp는 edge-management-server, edge-message-processor, edge-router, edge-qpid-server, 또는 edge-postgres-server입니다.
- 옵션은 다음과 같습니다.
- -u: 사용자 이름
- -p: 비밀번호
- -e: y (사용 설정) 또는 n(사용 중지)
- 구성 파일에는 다음이 포함됩니다.
- JMX_USERNAME=username
- JMX_ENABLED=y/n
- JMX_PASSWORD=password(설정되지 않았거나 -p로 전달되지 않은 경우 메시지가 표시됨)
예를 들어 명령줄에서 옵션을 사용하려면 다음 안내를 따르세요.
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -u foo -p bar -e y
구성 파일이 있는 경우:
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -f configFile
여러 노드에서 Edge를 실행하는 경우 동일한 사용자 이름과 비밀번호를 지정하여 모든 노드에서 이 명령어를 실행합니다.
나중에 JMX 인증을 사용 중지하려면 다음 명령어를 사용합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -e n
관리 서버
JConsole을 사용하여 시스템 상태 점검 및 프로세스 정보 모니터링
JConsole (JMX 호환 도구)을 사용하여 상태 점검 및 프로세스 통계를 관리하고 모니터링합니다. JConsole을 사용하면 Management Server (또는 모든 서버)에서 노출하는 JMX 통계를 사용하고 그래픽 인터페이스에 표시할 수 있습니다. JConsole 사용에 대한 자세한 내용은 http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html을 참조하세요.
JConsole 및 다음 서비스 URL을 사용하여 JMX를 통해 제공되는 JMX 속성(MBean)을 모니터링합니다.
service:jmx:rmi:///jndi/rmi://<ip address>:<port>/platform
여기서 <ip address>는 관리 서버 (또는 각 서버)의 IP 주소입니다. 기본적으로 Management Server의 포트는 1099입니다.
다음 표에는 일반 JMX 통계가 나와 있습니다.
|
JMX MBean |
JMX 속성 |
|---|---|
|
메모리 |
HeapMemoryUsage |
|
NonHeapMemoryUsage |
|
|
사용 |
|
|
참고: 속성 값은 커밋됨, 초기화, 최댓값, 사용됨의 네 가지 값으로 표시됩니다. |
|
Edge Application API 검사 사용
다음 CURL 명령어를 호출하여 관리 서버 (또는 모든 서버)에서 API 검사를 수행할 수 있습니다.
curl http://<host>:8080/v1/servers/self/up
여기서 <host>는 관리 서버의 IP 주소입니다.
이 호출은 'true' 및 'false'를 반환합니다. true이면 노드가 작동 중이고 Java 서비스가 실행 중임을 의미합니다.
HTTP 200 (OK) 응답을 받지 못하면 Edge가 포트 8080 요청에 응답할 수 없습니다.
문제 해결
- 서버에 로그인하고 다음 명령어를 실행합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server status - 서비스가 실행 중이 아니면 서비스를 시작합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server start
Edge 애플리케이션 사용 – 사용자, 조직, 배포 확인
관리 서버는 각 온프레미스 설치에서 다른 모든 파셀을 함께 유지하는 데 중요한 역할을 합니다. 다음 명령어를 실행하여 관리 서버에서 사용자, 조직, 배포 상태를 확인할 수 있습니다.
curl -u userEmail:password http://localhost:8080/v1/users curl -u userEmail:password http://localhost:8080/v1/organizations curl -u userEmail:password http://localhost:8080/v1/organizations/orgname/deployments
시스템에 모든 통화의 '배포됨' 상태가 표시되어야 합니다. 이 방법으로 문제가 해결되지 않으면 다음을 실행합니다.
- 관리 서버 로그 (<inst_root>/apigee/var/log/edge-management-server)에서 오류가 있는지 확인합니다.
- 관리 서버를 호출하여 제대로 작동하는지 확인합니다.
- ELB에서 서버를 삭제한 후 Management Server를 다시 시작합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server restart
라우터
다음 CURL 명령어를 호출하여 라우터 (또는 모든 서버)에서 API 검사를 수행할 수 있습니다.
curl http://<host>:8081/v1/servers/self/up
여기서 호스트는 라우터의 IP 주소입니다.
이 호출은 'true' 및 'false'를 반환합니다. true이면 노드가 작동 중이고 Java 서비스가 실행 중임을 의미합니다.
HTTP 200 (OK) 응답을 받지 못하면 Edge가 포트 8081 요청에 응답할 수 없습니다.
문제 해결
- 서버에 로그인하고 다음 명령어를 실행합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-router status - 서비스가 실행 중이 아니면 서비스를 시작합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-router start - 서비스가 실행 중이면 작동하는지 테스트합니다. reachableCount에 대해 memberCount를 확인하여 클러스터 상태를 모니터링하고 'memberCount != reachableCount'가 있는 모든 인스턴스에 알림을 보냅니다.
curl -v -u <userEmail>:<password> http://localhost:port/v1/cluster
여기서 포트는 라우터의 경우 8081이고 메시지 프로세서의 경우 8082입니다. 위 CURL 명령어의 출력은 다음과 같습니다.
{
"memberCount" : 12,
"pod" : "rea1gw001",
"reachableCount" : 12,
"region" : "us-east-1",
"types" : [ "management-server" ]
* Connection #0 to host ms05apigee left intact
* Closing connection #0
} - 작동하지 않으면 다음 명령어를 실행하여 실패를 검사하거나 문제가 있는 구성원을 찾습니다.
curl http://localhost:port/v1/cluster/members
여기서 포트는 라우터의 경우 8081이고 메시지 프로세서의 경우 8082입니다. 위의 CURL 명령어 출력은 다음과 같습니다.
{
"lastChange" : 0,
"latency" : 0,
"state" : "CONNECTED",
"uuid" : "9c4c8bde-0015-4dc5-82d2-59fb326c4074"
}, {
"address" : "/192.168.5.209:4526",
"clusterType" : "router,message-processor",
"lastChange" : 1350658037228,
"latency" : 3,
"pod" : "rea1gw001",
"region" : "us-east-1",
"serverType" : "message-processor",
"state" : "CONNECTED",
"uuid" : "f1c663a1-2bb8-469f-b5fd-69a5c5aa91c5"
}, {
"address" : "/192.168.5.29:4526",
"clusterType" : "router,message-processor",
"lastChange" : 1350623005057,
"latency" : 1,
"pod" : "rea1gw001",
"region" : "us-east-1",
"serverType" : "message-processor",
"state" : " DISCONNECTED ",
"uuid" : "4cfe932b-f644-4581-b1ae-df338af9c7ce"
}, {
"address" : "/192.168.4.182:4526",
"clusterType" : "router,message-processor",
"lastChange" : 1350657730535,
"latency" : 1,
"pod" : "rea1gw001",
"region" : "us-east-1",
"serverType" : "message-processor",
"state" : "CONNECTED",
"uuid" : "cba063d5-b8a4-409f-9e0b-f5d403e02091"
} - IP 주소 192.168.5.29의 연결이 끊어졌습니다. 서버를 다시 시작합니다.
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-router restart
참고: 라우터의 연결이 끊어진 경우 ELB에서 라우터를 삭제한 후 다시 시작합니다. - 다시 시작한 후 작동하는지 확인합니다.
curl -v http://localhost:port/v1/cluster
여기서 port는 라우터의 경우 8081이고 메시지 프로세서의 경우 8082입니다.
메시지 프로세서
JConsole을 사용하여 시스템 상태 점검 및 프로세스 정보 모니터링
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 1101을 사용해야 합니다.
Edge Application API 검사 사용
라우터에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 8082를 사용해야 합니다.
JMX 메시지 흐름 검사 사용
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 1101을 사용해야 합니다.
Qpid 서버
JConsole을 사용하여 시스템 상태 점검 및 프로세스 정보 모니터링
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 1102를 사용해야 합니다.
Edge Application API 검사 사용
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 8083을 사용해야 합니다. Qpid 서버에는 다음 CURL 명령어도 지원됩니다.
curl http://<qpid_IP>:8083/v1/servers/self
Postgres 서버
JConsole을 사용하여 시스템 상태 점검 및 프로세스 정보 모니터링
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 1103을 사용해야 합니다.
Edge Application API 검사 사용
관리 서버에 대해 위에서 설명한 것과 동일한 단계를 따릅니다.
참고: 포트 8084를 사용해야 합니다. Postgres 서버에는 다음 CURL 명령어도 지원됩니다.
curl http://<postgres_IP>:8084/v1/servers/self
Edge 애플리케이션 조직 및 환경 검사 사용
다음 CURL 명령어를 실행하여 Postgres 서버에 온보딩된 조직 및 환경 이름을 확인할 수 있습니다.
curl http:// <postgres_IP>:8084/v1/servers/self/organizations
참고: 포트 8084를 사용해야 합니다.
시스템에 조직 및 환경 이름이 표시됩니다.
Edge 애플리케이션 axstatus 검사 사용
다음 CURL 명령어를 실행하여 분석 서버의 상태를 확인할 수 있습니다.
curl -u userEmail:password http://<host>:<port>/v1/organizations/<orgname>/environments/<envname>/provisioning/axstatus
시스템은 모든 분석 서버에 대해 SUCCESS 상태를 표시해야 합니다. 위 CURL 명령어의 출력은 다음과 같습니다.
{
"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 데이터베이스
check_postgres.pl 스크립트 사용
PostgreSQL 데이터베이스를 모니터링하려면 http://bucardo.org/wiki/Check_postgres에서 제공되는 표준 모니터링 스크립트인 check_postgres.pl을 사용하면 됩니다.
참고: check_postgres.pl 스크립트는 각 Postgres 노드에 설치해야 합니다.
스크립트를 실행하기 전에 다음을 수행합니다.
- 고해상도 알람, 절전 모드, gettimeofday, 인터벌 타이머를 구현하는 Perl 모듈인 perl-Time-HiRes.x86_64를 설치했는지 확인합니다. 예를 들어 다음 명령어를 사용하여 설치할 수 있습니다.
yum install perl-Time-HiRes.x86_64
check_postgres.pl 스크립트를 사용하는 API 호출의 기본 출력은 Nagios와 호환됩니다. 스크립트를 설치한 후 다음을 확인합니다.
- 데이터베이스 크기 - 데이터베이스 크기를 확인합니다.
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' - 데이터베이스에 대한 수신 연결 - 데이터베이스에 대한 수신 연결 수를 확인하고 허용되는 최대 연결 수와 비교합니다.
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends - 데이터베이스 가용성 및 성능 - 데이터베이스가 실행 중이고 사용 가능한지 확인합니다.
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection - 디스크 공간 - 디스크 공간을 확인합니다.
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%' - 온보딩된 조직/환경 - 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
참고: 위의 명령어를 사용하는 데 도움이 필요한 경우 http://bucardo.org/check_postgres/check_postgres.pl.html을 참조하세요.
DB 검사
PostgreSQL 데이터베이스에 적절한 테이블이 생성되었는지 확인할 수 있습니다. 다음을 사용하여 PostgreSQL 데이터베이스에 로그인합니다.
psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee
그런 후 다음을 실행합니다.
\d analytics."<org>.<env>.fact"
postgres 프로세스의 상태 확인
다음 CURL 명령어를 호출하여 postgres 머신에서 API 검사를 수행할 수 있습니다.
http://<postgres_IP>:8084/v1/servers/self/health/
참고: 포트 8084를 사용해야 합니다.
postgres 프로세스가 활성 상태이면 'ACTIVE' 상태를 반환합니다. postgres 프로세스가 실행 중이 아니면 'INACTIVE' 상태를 반환합니다.
Postgres 리소스
- http://www.postgresql.org/docs/9.0/static/monitoring.html
- http://www.postgresql.org/docs/9.0/static/diskusage.html
- http://bucardo.org/check_postgres/check_postgres.pl.html
Apache Cassandra
JConsole 사용 – 태스크 통계 모니터링
JConsole 및 다음 서비스 URL을 사용하여 JMX를 통해 제공되는 JMX 속성(MBean)을 모니터링합니다.
service:jmx:rmi:///jndi/rmi://<ip address>:7199/jmxrmi
여기서 <ip address>는 Cassandra 서버의 IP 주소입니다.
JMX는 Cassandra에 기본적으로 사용 설정되어 있으며 Cassandra에 대한 원격 JMX 액세스에는 비밀번호가 필요하지 않습니다.
JMX 인증을 사용 설정하여 비밀번호를 추가하려면 다음 안내를 따르세요.
- /<inst_root>/apigee/customer/application/cassandra.properties를 수정합니다. 파일이 없으면 만듭니다.
- 파일에 다음을 추가합니다.
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true - 파일을 저장합니다.
- $JAVA_HOME 디렉터리에서 /<inst_root>/apigee/data/apigee-cassandra/로 다음 파일을 복사합니다.
cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password
cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/apigee-cassandra/jmxremote.access - jmxremote.password를 수정하고 파일에 사용자 이름과 비밀번호를 추가합니다.
cassandra password
여기서 password는 JMX 비밀번호입니다. - jmxremote.access를 수정하고 다음 역할을 추가합니다.
cassandra readwrite - 파일이 'apigee' 소유이고 파일 모드가 400인지 확인합니다.
> chown apigee:apigee /<inst_root>/apigee/data/apigee-cassandra/jmxremote.*
> chmod 400 /<inst_root>/apigee/data/apigee-cassandra/jmxremote.* - Cassandra에서 configure를 실행합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Cassandra를 다시 시작합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
나중에 인증을 사용 중지하려면 다음 단계를 따르세요.
- /<inst_root>/apigee/customer/application/cassandra.properties를 수정합니다.
- 파일에서 다음 줄을 삭제합니다.
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true - Cassandra에서 구성을 실행합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Cassandra를 다시 시작합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
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 유틸리티를 사용하여 클러스터 노드 관리
Cassandra의 명령줄 인터페이스인 nodetool 유틸리티는 클러스터 노드를 관리하는 데 사용됩니다. 이 유틸리티는 <inst_root>/apigee/apigee-cassandra/bin에서 찾을 수 있습니다.
nodetool 유틸리티에 대한 자세한 내용은 http://www.datastax.com/docs/1.0/references/nodetool을 참조하세요.
모든 Cassandra 클러스터 노드에서 다음 호출을 수행할 수 있습니다.
- 일반 링 정보 (단일 Cassandra 노드에도 가능): 모든 노드에서 'Up' 및 'Normal'을 찾습니다.
[host]# nodetool -h localhost ring
위 명령어의 출력은 다음과 같습니다.
Address DC Rack Status State Load Owns Token
192.168.124.201 dc1 ra1 Up Normal 1.67 MB 33,33% 0
192.168.124.202 dc1 ra1 Up Normal 1.68 MB 33,33% 56713727820156410577229101238628035242
192.168.124.203 dc1 ra1 Up Normal 1.67 MB 33,33% 113427455640312821154458202477256070484 - 노드에 대한 일반 정보 (노드당 호출)
nodetool -h localhost info
위 명령어의 출력은 다음과 같습니다.
토큰 : 0
Gossip active : 참
Load : 1.67 MB
Generation No : 1361968765
가동시간 (seconds) : 78108
힙 메모리 (MB) : 46,80 / 772,00
데이터 센터 : dc1
Rack : ra1
예외 : 0 - Thrift 서버 상태 (클라이언트 API 제공)
host]# nodetool -h localhost statusthrift
위 명령어의 출력은 상태를 '실행 중'으로 표시합니다. - 데이터 스트리밍 작업 상태: cassandra 노드의 트래픽을 관찰합니다.
nodetool -h localhost netstats 192.168.124.203
위 명령어의 출력은 다음과 같습니다.
Mode: NORMAL
Nothing streaming to /192.168.124.203
Nothing streaming from /192.168.124.203
Pool Name Active Pending Completed
Commands n/a 0 1688
Responses n/a 0 292277
Cassandra 모니터링 (UI)
datastax opscenter URL(http://www.datastax.com/products/opscenter)을 참조하세요.
Cassandra 리소스
http://www.datastax.com/docs/1.0/operations/monitoring URL을 참조하세요.
Apache ZooKeeper
ZooKeeper 상태 확인
- ZooKeeper 프로세스가 실행 중인지 확인합니다. ZooKeeper는 PID 파일을 <inst_root>/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid에 작성합니다.
- ZooKeeper 포트를 테스트하여 모든 ZooKeeper 서버의 포트 2181 및 3888에 대한 TCP 연결을 설정할 수 있는지 확인합니다.
- ZooKeeper 데이터베이스에서 값을 읽을 수 있는지 확인합니다. ZooKeeper 클라이언트 라이브러리 (또는 /<inst_root>/apigee/apigee-zookeeper/bin/zkCli.sh)를 사용하여 연결하고 데이터베이스에서 값을 읽습니다.
- 상태를 확인합니다.
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-zookeeper status
ZooKeeper 4글자 단어 사용
ZooKeeper는 netcat (nc) 또는 telnet을 사용하여 포트 2181로 전송되는 작은 명령어 집합 (4글자 단어)을 통해 모니터링할 수 있습니다.
ZooKeeper 명령어에 대한 자세한 내용은 http://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_zkCommands를 참조하세요.
예를 들면 다음과 같습니다.
- srvr: 서버의 전체 세부정보를 나열합니다.
- stat: 서버 및 연결된 클라이언트에 대한 간단한 세부정보를 나열합니다.
ZooKeeper 포트에 다음 명령어를 실행할 수 있습니다.
- 4글자 명령어 ruok를 실행하여 서버가 오류가 없는 상태로 실행 중인지 테스트합니다. 응답에 성공하면 'imok'가 반환됩니다.
echo ruok | nc <host> 2181
반환:
imok - 4글자 명령어인 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
참고: ZooKeeper가 리더, 팔로어 또는 관찰자 모드인지 확인하는 것이 중요할 수 있습니다. - 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
OpenLDAP
LDAP 수준 테스트
OpenLDAP를 모니터링하여 특정 요청이 제대로 처리되는지 확인할 수 있습니다. 즉, 올바른 결과를 반환하는 특정 검색을 확인합니다.
- 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@apigee.com - 관리 서버가 LDAP 문제에 계속 연결되어 있는지 확인합니다.
curl -u <userEMail>:<password> http://localhost:8080/v1/users/<ADMIN>
반환:
{
"emailId" : <ADMIN>,
"firstName" : "admin",
"lastName" : "admin"
}
또한 OpenLDAP 캐시를 모니터링하여 디스크 액세스 수를 줄이고 시스템 성능을 개선할 수 있습니다. OpenLDAP 서버에서 캐시 크기를 모니터링한 후 조정하면 디렉터리 서버의 성능에 큰 영향을 미칠 수 있습니다. 로그 파일 (<inst_root>/apigee/var/log)을 확인하여 캐시에 대한 정보를 얻을 수 있습니다.