Jak monitorować

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:

Mgmt API
Usługa Wykorzystanie pamięci [JMX*] Sprawdzanie usługi Użytkownik/organizacja/ stan wdrożenia axstatus Sprawdzanie bazy danych Stan funkcji apigee-service apigee-monit**
Serwer zarządzania
procesor komunikatów
Postgres
Qpid
Router
Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji Więcej informacji

* Jeśli chcesz używać protokołu JMX, musisz go włączyć w sposób opisany w sekcji Włączanie JMX.

** Usługa apigee-monit sprawdza, czy komponent jest aktywny. Jeśli tak nie jest, spróbuje go uruchomić ponownie. Więcej informacji znajdziesz w artykule Automatyczne naprawianie błędów za pomocą apigee-monit.

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:

Komponent Port JMX Port interfejsu API zarządzania
Serwer zarządzania 1099 8080
Router 1100 8081
procesor komunikatów 1101 8082
Qpid 1102 8083
Postgres 1103 8084

Monitoruj za pomocą 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. Dlatego musisz włączyć JMX oddzielnie dla każdego komponentu, aby móc je monitorować.

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łączanie JMX

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

Aby włączyć JMX:

  1. Zmodyfikuj plik konfiguracji komponentu. Ten plik znajduje się w folderze opt/apigee/edge-component_name/bin/start. W środowiskach produkcyjnych te pliki konfiguracji będą się znajdować na różnych maszynach.

    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, który rozpoczyna 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 konfiguracji serwera zarządzania ten kod:

    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. Uruchom ponownie 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 dla wszystkich komponentów, zgodnie z opisem w artykule Włączanie uwierzytelniania JMX. Aby włączyć uwierzytelnianie JMX w Cassandra, zapoznaj się z artykułem Włączanie uwierzytelniania JMX w Cassandra.

Włącz uwierzytelnianie JMX

Uwierzytelnianie JMX nie jest domyślnie włączone. Możesz włączyć uwierzytelnianie JMX dla wszystkich komponentów. W przypadku systemu Cassandra skorzystaj z instrukcji w artykule Włączanie uwierzytelniania JMX w 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_name change_jmx_auth [options|-f config_file]

Gdzie:

  • component jest 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 jest ustawiona lub nie jest przekazywana za pomocą funkcji -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 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ą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

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 interfejsu Management API.

Tabela poniżej zawiera ogólne statystyki JMX:

MBeanse JMX Atrybuty JMX

Pamięć

HeapMemoryUsage

NonHeapMemoryUsage

Wykorzystanie

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 opisaliśmy 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 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 jest uruchomiona, ten punkt końcowy zwraca tę odpowiedź:

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

Jeśli usługa nie działa, otrzymasz odpowiedź podobną do tej: (w zależności od usługi i sposobu jej sprawdzania):

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 podregion
  • Właściwość <isUp>, która wskazuje, czy usługa jest uruchomiona

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

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 API zarządzania dla serwera, który chcesz sprawdzić. Jest to inny port dla każdego typu komponentu. Na przykład port interfejsu API zarządzania serwerem 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 określić nagłówek Accept jako „application/json” lub „application/xml”.

W tym przykładzie uzyskujemy stan routera na localhost (port 8081):

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

W tym przykładzie uzyskujemy informacje o procesorze wiadomości o adresie 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żytkowników, organizacji i wdrożenia

Za pomocą interfejsu Management API możesz monitorować stan użytkowników, organizacji i wdrożenia serwerów proxy na serwerach zarządzania i procesorach wiadomości, uruchamiając następujące 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 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. Sprawdź dzienniki serwera pod kątem błędów. Dzienniki znajdują się tutaj:
    • 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 narzędzia 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

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 prawidłowo, używając polecenia apigee-service status, którego używałeś(-aś) wcześniej, lub interfejsu Management API zgodnie z opisem w artykule Monitorowanie za pomocą interfejsu Management API.

    Na przykład:

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

    Gdzie port_number to port interfejsu Management API usługi.

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

Monitorowanie Postgres

Postgres obsługuje kilka narzędzi, za pomocą których możesz sprawdzić jego stan. Te narzędzia są opisane w dalszych sekcjach.

