Jak monitorować

Ten dokument opisuje techniki monitorowania komponentów obsługiwanych przez lokalne wdrożenie Apigee Edge dla chmury prywatnej.

Przegląd

Edge obsługuje kilka sposobów uzyskiwania szczegółowych informacji o usługach i sprawdzania ich stanu. W tabeli poniżej znajdziesz typy kontroli, które możesz przeprowadzić w przypadku każdej kwalifikującej się usługi:

Mgmt API
Komponent Wykorzystanie pamięci [JMX*] Sprawdzanie usługi Stan wdrożenia użytkownika/organizacji axstatus Sprawdzenie bazy danych Stan aplikacji apigee-service apigee-monit**
Serwer zarządzania
procesor komunikatów
Router
Qpid
Postgres
Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji

* Zanim zaczniesz korzystać z JMX, musisz włączyć tę usługę zgodnie z opisem w sekcji Włączanie JMX.

** Usługa apigee-monit sprawdza, czy komponent działa, i próbuje go ponownie uruchomić, jeśli nie działa. Więcej informacji znajdziesz w artykule Samonaprawa za pomocą narzędzia apigee-monit.

Porty monitorowania i pliki konfiguracji

Każdy komponent obsługuje wywołania monitorowania interfejsu API zarządzania i JMX (Java Management Extensions) na różnych portach. W tabeli poniżej znajdziesz porty JMX i interfejsu API zarządzania Google Analytics dla każdego typu serwera oraz lokalizacje plików konfiguracyjnych:

Komponent Port JMX Port interfejsu API zarządzania Google Analytics Lokalizacja pliku konfiguracji
Serwer zarządzania 1099 8080 $APIGEE_ROOT/customer/application/management-server.properties
procesor komunikatów 1101 8082 $APIGEE_ROOT/customer/application/message-processor.properties
Router 1100 8081 $APIGEE_ROOT/customer/application/router.properties
Qpid 1102 8083 $APIGEE_ROOT/customer/application/qpid-server.properties
Postgres 1103 8084 $APIGEE_ROOT/customer/application/postgres-server.properties

Monitorowanie komponentów za pomocą JMX

W sekcjach poniżej opisano, jak używać JMX do monitorowania komponentów Edge.

Włącz JMX

Aby włączyć JMX bez uwierzytelniania lub komunikacji opartej na SSL, wykonaj te czynności. Uwaga: w systemach produkcyjnych ze względów bezpieczeństwa należy włączyć zarówno uwierzytelnianie szyfrowane, jak i SSL.

  1. Edytuj odpowiedni plik konfiguracji (patrz Dokumentacja pliku konfiguracji). Jeśli plik konfiguracji nie istnieje, utwórz go.
    conf_system_jmxremote_enable=true
  2. Zapisz plik konfiguracji i upewnij się, że jego właścicielem jest apigee:apigee.
  3. Ponownie uruchom odpowiedni komponent Edge
    apigee-service edge-management-server restart

Aby wyłączyć JMX, usuń właściwość conf_system_jmxremote_enable lub zmień jej wartość na false. Następnie ponownie uruchom odpowiedni komponent Edge.

Uwierzytelnianie w JMX

Edge dla chmury prywatnej obsługuje uwierzytelnianie oparte na hasłach przy użyciu danych przechowywanych w plikach. Aby zwiększyć bezpieczeństwo, możesz przechowywać hasła jako skróty.

  1. Aby włączyć uwierzytelnianie JMX w komponencie edge-*, edytuj odpowiedni plik konfiguracyjny (patrz Dokumentacja pliku konfiguracyjnego). Utwórz plik konfiguracji, jeśli nie istnieje:
    conf_system_jmxremote_enable=true
    conf_system_jmxremote_authenticate=true
    conf_system_jmxremote_encrypted_auth=true
    conf_system_jmxremote_access_file=/opt/apigee/customer/application/management-server/jmxremote.access
    conf_system_jmxremote_password_file=/opt/apigee/customer/application/management-server/jmxremote.password
     Zapisz plik konfiguracji i upewnij się, że jego właścicielem jest użytkownik apigee:apigee.
  2. Utwórz skrót SHA256 hasła:
    echo -n '' | openssl dgst -sha256
  3. Utwórz plik jmxremote.password z danymi logowania użytkownika JMX:
    1. Skopiuj te pliki z katalogu $JAVA_HOME do katalogu /opt/apigee/customer/application/<component>/:
      cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/customer/application/management-server/jmxremote.password
    2. Edytuj plik i dodaj nazwę użytkownika i hasło JMX, używając tej składni:
      USERNAME <HASH-PASSWORD>
    3. Sprawdź, czy plik należy do użytkownika apigee i czy tryb pliku to 400:
      chown apigee:apigee $APIGEE_ROOT/customer/application/management-server/jmxremote.password
      chmod 400 $APIGEE_ROOT/customer/application/management-server/jmxremote.password
  4. Utwórz plik jmxremote.access z uprawnieniami użytkownika JMX:
    1. Skopiuj te pliki z katalogu $JAVA_HOME do katalogu /opt/apigee/customer/application/<component>/:
      cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/customer/application/management-server/jmxremote.access
    2. Edytuj plik i dodaj nazwę użytkownika JMX, a następnie uprawnienie (READONLY/READWRITE).
      USERNAME READONLY
    3. Sprawdź, czy plik należy do użytkownika apigee i czy tryb pliku to 400:
      chown apigee:apigee $APIGEE_ROOT/customer/application/management-server/jmxremote.access
      chmod 400 $APIGEE_ROOT/customer/application/management-server/jmxremote.access
  5. Uruchom ponownie odpowiedni komponent Edge:
    apigee-service edge-management-server restart

