Jak monitorować

Edge for Private Cloud w wersji 4.18.05

W tym dokumencie opisano techniki monitorowania komponentów obsługiwanych przez lokalną implementację Apigee Edge.

Omówienie

Edge obsługuje kilka sposobów uzyskiwania informacji o usługach oraz sprawdzania ich stanu. W tabeli poniżej znajdziesz listę typów kontroli, które możesz przeprowadzać w przypadku poszczególnych kwalifikujących się usług:

Porty monitorowania interfejsów JMX i Management API

Każdy komponent obsługuje wywołania monitorowania interfejsu JMX i interfejsu Management API na różnych portach. W tabeli poniżej znajdziesz porty JMX i interfejsu Management API dla każdego typu serwera:

Używanie JMX

Procesy monitorowania serwera zarządzania, procesora wiadomości, Qpid i Postgres używają JMX. Jednak JMX jest domyślnie włączony tylko w przypadku Cassandra i domyślnie wyłączony we wszystkich pozostałych komponentach Edge. Zanim będzie można je monitorować, musisz włączyć JMX osobno dla każdego komponentu.

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX we wszystkich komponentach z wyjątkiem Cassandra.

Włączanie JMX

JMX jest domyślnie włączony tylko w przypadku Cassandra i domyślnie wyłączony we wszystkich innych komponentach Edge. Z tej sekcji dowiesz się, jak włączyć JMX w przypadku innych komponentów Edge.

Aby włączyć JMX:

1. Zmodyfikuj plik konfiguracji komponentu. Znajduje się on pod adresem opt/apigee/edge-component_name/bin/start. W środowiskach produkcyjnych pliki konfiguracji znajdują się na różnych komputerach.

   Wybierz jedną z tych lokalizacji plików na każdym serwerze:

   • Serwer zarządzania: /opt/apigee/edge-management-server/bin/start
   • Procesor wiadomości: /opt/apigee/edge-message-processor/bin/start
   • Postgres: /opt/apigee/edge-postgres-server/bin/start
   • Qpid: /opt/apigee/edge-qpid-server/bin/start
   • Router: /opt/apigee/edge-router/bin/start

   Przykładowo plik konfiguracji serwera zarządzania na serwerze znajduje się w folderze/opt/apigee/edge-management-server/bin/start.

2. Dodaj te opcje com.sun.management.jmxremote do wiersza exec, w którym rozpoczyna się komponent:

   -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

   Gdzie port_number to port JMX usługi. Aby uzyskać numer portu JMX usługi, zapoznaj się z artykułem Porty monitorowania interfejsu JMX i interfejsu Management API.

   Aby na przykład włączyć JMX na serwerze zarządzania, dodaj do pliku konfiguracyjnego serwera zarządzania następujące informacje:

   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

   W tym przykładzie port 1099 jest przeznaczony dla serwera zarządzania. Jak wspomnieliśmy wcześniej, każda usługa ma własny numer portu.

   Zmieniony wiersz w pliku konfiguracyjnym wygląda tak:

   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. Zapisz plik konfiguracji.
4. Ponownie uruchom komponent za pomocą polecenia restart.

   Aby na przykład ponownie uruchomić serwer zarządzania, uruchom to polecenie:

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

Uwierzytelnianie w JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX we wszystkich komponentach oprócz Cassandra, zgodnie z opisem w sekcji Włączanie uwierzytelniania JMX.

Włącz uwierzytelnianie JMX

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX we wszystkich komponentach z wyjątkiem Cassandra.

Aby włączyć uwierzytelnianie JMX, wykonaj tę czynność change_jmx_auth na wszystkich węzłach:

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

Gdzie:

• component może być jedną z tych wartości:
  • edge-management-server
  • edge-message-processor
  • edge-postgres-server
  • edge-qpid-server
  • edge-router
• options określa:
  • -u username
  • -p password
  • -e [y|n] (włącz lub wyłącz)
• config_file określa lokalizację pliku konfiguracji, w którym definiujesz:
  • JMX_USERNAME=username
  • JMX_ENABLED=y|n
  • JMX_PASSWORD=password (jeśli nie zostanie ustawiony lub nie został przekazany za pomocą -p, pojawi się odpowiedni komunikat)

Do zdefiniowania nazwy użytkownika i hasła oraz do określenia stanu włączenia lub wyłączenia możesz użyć opcji wiersza poleceń lub pliku konfiguracji. Nie określasz ani zestawu opcji, ani pliku konfiguracyjnego.

W tym przykładzie uaktywniamy uwierzytelnianie JMX dla serwera zarządzania za pomocą opcji wiersza poleceń:

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

W tym przykładzie zamiast opcji wiersza poleceń użyto pliku konfiguracji:

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