Sprawdzanie organizacji i środowisk w Postgres

Aby sprawdzić nazwy organizacji i środowiska, które są używane na serwerze Postgres, możesz użyć tego polecenia 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 analityki 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 „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 opisujemy 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 alarm o wysokiej rozdzielczości, sleep, gettimeofday i interwałowe timery. Możesz na przykład zainstalować je za pomocą tego polecenia:
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: zanim zaczniesz korzystać z pliku check_postgres.pl w CentOS w wersji 7, zainstaluj perl-Data-Dumper.x86_64 RPM.

Wynik polecenia check_postgres.pl

Domyślne dane wyjściowe wywołań interfejsu API używające funkcji 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 do bazy 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 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

Sprawdzanie bazy danych

Możesz sprawdzić, czy w bazie danych PostgreSQL utworzono 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 działa, zwraca stan INACTIVE.

Zasoby Postgres

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

Apache Cassandra,

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

Włączanie uwierzytelniania JMX w Cassandra

Możesz włączyć uwierzytelnianie JMX dla systemu Cassandra. Gdy to zrobisz, we wszystkich wywołaniach narzędzia Nodetool musisz przekazywać nazwę użytkownika i hasło.

Aby włączyć uwierzytelnianie JMX w usłudze Cassandra:

  1. Utwórz i edytuj plik cassandra.properties:
    1. Edytuj 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 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 Jak skonfigurować Edge.

  2. tworzyć i edytować 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. Źródło pliku:
      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. Zmień plik jmxremote.password i dodaj nazwę użytkownika oraz hasło JMX, używając tej składni:
      JMX_USERNAME JMX_PASSWORD

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

    3. Upewnij się, że właścicielem pliku jest „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. Edytuj plik jmxremote.access i dodaj tę rolę:
      JMX_USERNAME readwrite
    3. Upewnij się, że właścicielem pliku jest „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 Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  6. Uruchom ponownie Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  7. Powtórz ten proces we wszystkich pozostałych węzłach Cassandra.

Włącz szyfrowanie hasła JMX

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

  1. Otwórz plik source/conf/casssandra-env.sh.
  2. Usuń znacznik 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 hashe SHA1 wybranych haseł, wpisując:echo -n 'Secret' | openssl dgst -sha1
  4. Ustaw hasła dla nazwy użytkownika w pliku jmxremote.password.
  5. Po aktualizacji zmień plik cassandra-env.sh z powrotem na tylko do odczytu.

Włączanie JMX z SSL w przypadku Cassandra

Włączenie JMX z SSL zapewnia dodatkową ochronę i szyfrowanie komunikacji z Cassandra opartej na JMX. Aby włączyć JMX z SSL, musisz podać klucz i certyfikat do Cassandra, aby zaakceptować połączenia JMX z SSL. Musisz też skonfigurować narzędzie nodetool (i inne narzędzia komunikujące się z Cassandra przez JMX) do SSL.