Aby wyłączyć uwierzytelnianie JMX, usuń właściwość conf_system_jmxremote_authenticate lub zmień wartość na false i uruchom ponownie odpowiedni komponent Edge.

SSL w JMX

Aby włączyć JMX oparty na SSL w komponencie edge-*:

  1. Edytuj odpowiedni plik konfiguracji (patrz Dokumentacja pliku konfiguracji). Utwórz plik konfiguracji, jeśli nie istnieje:
    conf_system_jmxremote_enable=true
    conf_system_jmxremote_ssl=true
    conf_system_javax_net_ssl_keystore=/opt/apigee/customer/application/management-server/jmxremote.keystore
    conf_system_javax_net_ssl_keystorepassword=<keystore-password>
    Zapisz plik konfiguracji i upewnij się, że jego właścicielem jest apigee:apigee.
  2. Przygotuj magazyn kluczy zawierający klucz serwera i umieść go w ścieżce podanej w konfiguracji conf_system_javax_net_ssl_keystore powyżej. Upewnij się, że plik magazynu kluczy jest czytelny dla apigee:apigee.
  3. Ponownie uruchom odpowiedni komponent Edge:
    apigee-service edge-management-server restart

Aby wyłączyć JMX oparty na SSL, usuń właściwość conf_system_jmxremote_ssl lub zmień wartość na false. Uruchom ponownie odpowiedni komponent Edge.

Monitorowanie za pomocą JConsole

Użyj JConsole (narzędzia zgodnego z JMX), aby zarządzać kontrolą stanu i statystykami procesów oraz je monitorować. Za pomocą JConsole możesz wykorzystywać statystyki JMX udostępniane przez serwery i wyświetlać je w interfejsie graficznym. Więcej informacji znajdziesz w artykule Korzystanie z JConsole.

Jeśli dla JMX włączony jest protokół SSL, musisz uruchomić JConsole z magazynem zaufanych certyfikatów i hasłem do niego. Zobacz Korzystanie 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ądzający, wydaj 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

Pamiętaj, że w tym przykładzie określono port 1099, który jest portem JMX serwera zarządzania. Informacje o innych portach znajdziesz w artykule Porty monitorowania interfejsu JMX i Management API.

W tabeli poniżej przedstawiono ogólne statystyki JMX:

JMX MBeans Atrybuty JMX

Pamięć

HeapMemoryUsage

NonHeapMemoryUsage

Wykorzystanie

Plik referencyjny konfiguracji

W poniższych sekcjach opisano zmiany, które może być konieczne wprowadzić w plikach konfiguracji komponentów Edge w przypadku konfiguracji związanych z JMX. Więcej informacji znajdziesz w artykule Monitorowanie portów i plików konfiguracyjnych.

Konfiguracja JMX, którą należy dodać do pliku konfiguracji odpowiedniego komponentu

  • Włącz agenta JMX w komponencie brzegowym. Domyślnie ma wartość false.
    conf_system_jmxremote_enable=true

Konfiguracje uwierzytelniania opartego na haśle

  • Włącz uwierzytelnianie oparte na haśle. Domyślnie ma wartość false.
    conf_system_jmxremote_authenticate=true
  • Ścieżka dostępu do pliku. Powinien być własnością użytkownika Apigee i tylko on powinien mieć do niego dostęp do odczytu.
    conf_system_jmxremote_access_file=/opt/apigee/customer/application/management-server/jmxremote.access
  • Ścieżka do pliku z hasłem. Powinien być własnością użytkownika Apigee i być możliwy do odczytu tylko przez niego.
    conf_system_jmxremote_password_file=/opt/apigee/customer/application/management-server/jmxremote.password
  • Włącz przechowywanie haseł w zaszyfrowanym formacie. Domyślnie ma wartość false.
    conf_system_jmxremote_encrypted_auth=true

Konfiguracje JMX opartego na SSL

  • Włącz SSL na potrzeby komunikacji JMX. Domyślnie ma wartość „fałsz”.
    conf_system_jmxremote_ssl=true
  • Ścieżka do magazynu kluczy. Powinien być własnością użytkownika Apigee i tylko on powinien mieć do niego dostęp do odczytu.
    conf_system_javax_net_ssl_keystore=/opt/apigee/customer/application/management-server/jmxremote.keystore
  • Hasło magazynu kluczy:
    conf_system_javax_net_ssl_keystorepassword=changeme