Jeśli używasz Edge na wielu węzłach, uruchom to polecenie na wszystkich węzłach, podając te same dane logowania.

Aby wyłączyć uwierzytelnianie JMX w wierszu poleceń, użyj opcji „-e n”, jak pokazano w tym przykładzie:

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

Monitorowanie za pomocą JConsole

Do zarządzania i monitorowania stanu oraz statystyk przetwarzania używaj narzędzia JConsole (kompatybilnego z JMX). Za pomocą JConsole możesz korzystać ze statystyk JMX udostępnianych przez serwery i wyświetlać je w interfejsie graficznym. Więcej informacji znajdziesz w artykule o korzystaniu z JConsole.

JConsole używa tego adresu URL usługi do monitorowania atrybutów JMX (MBeans) oferowanych przez JMX:

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

Gdzie:

• IP_address to adres IP serwera, który chcesz monitorować.
• port_number to numer portu JMX serwera, który chcesz monitorować.

Aby na przykład monitorować serwer zarządzania, uruchom polecenie podobne do tego (zakładając, że adres IP serwera to 216.3.128.12):

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

Zwróć uwagę, że w tym przykładzie podano port 1099, który jest portem JMX serwera zarządzania. Informacje o innych portach znajdziesz w artykule Porty monitorowania JMX i zarządzania interfejsem API.

Tabela poniżej zawiera ogólne statystyki JMX:

Monitorowanie za pomocą interfejsu Management API

Edge zawiera kilka interfejsów API, których możesz używać do sprawdzania usług na serwerach oraz do sprawdzania użytkowników, organizacji i wdrożeń. W tej sekcji opisano te interfejsy API.

Wykonywanie sprawdzania usługi

Interfejs Management API udostępnia kilka punktów końcowych do monitorowania i diagnozowania problemów z usługami. Te punkty końcowe to między innymi:

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

curl: Failed connect to localhost:port_number; Connection refused

Aby używać tych punktów końcowych, wywołaj narzędzie takie jak curl za pomocą poleceń, które używają tej składni:

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]"

Gdzie:

• host to adres IP serwera, który chcesz sprawdzić. Jeśli jesteś zalogowany na serwerze, możesz użyć „localhost”; w przeciwnym razie określ adres IP serwera, a także nazwę użytkownika i hasło.
• port_number to port interfejsu Management API na serwerze, który chcesz sprawdzić. Jest to inny port dla każdego typu komponentu. Na przykład port interfejsu Management API serwera zarządzania to 8080. Listę numerów portów interfejsu Management API, których możesz używać, znajdziesz w artykule Porty monitorowania JMX i Management API.

Aby zmienić format odpowiedzi, możesz ustawić nagłówek Accept jako „application/json” lub „application/xml”.

Ten przykład pokazuje stan routera na hoście lokalnym (port 8081):

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

Poniższy przykład zawiera informacje o procesorze wiadomości na porcie 216.3.128.12 (port 8082):

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

Monitorowanie stanu użytkownika, organizacji i wdrożenia

Za pomocą interfejsu Management API możesz monitorować użytkowników, organizacje i stan wdrożenia proxy na serwerach zarządzających oraz procesorach wiadomości. Aby to zrobić, użyj tych poleceń:

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

Gdzie port_number to 8080 w przypadku serwera zarządzania lub 8082 w przypadku procesora wiadomości.

Ta operacja wymaga uwierzytelnienia za pomocą nazwy użytkownika i hasła do administracji systemu.

Serwer powinien zwracać stan „deployed” (wdrożono) w przypadku wszystkich wywołań. Jeśli te metody zawiodą, wykonaj te czynności:

1. Poszukaj błędów w logach serwera. Dzienniki znajdują się w folderze:
   • Serwer zarządzania: opt/apigee/var/log/edge-management-server
   • Procesor wiadomości: opt/apigee/var/log/edge-message-processor
2. Aby sprawdzić, czy serwer działa prawidłowo, wyślij do niego żądanie.
3. Usuń serwer z ELB, a następnie go uruchom ponownie:

   /opt/apigee/apigee-service/bin/apigee-service service_name restart

   Gdzie service_name to:

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

Sprawdzanie stanu za pomocą polecenia apigee-service

Gdy zalogujesz się na serwerze, na którym działa usługa, możesz rozwiązać problemy z usługami Edge, używając polecenia apigee-service.

Aby sprawdzić stan usługi za pomocą apigee-service:

1. Zaloguj się na serwerze i uruchom to polecenie:

   /opt/apigee/apigee-service/bin/apigee-service service_name status

   Gdzie service_name jest jedną z tych wartości:

   • Serwer zarządzania: edge-management-server
   • Procesor wiadomości: edge-message-processor
   • Postgres: edge-postgres-server
   • Qpid: edge-qpid-server
   • Router: edge-router

   Na przykład:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status

