Jak monitorować

W tym dokumencie opisano techniki monitorowania komponentów obsługiwanych przez wdrożenie lokalne Apigee Edge.

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:

Porty monitorowania interfejsu JMX i interfejsu API zarządzania

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

Monitorowanie za pomocą JMX

Procesy monitorowania serwera zarządzania, procesora komunikatów, Qpid i Postgres używają JMX. Jednak JMX jest domyślnie włączony tylko w przypadku Cassandry i domyślnie wyłączony we wszystkich innych komponentach Edge. Dlatego przed rozpoczęciem monitorowania musisz włączyć JMX osobno dla każdego komponentu.

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX dla wszystkich komponentów. W przypadku systemu Cassandra postępuj zgodnie z instrukcjami podanymi w artykule Włączanie uwierzytelniania JMX w systemie Cassandra.

Włącz 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. Edytuj plik konfiguracji komponentu. Ten plik znajduje się w lokalizacji opt/apigee/edge-component_name/bin/start. W środowiskach produkcyjnych te pliki konfiguracji będą znajdować 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 komunikatów: /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

   Na przykład plik konfiguracji serwera zarządzania na jego serwerze znajduje się w /opt/apigee/edge-management-server/bin/start.

2. Dodaj te opcje com.sun.management.jmxremote do wiersza exec, który uruchamia 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

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

   Aby na przykład włączyć JMX na serwerze zarządzania, dodaj do pliku konfiguracji serwera zarządzania te 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 dla serwera zarządzania określono port 1099. Jak wspomnieliśmy wcześniej, każda usługa ma własny numer portu.

   Zmieniony wiersz w pliku konfiguracji 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. Uruchom ponownie komponent za pomocą polecenia restart.

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

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

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX dla wszystkich komponentów, jak opisano w artykule Włączanie uwierzytelniania JMX. Aby włączyć uwierzytelnianie JMX dla systemu Cassandra, zapoznaj się z artykułem Włączanie uwierzytelniania JMX dla systemu Cassandra.

Włączanie uwierzytelniania JMX

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX dla wszystkich komponentów. W przypadku systemu Cassandra postępuj zgodnie z instrukcjami podanymi w artykule Włączanie uwierzytelniania JMX w systemie Cassandra.

Aby włączyć uwierzytelnianie JMX, wykonaj na wszystkich węzłach to działanie change_jmx_auth:

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

Gdzie:

• component to jedna z tych wartości:
  • edge-management-server
  • edge-message-processor
  • edge-postgres-server
  • edge-qpid-server
  • edge-router
• options określa te informacje:
  • -u username
  • -p password
  • -e [y|n] (włącz lub wyłącz)
• config_file określa lokalizację pliku konfiguracji, w którym definiujesz te elementy:
  • JMX_USERNAME=username
  • JMX_ENABLED=y|n
  • JMX_PASSWORD=password (jeśli nie jest ustawiony lub nie został przekazany za pomocą -p, pojawi się prośba o jego podanie)

Możesz użyć opcji wiersza poleceń lub pliku konfiguracji, aby zdefiniować nazwę użytkownika, hasło i stan włączenia/wyłączenia. Nie podawaj jednocześnie zestawu opcji i pliku konfiguracji.

W tym przykładzie włączamy 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 użyto pliku konfiguracji zamiast opcji wiersza poleceń:

/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 polecenie na wszystkich węzłach, podając tę samą nazwę użytkownika i hasło.

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

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 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ć.

Na przykład, aby monitorować serwer zarządzania, 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

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 interfejsu API zarządzania.

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

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ługi

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ą:

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

curl: Failed connect to localhost:port_number; Connection refused

Aby użyć tych punktów końcowych, wywołaj narzędzie takie jak curl za pomocą poleceń o 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 zalogujesz się 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 to:

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

Sprawdź stan za pomocą polecenia apigee-service

Możesz rozwiązać problemy z usługami Edge, używając 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 jest uruchomiona, 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ładamy, ż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 opisano 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 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"

Sprawdź stan 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:

• 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

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 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}/data/apigee-cassandra/jmxremote.password
      conf_cassandra-env_com.sun.management.jmxremote.access.file=${APIGEE_ROOT}/data/apigee-cassandra/jmxremote.access

   3. Zapisz plik cassandra.properties.
   4. Zmień właściciela pliku na apigee:apigee, jak 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/data/apigee-cassandra/:

      cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password

   2. Zmodyfikuj plik jmxremote.password i dodaj nazwę użytkownika oraz hasło JMX, używając tej składni:

      JMX_USERNAME JMX_PASSWORD

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

   3. Upewnij się, że plik należy do „apigee” i że tryb pliku to 400:

      chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.password
      chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.password

4. Skopiuj i edytuj plik jmxremote.access:
   1. Skopiuj ten plik z katalogu $JAVA_HOME do /opt/apigee/data/apigee-cassandra/:

      cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/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/data/apigee-cassandra/jmxremote.access
      chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.access