Opcjonalne konfiguracje JMX

Podane wartości są wartościami domyślnymi i można je zmienić.

  • Port JMX. Wartości domyślne znajdziesz w tabeli poniżej.
    conf_system_jmxremote_port=
  • Port JMX RMI. Domyślnie proces Java wybiera losowy port.
    conf_system_jmxremote_rmi_port=
  • Nazwa hosta dla zdalnych stubów. Domyślny adres IP hosta lokalnego.
    conf_system_java_rmi_server_hostname=
  • Zabezpiecz rejestr JMX za pomocą protokołu SSL. Wartość domyślna to false. Ma zastosowanie tylko wtedy, gdy włączony jest protokół SSL.
    conf_system_jmxremote_registry_ssl=false

Monitorowanie za pomocą interfejsu API zarządzania Google Analytics

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

Przeprowadzanie kontroli usług

Interfejs API zarządzania Google Analytics udostępnia kilka punktów końcowych do monitorowania i diagnozowania problemów z usługami. Te punkty końcowe obejmują:

Punkt końcowy Opis
/servers/self/up

Sprawdza, czy usługa działa. To wywołanie interfejsu API nie wymaga uwierzytelniania.

Jeśli usługa działa, ten punkt końcowy zwraca tę odpowiedź:

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

Jeśli usługa nie jest uruchomiona, otrzymasz odpowiedź podobną do tej (w zależności od tego, jaka to usługa i jak została sprawdzona):

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

Zwraca informacje o usłudze, w tym:

  • Właściwości konfiguracji
  • Czas rozpoczęcia i czas działania
  • Informacje o kompilacji, RPM i UUID
  • Wewnętrzna i zewnętrzna nazwa hosta oraz adres IP
  • Region i pod
  • właściwość <isUp> wskazująca, czy usługa jest uruchomiona;

To wywołanie interfejsu API wymaga uwierzytelnienia za pomocą danych logowania administratora Apigee.

Aby użyć 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(-a) na serwerze, możesz użyć „localhost”. W przeciwnym razie podaj adres IP serwera, a także nazwę użytkownika i hasło.
  • port_number to port interfejsu API zarządzania Google Analytics dla serwera, który chcesz sprawdzić. Jest to inny port dla każdego typu komponentu. Na przykład port interfejsu API zarządzania Google Analytics serwera zarządzania to 8080. Listę numerów portów interfejsu API zarządzania Google Analytics, których można używać, znajdziesz w artykule o portach monitorowania interfejsów API JMX i interfejsu API zarządzania Google Analytics.

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

W tym przykładzie pobierany jest stan routera na serwerze lokalnym (port 8081):

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

Ten przykład pokazuje, jak uzyskać informacje o procesorze komunikatów pod adresem 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

Możesz używać interfejsu API zarządzania Google Analytics do monitorowania stanu użytkowników, organizacji i wdrożeń serwerów proxy na serwerach zarządzania i procesorach komunikatów, wydając te polecenia:

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 komunikatów.

To wywołanie wymaga uwierzytelnienia przy użyciu nazwy użytkownika i hasła administratora systemu.

Serwer powinien zwracać stan „wdrożono” w przypadku wszystkich wywołań. Jeśli to nie pomoże, wykonaj te czynności:

  1. Poszukaj błędów w logach serwera. Dzienniki znajdują się tutaj:
    • Serwer zarządzania: opt/apigee/var/log/edge-management-server
    • Procesor komunikatów: opt/apigee/var/log/edge-message-processor
  2. Wykonaj wywołanie do serwera, aby sprawdzić, czy działa on prawidłowo.
  3. Usuń serwer z ELB, a następnie uruchom go ponownie:
    /opt/apigee/apigee-service/bin/apigee-service service_name restart

    Gdzie service_name:

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

Sprawdzanie stanu za pomocą polecenia apigee-service

Aby rozwiązać problemy z usługami Edge, użyj polecenia apigee-service po zalogowaniu się na serwerze, na którym działa usługa.

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 to jedna z tych wartości:

    • Serwer zarządzania: edge-management-server
    • Procesor komunikatów: 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, używając polecenia apigee-service status, którego użyto wcześniej, lub interfejsu API zarządzania Google Analytics opisanego w sekcji Monitorowanie za pomocą interfejsu API zarządzania Google Analytics.

    Na przykład:

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

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

    W tym przykładzie zakłada się, że jesteś zalogowany(-a) na serwerze i możesz użyć „localhost” jako nazwy hosta. Aby sprawdzić stan zdalnie za pomocą interfejsu API zarządzania Google Analytics, musisz podać adres IP serwera i dołączyć nazwę użytkownika oraz hasło administratora systemu w wywołaniu interfejsu API.

Monitorowanie Postgres

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

Sprawdzanie organizacji i środowisk w Postgres

Aby sprawdzić nazwy organizacji i środowisk, które zostały wprowadzone na serwerze Postgres, możesz użyć tego polecenia curl:

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

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

Sprawdzanie stanu statystyk

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

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