2. Jeśli usługa nie działa, uruchom ją:

   /opt/apigee/apigee-service/bin/apigee-service service_name start

3. Po ponownym uruchomieniu usługi sprawdź, czy działa ona za pomocą wcześniej użytego polecenia apigee-service status lub interfejsu Management API opisanego w artykule Monitorowanie przy użyciu interfejsu Management API.

   Na przykład:

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

   Gdzie port_number to port interfejsu API zarządzania usługi.

   W tym przykładzie zakładamy, że jesteś zalogowany na serwerze i możesz użyć „localhost” jako nazwy hosta. Aby zdalnie sprawdzić stan za pomocą interfejsu Management API, musisz podać adres IP serwera i uwzględnić w wywołaniu interfejsu API nazwę użytkownika i hasło administratora systemu.

Monitorowanie Postgres

Postgres obsługuje kilka narzędzi, których możesz używać do sprawdzania jego stanu. Te narzędzia są opisane w dalszych sekcjach.

Sprawdzanie organizacji i środowisk w Postgres

Możesz sprawdzić nazwy organizacji i środowiska zarejestrowane na serwerze Postgres, uruchamiając to polecenie curl:

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

System powinien wyświetlać nazwę organizacji i środowiska.

Sprawdzanie stanu funkcji analitycznych

Stan serwerów analitycznych Postgres i Qpid możesz sprawdzić, wykonując to polecenie:curl

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

System powinien wyświetlić stan „Success” (Sukces) dla wszystkich serwerów Analytics, jak pokazano w tym przykładzie:

{
  "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"
}

Baza danych PostgreSQL

W tej sekcji opisaliśmy techniki, których możesz używać do monitorowania bazy danych Postgres.

Użyj skryptu check_postgres.pl

Aby monitorować bazę danych PostgreSQL, możesz użyć standardowego skryptu monitorowania check_postgres.pl. Więcej informacji znajdziesz na stronie http://bucardo.org/wiki/Check_postgres.

Zanim uruchomisz skrypt:

1. Na każdym węźle Postgres musisz zainstalować skrypt check_postgres.pl.
2. Upewnij się, że masz zainstalowany perl-Time-HiRes.x86_64 – moduł Perl, który implementuje minutniki o wysokiej rozdzielczości, uśpienie, pora dnia i interwały. Możesz na przykład zainstalować to polecenie, używając tego polecenia:
   

   yum install perl-Time-HiRes.x86_64

3. CentOS 7: zanim użyjesz polecenia check_postgres.pl w CentOS 7, zainstaluj pakiet RPMperl-Data-Dumper.x86_64.

Wynik polecenia check_postgres.pl

Domyślne dane wyjściowe wywołań interfejsu API za pomocą check_postgres.pl są zgodne z Nagios. Po zainstalowaniu skryptu wykonaj te czynności:

1. Sprawdź rozmiar bazy danych:

   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. Sprawdzanie liczby przychodzących połączeń z bazą danych i porównywanie jej z maksymalną dozwoloną liczbą połączeń:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends

3. Sprawdź, czy baza danych działa i jest dostępna:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection

4. Sprawdź miejsce na dysku:

   check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'

5. Sprawdź liczbę organizacji i środowisk zainstalowanych w węźle 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

Uruchamianie kontroli bazy danych

Możesz sprawdzić, czy w bazie danych PostgreSQL zostały utworzone odpowiednie tabele. Zaloguj się do bazy danych PostgreSQL za pomocą tego polecenia:

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

Następnie uruchom:

\d analytics."org.env.fact"

Sprawdzanie stanu procesu postgres

Aby wykonać sprawdzanie interfejsu API na maszynie Postgres, uruchom to polecenie: curl

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

To polecenie zwraca stan ACTIVE, gdy proces postgres jest aktywny. Jeśli proces Postgres nie jest uruchomiony, zwraca stan INACTIVE.

Zasoby Postgres

Więcej informacji o monitorowaniu usługi Postgres znajdziesz w tych dokumentach:

• 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

Korzystanie z JConsole: sprawdzanie statystyk zadań

Aby monitorować atrybuty JMX (MBeans) oferowane przez JMX, użyj JConsole i tego adresu URL usługi:

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

Gdzie IP_address to adres IP serwera Cassandra.

JMX jest domyślnie włączony dla Cassandra, a zdalny dostęp JMX do Cassandra nie wymaga hasła.

Statystyki JMX Cassandra

Zarządzanie węzłami klastra za pomocą polecenia nodetool