JMX z włączonym SSL obsługuje hasła JMX w postaci zwykłego tekstu i zaszyfrowane.

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

  1. Włącz JMX. W razie potrzeby włącz szyfrowanie hasła.
  2. Włącz uwierzytelnianie JMX dla Cassandra. zgodnie z opisem 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 zaufania.

    • Keystore 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.

      Hasła do magazynu kluczy i klucza powinny być takie same (domyślnie jest ono generowane podczas generowania klucza za pomocą narzędzia do obsługi kluczy).

    • Sklep z zaufanymi certyfikatami powinien zawierać tylko certyfikat i jest używany przez klientów (polecenia oparte na usłudze apigee-service lub nodetool) do nawiązywania połączeń przez JMX.

    Po potwierdzeniu spełnienia powyższych wymagań:

    1. Umieść plik magazynu kluczy w obszarze /opt/apigee/data/apigee-cassandra.
    2. Upewnij się, że plik Keystore jest czytelny tylko dla użytkownika Apigee. Aby to zrobić, wpisz:
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/keystore.node1
      chmod 400 /opt/apigee/data/apigee-cassandra/keystore.node1
  4. Aby skonfigurować Cassandra na potrzeby JMX z SSL, wykonaj te czynności:
    1. Zatrzymaj węzeł Cassandra, wpisując:
      apigee-service apigee-cassandra stop
    2. Włącz SSL w Cassandra, otwierając plik /opt/apigee/customer/application/cassandra.properties i dodając ten wiersz:
      conf_cassandra-env_com.sun.management.jmxremote.ssl=true

      Plik powinien należeć do konta apigee:apigee.

    3. Włącz konfigurację związaną z SSL w Cassandra w następujący sposób. Otwórz plik /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh i usuń komentarze z podanych niżej wierszy, zmieniając w razie potrzeby ścieżkę /opt/apigee/data/apigee-cassandra/keystore.node1 oraz 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 wykonywania poleceń apigee-service musisz ustawić określone zmienne środowiskowe, w tym:
    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 skonfigurowania apigee-service pod kątem uwierzytelniania JMX i protokołu SSL. Wybierz opcję na podstawie użyteczności i stosowanych metod zabezpieczeń.

    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 głównym użytkownika Apigee (/opt/apigee).

    $HOME/.cassandra/nodetool-ssl.properties

    Dodaj do pliku 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 trustore jest czytelny dla użytkownika Apigee.

    Uruchom to polecenie apigee-service. Jeśli działa bez błędów, 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 uruchomi się bez błędów, 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: 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. Konfigurowanie nodetool Narzędzie nodetool wymaga przekazania parametrów JMX. Istnieją 2 sposoby konfigurowania narzędzia węzłów pod kątem uruchamiania z użyciem protokołu JMX z obsługą protokołu SSL, jak opisano w poniższych opcjach konfiguracji:

    Opcje różnią się sposobem, w jaki konfiguracje związane z SSL są przekazywane do narzędzia węzłów. W obu przypadkach użytkownik korzystający z narzędzia nodetool powinien mieć uprawnienia do odczytu pliku zaufania. Wybierz odpowiednią opcję na podstawie użyteczności i stosowanych metod zabezpieczania.

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

    Opcja konfiguracji 1

    Utwórz plik w katalogu domowym użytkownika, który uruchomił 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 zaufanej pamięci podręcznej określona powyżej powinna być dostępna dla każdego użytkownika korzystającego z 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 powyżej opisanej procedurze, 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 komentarzu 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. Rozpocznij 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ą prawidłowo.
  8. Przestań używać przełącznika --ssl w nodetool

Wyłączanie uwierzytelniania JMX w Cassandra

Aby wyłączyć uwierzytelnianie JMX w usłudze Cassandra:

  1. Edytuj stronę /opt/apigee/customer/application/cassandra.properties
  2. Usuń z pliku ten wiersz:
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Uruchom konfigurowanie w Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  4. Uruchom ponownie Cassandra:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  5. Powtórz ten proces we wszystkich pozostałych węzłach 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.

Statystyki JMX Cassandra

JMX MBeans 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ą 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.

Poniższe wywołania można wykonywać we wszystkich węzłach klastra Cassandra:

  1. Ogólne informacje o pierścieniu (możliwe również w przypadku pojedynczego węzła Cassandra): poszukaj wartości „Up” i „Normal” we wszystkich węzłach.
    nodetool [-u username -pw password] -h localhost ring

    Nazwę użytkownika i hasło musisz podać tylko wtedy, gdy usługa Cassandra ma włączone uwierzytelnianie JMX.

    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łania na węzeł)
    nodetool [-u username -pw password]  -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 (obsługa klienta API)
    nodetool [-u username -pw password] -h localhost statusthrift

    Dane wyjściowe tego 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 nodetool znajdziesz w artykule Informacje o narzędziu nodetool.

Zasób Cassandra

Skorzystaj z tego adresu URL: 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 do 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 kodu 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. Innymi słowy, sprawdź, czy konkretne wyszukiwanie zwraca właściwy wynik.

  1. Aby przesłać zapytanie do wpisu administratora systemu, użyj ldapsearch (yum install openldap-clients). 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:

    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ą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 dostosowywanie rozmiaru pamięci podręcznej na serwerze OpenLDAP może mieć duży wpływ na wydajność serwera katalogów. Aby uzyskać informacje o pamięci podręcznej, możesz wyświetlić pliki dziennika (opt/apigee/var/log).