System powinien wyświetlić stan powodzenia dla wszystkich serwerów analitycznych, jak 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 opisujemy techniki, których możesz używać do monitorowania bazy danych Postgres.

Używanie skryptu check_postgres.pl

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

Przed uruchomieniem skryptu:

  1. Skrypt check_postgres.pl musisz zainstalować na każdym węźle Postgres.
  2. Upewnij się, że masz zainstalowany moduł perl-Time-HiRes.x86_64, moduł języka PERL implementujący alarm o wysokiej rozdzielczości, uśpienie, gettimeofday i stopery interwałowe. Możesz go na przykład zainstalować za pomocą tego polecenia:
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: zanim użyjesz check_postgres.pl w systemie CentOS w wersji 7, zainstaluj RPM perl-Data-Dumper.x86_64.

Dane wyjściowe skryptu 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. Sprawdź liczbę połączeń przychodzących z bazą danych i porównaj ją 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 zarejestrowanych 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

Przeprowadzanie kontroli bazy danych

Możesz sprawdzić, czy w bazie danych PostgreSQL zostały utworzone odpowiednie tabele. Zaloguj się w bazie 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

Możesz przeprowadzić testy interfejsu API na maszynie Postgres, wywołując 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 działa, zwracany jest stan INACTIVE.

Zasoby Postgres

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

Apache Cassandra

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

Włączanie uwierzytelniania JMX dla systemu Cassandra

Możesz włączyć uwierzytelnianie JMX dla systemu Cassandra. Po wykonaniu tej czynności musisz podać nazwę użytkownika i hasło we wszystkich wywołaniach narzędzia nodetool.

Aby włączyć uwierzytelnianie JMX w przypadku Cassandra:

  1. Utwórz i edytuj plik cassandra.properties:
    1. Zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties. Jeśli plik nie istnieje, utwórz go.
    2. Dodaj do pliku te informacje:
      conf_cassandra_env_com.sun.management.jmxremote.authenticate=true
      conf_cassandra_env_com.sun.management.jmxremote.password.file=${APIGEE_ROOT}/customer/application/apigee-cassandra/jmxremote.password
      conf_cassandra_env_com.sun.management.jmxremote.access.file=${APIGEE_ROOT}/customer/application/apigee-cassandra/jmxremote.access
    3. Zapisz plik cassandra.properties.
    4. Zmień właściciela pliku na apigee:apigee, jak pokazano w tym przykładzie:
      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

    Więcej informacji o używaniu plików właściwości do ustawiania tokenów znajdziesz w artykule Konfigurowanie Edge.

  2. Tworzenie i edytowanie jmx_auth.sh:
    1. Jeśli plik nie istnieje, utwórz go w tej lokalizacji:
      /opt/apigee/customer/application/jmx_auth.sh
    2. Dodaj do pliku te właściwości:
      export CASS_JMX_USERNAME=JMX_USERNAME
      export CASS_JMX_PASSWORD=JMX_PASSWORD
    3. Zapisz plik jmx_auth.sh.
    4. Uruchom plik:
      source /opt/apigee/customer/application/jmx_auth.sh
  3. Skopiuj i edytuj plik jmxremote.password:
    1. Skopiuj ten plik z katalogu $JAVA_HOME do /opt/apigee/customer/application/apigee-cassandra/:
      cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/customer/application/apigee-cassandra/jmxremote.password
    2. Edytuj plik jmxremote.password i dodaj nazwę użytkownika i hasło JMX w tym formacie:
      JMX_USERNAME JMX_PASSWORD

      gdzie JMX_USERNAME i JMX_PASSWORD to nazwa użytkownika i hasło JMX ustawione wcześniej.

    3. Upewnij się, że plik należy do „apigee” i że tryb pliku to 400:
      chown apigee:apigee /opt/apigee/customer/application/apigee-cassandra/jmxremote.password
      chmod 400 /opt/apigee/customer/application/apigee-cassandra/jmxremote.password
  4. Skopiuj i edytuj plik jmxremote.access:
    1. Skopiuj ten plik z katalogu $JAVA_HOME do katalogu /opt/apigee/customer/application/apigee-cassandra/:
      cp ${JAVA_HOME}/lib/management/jmxremote.access
      $APIGEE_ROOT/customer/application/apigee-cassandra/jmxremote.access
    2. Zmodyfikuj plik jmxremote.access i dodaj tę rolę:
      JMX_USERNAME readwrite
    3. Upewnij się, że plik należy do „apigee” i że tryb pliku to 400:
      chown apigee:apigee /opt/apigee/customer/application/apigee-cassandra/jmxremote.access
      chmod 400 /opt/apigee/customer/application/apigee-cassandra/jmxremote.access
  5. Uruchom configure w Cassandrze:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  6. Uruchom ponownie Cassandrę:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  7. Powtórz ten proces na wszystkich pozostałych węzłach Cassandra.

Włącz szyfrowanie haseł JMX