5. Uruchom configure 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łącz szyfrowanie haseł JMX

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

1. Otwórz plik source/conf/casssandra-env.sh.
2. Usuń znaczniki komentarza z tych wierszy w pliku:
   • JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config={T}conf_cassandra-env_java.security.auth.login.config{/T}"
   • JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.login.config=ApigeeSecureFileLoginModule"
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 jmxremote.password.
5. Po aktualizacji zmień uprawnienia do pliku cassandra-env.sh z powrotem na tylko do odczytu.

Włączanie JMX z SSL dla 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 dla Cassandra, aby akceptować połączenia JMX oparte na SSL. Musisz też skonfigurować nodetool (i inne narzędzia, które komunikują się z Cassandrą przez 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. jak opisano powyżej. Sprawdź, czy narzędzie nodetool działa ze skonfigurowaną nazwą użytkownika i hasłem.

   /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 oraz 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/data/apigee-cassandra.
   2. Upewnij się, że plik magazynu kluczy jest dostępny tylko dla użytkownika Apigee, wpisując:

      chown apigee:apigee /opt/apigee/data/apigee-cassandra/keystore.node1
      chmod 400 /opt/apigee/data/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 ten wiersz:

      conf_cassandra-env_com.sun.management.jmxremote.ssl=true

      Właścicielem pliku powinien być apigee:apigee.

   3. Włącz konfigurację związaną z SSL w systemie Cassandra w następujący sposób. Otwórz plik /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh i usuń znaczniki komentarza z tych wierszy, zmieniając w razie potrzeby ścieżkę /opt/apigee/data/apigee-cassandra/keystore.node1 i hasło do magazynu kluczy.

      JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node1"
      JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keystore-password"
      JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true"

      Upewnij się, że właścicielem pliku jest apigee:apigee.
   4. Uruchom węzeł Cassandra, wpisując:

      apigee-service apigee-cassandra start

5. Skonfiguruj polecenia Cassandra apigee-service. Podczas uruchamiania poleceń apigee-service musisz ustawić pewne 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)
   • Opcja 2 (argumenty SSL przechowywane w zmiennych środowiskowych)
   • Opcja 3 (argumenty SSL przekazywane bezpośrednio do apigee-service)

   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

   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>

   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. takie jak 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> /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:

   • Opcja konfiguracji 1
   • Opcja konfiguracji 2

   Opcje różnią się sposobem przekazywania konfiguracji związanych z SSL do narzędzia nodetool. W obu przypadkach użytkownik uruchamiający nodetool powinien mieć uprawnienia do ODCZYTU pliku magazynu zaufanych certyfikatów. Wybierz odpowiednią opcję na podstawie użyteczności i praktyk dotyczących bezpieczeństwa.

   Więcej informacji o parametrach nodetool znajdziesz w dokumentacji DataStax.

   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

   Ścieżka magazynu zaufanych certyfikatów określona powyżej powinna być dostępna dla każdego użytkownika korzystającego z narzędzia 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 -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

apigee-service apigee-cassandra start

5. Usuń zmienną środowiskową CASS_JMX_SSL, jeśli została ustawiona.

   unset CASS_JMX_SSL

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

Wyłączanie uwierzytelniania JMX w Cassandra

Aby wyłączyć uwierzytelnianie JMX w 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ń

Użyj JConsole i poniższego adresu URL usługi, aby monitorować atrybuty JMX (MBeans) oferowane przez JMX:

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

gdzie IP_address to adres IP serwera Cassandra.

Statystyki JMX Cassandra

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

Narzędzie nodetool to interfejs wiersza poleceń dla 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

   Dane wyjściowe powyższego polecenia wyglądają 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 strumieniowego przesyłania danych: obserwuj ruch w 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 nodetool znajdziesz w artykule Informacje o narzędziu nodetool.

Zasób Cassandra

Zapoznaj się z informacjami pod tym adresem URL: http://www.datastax.com/docs/1.0/operations/monitoring.

Apache ZooKeeper

Sprawdzanie stanu ZooKeepera

1. Sprawdź, czy proces ZooKeeper jest uruchomiony. ZooKeeper zapisuje plik PID w opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid.
2. Przetestuj porty ZooKeeper, aby upewnić się, że 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), które są wysyłane do portu 2181 przy użyciu netcat (nc) lub telnetu.

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

Na przykład:

• srvr: wyświetla 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 to „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.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. 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 na poziomie LDAP

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

1. Użyj ldapsearch (yum install openldap-clients), aby wysłać zapytanie o wpis 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

   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 OpenLDAP, które pomagają zmniejszyć liczbę dostępów do dysku, a tym samym poprawić wydajność systemu. Monitorowanie, a następnie dostosowywanie rozmiaru pamięci podręcznej na serwerze OpenLDAP 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).