Narzędzie nodetool to interfejs wiersza poleceń Cassandra, który zarządza węzłami klastra. Narzędzie jest dostępne pod adresem /opt/apigee/apigee-cassandra/bin.

Na wszystkich węzłach klastra Cassandra można wykonywać te wywołania:

1. Ogólne informacje o pierścieniu (możliwe również w przypadku pojedynczego węzła Cassandra): sprawdź, czy dla wszystkich węzłów są widoczne stany „Up” (Włączony) i „Normal” (Normalny).

   nodetool -h localhost ring

   Wynik tego polecenia wygląda tak:

   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. Ogólne informacje o węzłach (wywołanie na węzeł)

   nodetool -h localhost info

   Wynik tego polecenia wygląda tak:

   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. Stan serwera Thrift (interfejs API klienta obsługi)

   nodetool -h localhost statusthrift

   Dane wyjściowe powyższego polecenia wyglądają tak:
   

   running

4. Stan operacji przesyłania strumieniowego danych: obserwuj ruch na węzłach Cassandra:

   nodetool -h localhost netstats

   Dane wyjściowe powyższego polecenia wyglądają tak:
   

   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

Więcej informacji o nodetool znajdziesz w artykule Informacje o narzędziu Nodetool.

Monitorowanie Cassandra (UI)

Otwórz stronę centrum operacji w Datastax: http://www.datastax.com/products/opscenter.

Zasób Cassandra

Zapoznaj się z tą stroną: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

Sprawdzanie stanu usługi ZooKeeper

1. Upewnij się, że proces ZooKeeper jest uruchomiony. ZooKeeper zapisuje plik PID w lokalizacji opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
2. Sprawdź porty ZooKeeper, aby upewnić się, że możesz nawiązać połączenie TCP z portami 2181 i 3888 na każdym serwerze ZooKeeper.
3. Upewnij się, że możesz odczytać wartości z bazy danych ZooKeeper. Połącz się za pomocą biblioteki klienta ZooKeeper (lub /opt/apigee/apigee-zookeeper/bin/zkCli.sh) i odczytaj wartość z bazy danych.
4. Sprawdź stan:

   /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

Używanie 4-literowych słów ZooKeeper

ZooKeeper można monitorować za pomocą niewielkiego zestawu poleceń (czteroliterowych słów), które są wysyłane na port 2181 za pomocą netcat (nc) lub telnetu.

Więcej informacji o poleceniach ZooKeeper znajdziesz w dokumentacji poleceń Apache ZooKeeper.

Na przykład:

• srvr: zawiera pełne informacje o serwerze.
• stat: wyświetla zwięzłe informacje o serwerze i połączonych klientach.

Do portu ZooKeeper można wysłać te polecenia:

1. Uruchom polecenie ruok, aby sprawdzić, czy serwer działa bezbłędnie. Odpowiedź świadcząca o pomyślnym wykonaniu operacji zwraca „imok”.

   echo ruok | nc host 2181

   Zwraca:

   imok

2. Aby wyświetlić statystyki dotyczące wydajności serwera i połączonych klientów, uruchom polecenie składające się z 4 liter: stat:

   echo stat | nc host 2181

   Zwraca:

   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. Jeśli netcat (nc) jest niedostępny, możesz użyć pythona jako alternatywy. Utwórz plik o nazwie zookeeper.py, który zawiera:

   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)

   Teraz uruchom te wiersze Pythona:

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

Test poziomu LDAP

Możesz monitorować OpenLDAP, aby sprawdzić, czy określone żądania są prawidłowo wyświetlane. Inaczej mówiąc, poszukaj konkretnego wyszukiwania, które zwraca właściwy wynik.

1. Użyj identyfikatora ldapsearch (yum install openldap-clients), aby zapytać o dane administratora systemu. Ten wpis służy do uwierzytelniania wszystkich wywołań interfejsu 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

   Następnie pojawi się prośba o podanie hasła administratora LDAP:

   Enter LDAP Password:

   Gdy wpiszesz hasło, zobaczysz odpowiedź w formie formularza:

   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. Sprawdź, czy serwer zarządzający jest nadal połączony z LDAP za pomocą tego polecenia:

   curl -u userEMail:password http://localhost:8080/v1/users/ADMIN

   Zwraca:

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

Możesz też monitorować pamięci podręczne OpenLDAP, które pomagają zmniejszyć liczbę dostępów do dysku, a tym samym poprawić wydajność systemu. Monitorowanie i dostrajanie rozmiaru pamięci podręcznej na serwerze OpenLDAP może znacznie wpłynąć na wydajność serwera katalogowego. Aby uzyskać informacje o pamięci podręcznej, możesz wyświetlić pliki dziennika (opt/apigee/var/log).