Aby włączyć szyfrowanie haseł JMX, wykonaj te czynności:

  1. Otwórz plik source/conf/casssandra-env.sh.
  2. Utwórz i edytuj plik cassandra.properties:
    1. Zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties. Jeśli plik nie istnieje, utwórz go.
    2. Dodaj do pliku te elementy:
      conf_cassandra_env_com.sun.management.jmxremote.encrypted.authenticate=true
    3. Zapisz plik cassandra.properties.
    4. Zmień właściciela pliku na apigee:apigee, jak pokazano w tym przykładzie:
      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. W wierszu poleceń wygeneruj skróty SHA1 odpowiednich haseł, wpisując echo -n 'Secret' | openssl dgst -sha1.
  4. Ustaw hasła dla nazwy użytkownika w pliku $APIGEE_ROOT/customer/application/apigee-cassandra/jmxremote.password (utworzonym w poprzedniej sekcji).
  5. Uruchom konfigurację w systemie Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  6. Uruchom ponownie Cassandrę:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  7. Powtórz ten proces na wszystkich pozostałych węzłach Cassandra.

Włączanie JMX z SSL w przypadku systemu Cassandra

Włączenie JMX z SSL zapewnia dodatkowe zabezpieczenia i szyfrowanie komunikacji z Cassandra opartej na JMX. Aby włączyć JMX z SSL, musisz podać klucz i certyfikat do Cassandry, aby akceptować połączenia JMX oparte na SSL. Musisz też skonfigurować narzędzie nodetool (i inne narzędzia, które komunikują się z Cassandrą za pomocą JMX) pod kątem SSL.

JMX z obsługą SSL obsługuje zarówno hasła JMX w postaci zwykłego tekstu, jak i zaszyfrowane.

Aby włączyć JMX z SSL dla Cassandra, wykonaj te czynności:

  1. Włącz JMX. W razie potrzeby włącz szyfrowanie haseł.
  2. Włącz uwierzytelnianie JMX dla Cassandra. zgodnie z opisem powyżej. Sprawdź, czy narzędzie nodetool działa z użyciem skonfigurowanej nazwy użytkownika i hasła.
    /opt/apigee/apigee-cassandra/bin/nodetool -u <JMX_USER> -pw <JMX_PASS> ring
  3. Przygotuj magazyn kluczy i magazyn zaufanych certyfikatów.

    • Magazyn kluczy powinien zawierać klucz i certyfikat i służy do konfigurowania serwera Cassandra. Jeśli magazyn kluczy zawiera wiele par kluczy, Cassandra używa pierwszej pary kluczy do włączenia SSL.

      Pamiętaj, że hasła do magazynu kluczy i klucza powinny być takie same (jest to domyślne ustawienie podczas generowania klucza za pomocą narzędzia keytool).

    • Magazyn zaufanych certyfikatów powinien zawierać tylko certyfikat i jest używany przez klientów (polecenia oparte na apigee-service lub nodetool) do łączenia się przez JMX.

    Po sprawdzeniu powyższych wymagań:

    1. Umieść plik magazynu kluczy w folderze /opt/apigee/customer/application/apigee-cassandra/.
    2. Sprawdź, czy plik magazynu kluczy jest czytelny tylko dla użytkownika Apigee, wpisując
      chown apigee:apigee /opt/apigee/customer/application/apigee-cassandra/keystore.node1
      chmod 400 /opt/apigee/customer/application/apigee-cassandra/keystore.node1
  4. Skonfiguruj Cassandra pod kątem JMX z SSL, wykonując te czynności:
    1. Zatrzymaj węzeł Cassandra, wpisując:
      apigee-service apigee-cassandra stop
    2. Włącz SSL w systemie Cassandra, otwierając plik /opt/apigee/customer/application/cassandra.properties i dodając te wiersze:
      conf_cassandra_env_com.sun.management.jmxremote.ssl=true
      conf_cassandra_env_javax.net.ssl.keyStore=/opt/apigee/customer/application/apigee-cassandra/keystore.node1
      conf_cassandra_env_javax.net.ssl.keyStorePassword=keystore-password
    3. Zmień właściciela pliku na apigee:apigee, jak w tym przykładzie:
      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    4. Uruchom konfigurację w systemie Cassandra:
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
    5. Uruchom ponownie Cassandrę:
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
    6. Powtórz ten proces na wszystkich pozostałych węzłach Cassandra.
    7. Uruchom węzeł Cassandra, wpisując:
      apigee-service apigee-cassandra start
  5. Skonfiguruj polecenia Cassandra apigee-service. Podczas uruchamiania poleceń apigee-service musisz ustawić określone zmienne środowiskowe, w tym te poniżej:
    apigee-service apigee-cassandra stop
    apigee-service apigee-cassandra wait_for_ready
    apigee-service apigee-cassandra ring
    apigee-service apigee-cassandra backup

    Istnieje kilka opcji konfigurowania apigee-service na potrzeby uwierzytelniania JMX i SSL. Wybierz opcję na podstawie użyteczności i praktyk dotyczących bezpieczeństwa.

    Opcja 1 (argumenty SSL przechowywane w pliku)

    Ustaw te zmienne środowiskowe:

    export CASS_JMX_USERNAME=ADMIN
    # Provide encrypted password here if you have setup JMX password encryption
    export CASS_JMX_PASSWORD=PASSWORD
    export CASS_JMX_SSL=Y

    Utwórz plik w katalogu domowym użytkownika Apigee (/opt/apigee).

    $HOME/.cassandra/nodetool-ssl.properties

    Zmodyfikuj plik i dodaj te wiersze:

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
    -Djavax.net.ssl.trustStorePassword=<truststore-password>
    -Dcom.sun.management.jmxremote.registry.ssl=true
    -Djavax.net.ssl.trustStoreType=PKCS12

    Upewnij się, że plik magazynu zaufanych certyfikatów może być odczytywany przez użytkownika Apigee.

    Uruchom to polecenie apigee-service. Jeśli nie wystąpią błędy, konfiguracja jest prawidłowa.

    apigee-service apigee-cassandra ring

    Opcja 2. Argumenty SSL przechowywane w zmiennych środowiskowych

    Ustaw te zmienne środowiskowe:

    export CASS_JMX_USERNAME=ADMIN
    # Provide encrypted password here if you have setup JMX password encryption
    export CASS_JMX_PASSWORD=PASSWORD
    export CASS_JMX_SSL=Y
    # Ensure the truststore file is accessible by Apigee user.
    export CASS_JMX_TRUSTSTORE=<path-to-trustore.node1>
    export CASS_JMX_TRUSTSTORE_PASSWORD=<truststore-password>
    # If you are using a non standard truststore type, export truststore type as well
    # Possible values are JKS, PKCS12, BCFKS
    export CASS_JMX_TRUSTSTORE_TYPE=PKCS12

    Uruchom to polecenie apigee-service. Jeśli nie wystąpią błędy, konfiguracja jest prawidłowa.

    apigee-service apigee-cassandra ring

    Opcja 3 (argumenty SSL przekazywane bezpośrednio do apigee-service)

    Uruchom dowolne polecenie apigee-service, np. to poniżej. Nie musisz konfigurować żadnych zmiennych środowiskowych.

    CASS_JMX_USERNAME=ADMIN CASS_JMX_PASSWORD=PASSWORD CASS_JMX_SSL=Y CASS_JMX_TRUSTSTORE=<path-to-trustore.node1> CASS_JMX_TRUSTSTORE_PASSWORD=<trustore-password> CASS_JMX_TRUSTSTORE_TYPE=PKCS12 /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra ring
  6. Skonfiguruj narzędzie nodetool. Narzędzie nodetool wymaga przekazania parametrów JMX. Istnieją 2 sposoby skonfigurowania narzędzia nodetool do działania z JMX z obsługą SSL, jak opisano w opcjach konfiguracji poniżej:

    Opcje różnią się sposobem przekazywania konfiguracji związanych z SSL do narzędzia nodetool. W obu przypadkach użytkownik uruchamiający narzędzie nodetool powinien mieć uprawnienia do odczytu do pliku truststore. Wybierz odpowiednią opcję na podstawie użyteczności i praktyk związanych z bezpieczeństwem.

    Więcej informacji o parametrach nodetool znajdziesz w dokumentacji Apache Cassandra nodetool.

    Opcja konfiguracji 1

    Utwórz plik w katalogu domowym użytkownika, który uruchamia nodetool.

    $HOME/.cassandra/nodetool-ssl.properties

    Dodaj do tego pliku te wiersze:

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
    -Djavax.net.ssl.trustStorePassword=<truststore-password>
    -Dcom.sun.management.jmxremote.registry.ssl=true
    -Djavax.net.ssl.trustStoreType=PKCS12

    Ścieżka do magazynu zaufanych certyfikatów podana powyżej powinna być dostępna dla każdego użytkownika uruchamiającego narzędzie nodetool.

    Uruchom nodetool z opcją --ssl.

    /opt/apigee/apigee-cassandra/bin/nodetool --ssl -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

    Opcja konfiguracji 2

    Uruchom nodetool jako pojedyncze polecenie z dodatkowymi parametrami wymienionymi poniżej.

    /opt/apigee/apigee-cassandra/bin/nodetool -Djavax.net.ssl.trustStore=<path-to-truststore.node1> -Djavax.net.ssl.trustStorePassword=<truststore-password> -Dcom.sun.management.jmxremote.registry.ssl=true -Djavax.net.ssl.trustStoreType=PKCS12 -Dssl.enable=true -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

Przywracanie konfiguracji SSL

Jeśli chcesz przywrócić konfiguracje SSL opisane w procedurze powyżej, wykonaj te czynności:

  1. Zatrzymaj apigee-cassandra, wpisując
    apigee-service apigee-cassandra stop
  2. Usuń wiersz conf_cassandra-env_com.sun.management.jmxremote.ssl=true z pliku /opt/apigee/customer/application/cassandra.properties.
  3. Zmień w komentarz te wiersze w pliku /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh:
    # JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node0"
    # JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keypass"
    # JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true”
  4. Zacznij apigee-cassandra, wpisując
  5. apigee-service apigee-cassandra start
  6. Usuń zmienną środowiskową CASS_JMX_SSL, jeśli została ustawiona.

    unset CASS_JMX_SSL
  7. Sprawdź, czy polecenia oparte na apigee-service, takie jak ring, stop, backup itp., działają.
  8. Przestań używać przełącznika --ssl z narzędziem nodetool

Wyłączanie uwierzytelniania JMX w Cassandra

Aby wyłączyć uwierzytelnianie JMX w przypadku Cassandra:

  1. Edytuj pakiet /opt/apigee/customer/application/cassandra.properties.
  2. Usuń z pliku ten wiersz:
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Uruchom konfigurację w systemie Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  4. Uruchom ponownie Cassandrę:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  5. Powtórz ten proces na wszystkich pozostałych węzłach Cassandra.

Korzystanie z JConsole: monitorowanie statystyk zadań

Aby monitorować atrybuty JMX (MBeans) udostępniane 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.

Statystyki JMX Cassandra

Komponenty MBean JMX Atrybuty 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

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

Narzędzie nodetool to interfejs wiersza poleceń Cassandry, który zarządza węzłami klastra. Narzędzie znajdziesz na stronie /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 też w przypadku pojedynczego węzła Cassandra): sprawdź, czy wszystkie węzły mają stan „Up” (Włączony) i „Normal” (Normalny).
    nodetool [-u username -pw password] -h localhost ring

    Nazwę użytkownika i hasło musisz podać tylko wtedy, gdy uwierzytelnianie JMX jest włączone w Cassandrze.

    Dane wyjściowe powyższego polecenia wyglądają 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 [-u username -pw password]  -h localhost info

    Wynik powyższego 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 (obsługującego interfejs API klienta)
    nodetool [-u username -pw password] -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 [-u username -pw password] -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 korzystaniu z narzędzia nodetool znajdziesz w artykule Informacje o narzędziu nodetool.

Zasób Cassandra

Zapoznaj się z informacjami pod tym adresem URL: Monitorowanie systemu Cassandra.

Monitorowanie Apache Qpid Broker-J

Qpid Broker-J możesz monitorować w konsoli zarządzania Qpid. W tej sekcji dowiesz się, jak uzyskać dostęp do konsoli i jak używać jej do wykonywania podstawowych funkcji monitorowania. Więcej informacji o korzystaniu z konsoli zarządzania znajdziesz w artykule Web Management Console (Internetowa konsola zarządzania) w dokumentacji Apache Qpid.

Otwieranie konsoli zarządzania

Domyślny port konsoli zarządzania to 8090. Aby uzyskać dostęp do konsoli na tym domyślnym porcie, otwórz w przeglądarce:

http://QPID_NODE_IP:8090

Aby zalogować się w konsoli, użyj domyślnych danych logowania ustawionych przez Apigee lub tych, które zostały ustawione w pliku konfiguracyjnym Edge. Szczegółowe informacje znajdziesz w dokumentacji pliku konfiguracji Edge.

Monitorowanie kolejek i wiadomości

W panelu nawigacyjnym po lewej stronie otwórz Java-Broker > virtualhosts > queues. Wybierz kolejkę, aby wyświetlić jej szczegóły w głównej części interfejsu. W widoku szczegółów możesz zobaczyć atrybuty i statystyki kolejki, w tym informacje o dostarczonych i umieszczonych w kolejce wiadomościach, szybkości przesyłania wiadomości itp.

Wyświetlanie i pobieranie plików dziennika

W panelu nawigacyjnym po lewej stronie kliknij Java-Broker > brokerloggers > logfile (Java-Broker > rejestratory brokera > plik dziennika). W widoku szczegółów głównego interfejsu możesz wyświetlić szczegóły plików dziennika i pobrać te pliki.

Korzystanie z interfejsu API zarządzania Qpid

Za pomocą interfejsu Apache Qpid Broker-J REST API możesz automatyzować zadania związane z zarządzaniem i monitorować brokera. Szczegółowe informacje znajdziesz w dokumentacji API brokera Apache Qpid typu REST.

Do monitorowania brokera możesz też używać narzędzi wiersza poleceń. Na przykład:

curl "QPID_NODE_IP":"8090"/api/latest/broker -u "USERNAME":"PASSWORD"

Włączanie monitorowania z użyciem SSL dla Qpid

Aby zapewnić dodatkowe zabezpieczenia na potrzeby monitorowania i zarządzania, włącz SSL w portalu zarządzania Qpid i interfejsach API zarządzania Qpid. Aby podać klucz i certyfikat, postępuj zgodnie z tymi wskazówkami.

Qpid udostępnia opcję magazynu kluczy plików, która jest włączona w Apigee. Ten typ akceptuje standardowy format magazynu kluczy JKS, który jest obsługiwany przez Javę i narzędzia Java, takie jak keytool. Może też akceptować magazyn kluczy PKCS12, który można wygenerować za pomocą narzędzi takich jak OpenSSL.

Przygotowanie magazynu kluczy

Informacje o generowaniu magazynów kluczy znajdziesz w dokumentacji narzędzia Java Keytool.

Informacje o generowaniu magazynów kluczy PKCS12 znajdziesz w dokumentacji OpenSSL.

Po sprawdzeniu wymagań

  1. Umieść plik magazynu kluczy w folderze /opt/apigee/customer/application/apigee-qpidd.
  2. Upewnij się, że plik magazynu kluczy może odczytywać tylko użytkownik Apigee:
    chown apigee:apigee /opt/apigee/customer/application/apigee-qpidd/qpidd.keystore
      chmod 400 /opt/apigee/customer/application/apigee-qpidd/qpidd.keystore

Włączanie SSL w Qpid

Wykonaj poniższe czynności na jednym węźle Qpid naraz:

Otwórz plik /opt/apigee/customer/application/qpidd.properties i dodaj te wiersze:

conf_qpidd_qpid_management.https.enabled=true
conf_qpidd_qpid.keystore.storeUrl=/opt/apigee/customer/application/apigee-qpidd/qpidd.keystore
conf_qpidd_qpid.keystore.password=keystore-password
conf_qpidd_qpid.keystore.certificateAlias=certificate-alias
## If you are using a PKCS12 keystore, specify the keystore type
conf_qpidd_qpid.keystore.keyStoreType=PKCS12
  1. Zmień właściciela pliku na apigee:apigee:
    chown apigee:apigee /opt/apigee/customer/application/qpidd.properties
  2. Skonfiguruj Qpidd:
    apigee-service apigee-qpidd configure
  3. Uruchom ponownie Qpidd:
    apigee-service apigee-qpidd restart
  4. Sprawdź stan za pomocą funkcji wait_for_ready:
    apigee-service apigee-qpidd wait_for_ready

Przywróć konfigurację SSL

Usuń lub zmień w komentarz właściwości z pliku /opt/apigee/customer/application/qpidd.properties:

conf_qpidd_qpid_management.https.enabled=true
conf_qpidd_qpid.keystore.storeUrl=/opt/apigee/customer/application/apigee-qpidd/keystore
  1. Skonfiguruj Qpidd:
    apigee-service apigee-qpidd configure
  2. Uruchom ponownie Qpidd:
    apigee-service apigee-qpidd restart
  3. Sprawdź stan za pomocą wait_for_ready:
    apigee-service apigee-qpidd wait_for_ready

Apache ZooKeeper

Sprawdzanie stanu ZooKeepera

  1. Sprawdź, czy proces ZooKeeper jest uruchomiony. ZooKeeper zapisuje plik PID w katalogu opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
  2. Przetestuj porty ZooKeeper, aby sprawdzić, czy możesz nawiązać połączenie TCP z portami 2181 i 3888 na każdym serwerze ZooKeeper.
  3. Sprawdź, czy możesz odczytywać 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 czteroliterowych słów ZooKeeper

ZooKeeper można monitorować za pomocą niewielkiego zestawu poleceń (czteroliterowych słów) wysyłanych do portu 2181 za pomocą narzędzi netcat (nc) lub telnet.

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 krótkie informacje o serwerze i połączonych klientach.

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

  1. Uruchom czteroliterowe polecenie ruok, aby sprawdzić, czy serwer działa w stanie bez błędu. Odpowiedź świadcząca o powodzeniu wykonania polecenia zwraca wartość „imok”.
    echo ruok | nc host 2181

    Zwraca:

    imok
  2. Uruchom polecenie składające się z 4 liter, stat, aby wyświetlić listę statystyk wydajności serwera i połączonych klientów:
    echo stat | nc host 2181

    Zwraca:

    Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-18 17:23 UTC
    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) nie jest dostępny, możesz użyć Pythona jako alternatywy. Utwórz plik o nazwie zookeeper.py z tą zawartością:
    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 kodu w Pythonie:

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

Test poziomu LDAP

Możesz monitorować SymasLDAP, aby sprawdzić, czy konkretne żądania są obsługiwane prawidłowo. Innymi słowy, sprawdź, czy konkretne wyszukiwanie zwraca prawidłowy wynik.

  1. Użyj ldapsearch (yum install symasldap-clients), aby wysłać zapytanie o wpis administratora systemu. Ten wpis służy do uwierzytelniania wszystkich wywołań interfejsu API.
    /opt/symas/bin/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

    Pojawi się prośba o podanie hasła administratora LDAP:

    Enter LDAP Password:

    Po wpisaniu hasła zobaczysz odpowiedź w formie:

    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ądzania jest nadal połączony z LDAP, używając 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 SymasLDAP, które pomagają zmniejszyć liczbę dostępów do dysku, a tym samym poprawić wydajność systemu. Monitorowanie, a następnie dostrajanie rozmiaru pamięci podręcznej na serwerze SymasLDAP może mieć duży wpływ na wydajność serwera usługi katalogowej. Aby uzyskać informacje o pamięci podręcznej, możesz wyświetlić pliki dziennika (opt/apigee/var/log).