Edge for Private Cloud v4.19.01
このドキュメントでは、オンプレミス デプロイの Apigee Edge でサポートされるコンポーネントのモニタリング方法について説明します。
概要
Edge では、いくつかの方法でサービスの詳細情報やステータスを確認できます。次の表に、サポート対象のサービスで実行可能な確認方法を示します。
Management API | |||||||
サービス | メモリ使用量 [JMX*] | サービスのチェック | ユーザー / 組織 / デプロイのステータス | axstatus | データベースのチェック | apigee-service のステータス |
apigee-monit ** |
Management Server | |||||||
Message Processor | |||||||
Postgres | |||||||
Qpid | |||||||
Router | |||||||
詳細 | 詳細 | 詳細 | 詳細 | 詳細 | 詳細 | 詳細 | |
* JMX を使用する前に、JMX を有効にするの手順に沿って JMX を有効にする必要があります。 ** |
JMX と Management API のモニタリング ポート
コンポーネントごとに、JMX と Management API のモニタリング呼び出しに使用されるポートが異なります。次の表に、各サーバーで使用される JMX と Management API のポートを示します。
コンポーネント | JMX ポート | Management API ポート |
---|---|---|
Management Server | 1099 | 8080 |
Router | 1100 | 8081 |
Message Processor | 1101 | 8082 |
Qpid | 1102 | 8083 |
Postgres | 1103 | 8084 |
JMX を使用してモニタリングする
Management Server、Message Processor、Qpid、Postgres のモニタリング プロセスでは JMX を使用します。ただし、JMX がデフォルトで有効になっているのは Cassandra だけです。他の Edge コンポーネントでは、デフォルトで無効になっています。したがって、モニタリングするコンポーネントごとに JMX を有効にする必要があります。
デフォルトでは、JMX 認証は有効になっていません。すべてのコンポーネントで JMX 認証を有効にできます。Cassandra の場合は、Cassandra に対して JMX 認証を有効にするの手順を使用します。
JMX を有効にする
JMX がデフォルトで有効になっているのは Cassandra だけです。他の Edge コンポーネントでは、デフォルトで無効になっています。以下では、これらの Edge コンポーネントで JMX を有効にする方法を説明します。
JMX を有効にするには:
- コンポーネントの構成ファイルを編集します。このファイルは
opt/apigee/edge-component_name/bin/start
にあります。本番環境では、これらの構成ファイルは別のマシンに存在します。各サーバーで次の場所からファイルを選択します。
- Management Server:
/opt/apigee/edge-management-server/bin/start
- Message Processor:
/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
たとえば、Management Server の構成ファイルは、サーバーの
/opt/apigee/edge-management-server/bin/start
にあります。 - Management Server:
- コンポーネントを起動する
exec
行に次のcom.sun.management.jmxremote
オプションを追加します。-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 はサービスの JMX ポートです。サービスの JMX ポート番号については、JMX と Management API のモニタリング ポートをご覧ください。
たとえば、Management Server で JMX を有効にするには、次の行を Management Server の構成ファイルに追加します。
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
この例では、Management Server のポート番号が 1099 になっています。前述のように、ポート番号はサービスによって異なります。
編集後の構成ファイルは次のようになります。
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
- 構成ファイルを保存します。
restart
コマンドを実行して、コンポーネントを再起動します。たとえば、Management Server を再起動するには、次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
デフォルトでは、JMX の認証が有効になっていません。すべてのコンポーネントで JMX 認証を有効にできます。手順は JMX 認証を有効にするをご覧ください。Cassandra の JMX 認証を有効にする手順については、Cassandra に対して JMX 認証を有効にするをご覧ください。
JMX 認証を有効にする
デフォルトでは、JMX 認証は有効になっていません。すべてのコンポーネントで JMX 認証を有効にできます。Cassandra の場合は、Cassandra に対して JMX 認証を有効にするの手順を使用します。
JMX 認証を有効にするには、すべてのノードで次の change_jmx_auth
アクションを実行します。
/opt/apigee/apigee-service/bin/apigee-service component change_jmx_auth [options|-f config_file]
ここで:
- component は次のいずれかです。
edge-management-server
edge-message-processor
edge-postgres-server
edge-qpid-server
edge-router
- options には、次を指定します。
-u username
-p password
-e [y|n]
(有効または無効)
- config_file には、次の情報が定義されている構成ファイルの場所を指定します。
JMX_USERNAME=username
JMX_ENABLED=y|n
JMX_PASSWORD=password
(未設定または-p
で渡していない場合、プロンプトが表示されます)
コマンドライン オプションまたは構成ファイルを使用して、ユーザー名、パスワード、有効 / 無効の状態を定義します。オプションと構成ファイルのいずれかを使用してください。
次の例では、コマンドライン オプションを使用して、Management Server で JMX 認証を有効にしています。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -u foo -p bar -e y
次に例では、コマンドライン オプションではなく、構成ファイルを使用しています。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -f /tmp/my-config-file
複数のノードで Edge を実行している場合は、すべてのノードで同じユーザー名とパスワードを指定してコマンドを実行します。
コマンドラインで JMX 認証を無効にするには、次のように "-e n" オプションを使用します。
/opt/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -e n
JConsole でモニタリングする
JConsole(JMX 準拠ツール)を使用して、ヘルスチェックとプロセス統計を管理し、モニタリングします。JConsole では、サーバーによって公開されている JMX 統計情報がグラフィカル インターフェースに表示されます。詳細については、JConsole の使用をご覧ください。
JConsole では、次のサービス URL を使用して、JMX 経由で提供される JMX 属性(MBeans)をモニタリングします。
service:jmx:rmi:///jndi/rmi://IP_address:port_number/jmxrmi
ここで:
- IP_address は、モニタリングするサーバーの IP アドレスです。
- port_number は、モニタリングするサーバーの JMX ポート番号です。
たとえば、Management Server をモニタリングするには、次のようなコマンドを実行します(サーバーの IP アドレスを 216.3.128.12 としています)。
service:jmx:rmi:///jndi/rmi://216.3.128.12:1099/jmxrmi
この例では、Management Server の JMX のポート番号(1099)を使用しています。他のポートについては、JMX と Management API のモニタリング ポートをご覧ください。
次の表に、一般的な JMX 統計を示します。
JMX MBeans | JMX 属性 |
---|---|
メモリ |
HeapMemoryUsage |
NonHeapMemoryUsage |
|
Usage |
|
Management API でモニタリングする
Edge には、サーバーのサービス チェックに使用できる API があります。また、ユーザー、組織、デプロイの状況を確認できる API もあります。以下では、これらの API について説明します。
サービス チェックを実行する
Management API には、サービスのモニタリングと問題の診断に使用できるエンドポイントがいくつかあります。たとえば、次のようなエンドポイントを使用できます。
エンドポイント | 説明 |
---|---|
/servers/self/up |
サービスが実行されているかどうかを確認します。この API 呼び出しに認証は不要です。 サービスが実行中の場合、このエンドポイントは次のレスポンスを返します。 <ServerField> <Up>true</Up> </ServerField> サービスが実行されていない場合、次のようなレスポンスが返されます。確認するサービスと確認方法によって内容が異なります。 curl: Failed connect to localhost:port_number; Connection refused |
/servers/self |
サービスに関する次の情報を返します。
この API 呼び出しを行うには、Apigee 管理者の認証情報で認証を行う必要があります。 |
これらのエンドポイントを使用するには、curl
などのユーティリティで次の構文のコマンドを実行します。
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]"
ここで:
- host は、確認するサーバーの IP アドレスです。サーバーにログインしている場合は、"localhost" を使用できます。ログインしていない場合は、サーバーの IP アドレスとユーザー名、パスワードを指定します。
- port_number は、確認するサーバーの Management API ポートです。これは、コンポーネントの種類によって異なります。たとえば、Management Server の Management API ポートは 8080 です。Management API のポート番号の一覧については、JMX と Management API のモニタリング ポートをご覧ください。
レスポンスの形式を変更するには、Accept
ヘッダーに "application/json" または "application/xml" を指定します。
次の例では、Router の localhost(ポート 8081)のステータスを取得しています。
curl http://localhost:8081/v1/servers/self/up -H "Accept: application/xml"
次の例では、216.3.128.12(ポート 8082)の Message Processor の情報を取得しています。
curl http://216.3.128.12:8082/v1/servers/self -u sysAdminEmail:password -H "Accept: application/xml"
ユーザー、組織、デプロイのステータスをモニタリングする
Management API を使用して次のコマンドを実行すると、Management Server と Message Processor でプロキシのユーザー、組織、デプロイのステータスをモニタリングできます。
curl http://host:port_number/v1/users -u sysAdminEmail:passwordcurl http://host:port_number/v1/organizations -u sysAdminEmail:password
curl http://host:port_number/v1/organizations/orgname/deployments -u sysAdminEmail:password
port_number は 8080(Management Server の場合)または 8082(Message Processor の場合)です。
この呼び出しを行うには、システムの管理者のユーザー名とパスワードで認証を行う必要があります。
サーバーからすべての呼び出しに「deployed」ステータスが返されます。そうでない場合は、次の操作を行います。
- サーバーのログでエラーを確認します。ログは次の場所にあります。
- Management Server:
opt/apigee/var/log/edge-management-server
- Message Processor:
opt/apigee/var/log/edge-message-processor
- Management Server:
- サーバーを呼び出して、正常に機能しているかどうか確認します。
- サーバーを ELB から削除し、再起動します。
/opt/apigee/apigee-service/bin/apigee-service service_name restart
service_name は次のとおりです。
edge-management-server
edge-message-processor
apigee-service
コマンドでステータスを確認する
サービスを実行しているサーバーにログインしているときに、Edge サービスのトラブルシューティングを行う場合は、apigee-service
コマンドを使用します。
apigee-service
でサービスのステータスを確認するには:
- サーバーにログインして、次のコマンドを実行します。
/opt/apigee/apigee-service/bin/apigee-service service_name status
service_name は次のいずれかです。
- Management Server:
edge-management-server
- Message Processor:
edge-message-processor
- Postgres:
edge-postgres-server
- Qpid:
edge-qpid-server
- Router:
edge-router
例:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor status
- Management Server:
- サービスが実行されていない場合は、サービスを開始します。
/opt/apigee/apigee-service/bin/apigee-service service_name start
- サービスを再起動したら、前に使用した
apigee-service status
コマンドを使用するか、Management API でモニタリングするで説明した Management API を使用して、サービスが正常に機能しているかどうか確認します。例:
curl -v http://localhost:port_number/v1/servers/self/up
port_number は、サービスの Management API ポートです。
この例では、サーバーにログインしていることを前提としているため、ホスト名として "localhost" を使用しています。リモートから Management API でステータスを確認する場合は、API の呼び出しでサーバーの IP アドレスを指定し、システム管理者のユーザー名とパスワードを提供する必要があります。
Postgres のモニタリング
Postgres のステータス確認には、いくつかのユーティリティを使用できます。以下では、これらのユーティリティについて説明します。
Postgres の組織と環境を確認する
Postgres サーバーにオンボーディングされている組織名と環境名を確認するには、次の curl
コマンドを実行します。
curl -v http://postgres_IP:8084/v1/servers/self/organizations
システムに組織名と環境名が表示されます。
分析のステータスを確認する
Postgres と Qpid の分析サーバーのステータスを確認するには、次の curl
コマンドを実行します。
curl -u userEmail:password http://host:port_number/v1/organizations/orgname/environments/envname/provisioning/axstatus
次の例のように、すべての分析サーバーに成功ステータスが表示されます。
{ "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" }
PostgresSQL データベース
このセクションでは、Postgres データベースのモニタリング方法について説明します。
check_postgres.pl
スクリプトを使用する
PostgresSQL データベースをモニタリングするには、標準のモニタリング スクリプト check_postgres.pl
を使用します。詳細については、http://bucardo.org/wiki/Check_postgres をご覧ください。
スクリプトを実行する前に:
- 各 Postgres ノードに check_postgres.pl スクリプトをインストールします。
perl-Time-HiRes.x86_64
がインストールされていることを確認します。これは、高解像度のアラーム、スリープ、gettimeofday、間隔タイマーを実装する Perl モジュールです。たとえば、このモジュールをインストールするには、次のコマンドを実行します。
yum install perl-Time-HiRes.x86_64
- CentOS 7: CentOS v7 で check_postgres.pl を使用する前に、
perl-Data-Dumper.x86_64
RPM をインストールします。
check_postgres.pl の出力
デフォルトでは、check_postgres.pl
を使用した API 呼び出しの出力は Nagios 互換形式になります。スクリプトをインストールしたら、次の操作を行います。
- データベースのサイズを確認します。
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -include=apigee -action database_size --warning='800 GB' --critical='900 GB'
- データベースの受信接続数と最大許容接続数を比較します。
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends
- データベースが実行中で、使用可能な状態であることを確認します。
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection
- ディスク容量を確認します。
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'
- Postgres ノードにオンボーディングされている組織と環境の数を確認します。
check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action=custom_query --query="select count(*) as result from pg_tables where schemaname='analytics' and tablename like '%fact'" --warning='80' --critical='90' --valtype=integer
データベース チェックを実行する
PostgresSQL データベースに正しいテーブルが作成されていることを確認します。次のコマンドを使用して、PostgreSQL データベースにログインします。
psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee
次のコマンドを実行します。
\d analytics."org.env.fact"
Postgres プロセスのヘルス ステータスを確認する
Postgres マシンで API チェックを実行するには、次の curl
コマンドを呼び出します。
curl -v http://postgres_IP:8084/v1/servers/self/health
Postgres プロセスがアクティブであれば、このコマンドは ACTIVE
ステータスを返します。Postgres プロセスが実行されていない場合は、INACTIVE
ステータスを返します。
Postgres リソース
Postgres サービスのモニタリングに関する詳細については、次をご覧ください。
- http://www.postgresql.org/docs/9.0/static/monitoring.html
- http://www.postgresql.org/docs/9.0/static/diskusage.html
- http://bucardo.org/check_postgres/check_postgres.pl.html
Apache Cassandra
Cassandra では、JMX がデフォルトで有効になっています。リモートの JMX から Cassandra にアクセスする場合、パスワードは不要です。
Cassandra に対して JMX 認証を有効にする
Cassandra の JMX 認証を有効にできます。その後で、nodetool
ユーティリティのすべての呼び出しにユーザー名とパスワードを渡す必要があります。
Cassandra の JMX 認証を有効にするには:
cassandra.properties
ファイルを作成して編集します。/opt/apigee/customer/application/cassandra.properties
ファイルを編集します。ファイルが存在しない場合は作成します。- 次のプロパティをファイルに追加します。
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
cassandra.properties
ファイルを保存します。- 次の例のように、ファイルの所有者を「apigee:apigee」に変更します。
chown apigee:apigee /opt/apigee/customers/application/router.properties
プロパティ ファイルを使用したトークンの設定に関する詳細については、Edge の構成方法をご覧ください。
jmx_auth.sh
を作成して編集します。- ファイルが存在しない場合は、次の場所にファイルを作成します。
/opt/apigee/customer/application/jmx_auth.sh
- 以下のプロパティをファイルに追加します。
export CASS_JMX_USERNAME=JMX_USERNAME export CASS_JMX_PASSWORD=JMX_PASSWORD
jmx_auth.sh
ファイルを保存します。- ファイルを読み込みます。
source /opt/apigee/customer/application/jmx_auth.sh
- ファイルが存在しない場合は、次の場所にファイルを作成します。
jmxremote.password
ファイルをコピーして編集します。- 次のファイルを
$JAVA_HOME
ディレクトリから/opt/apigee/data/apigee-cassandra/
にコピーします。cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password
jmxremote.password
ファイルを編集し、次の構文を使用して JMX のユーザー名とパスワードを追加します。JMX_USERNAME JMX_PASSWORD
JMX_USERNAME と JMX_PASSWORD は、以前に設定した JMX のユーザー名とパスワードです。
- ファイルの所有者が「apigee」で、ファイルモードが 400 であることを確認します。
chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.password
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.password
- 次のファイルを
jmxremote.access
ファイルをその場で編集します。${JAVA_HOME}/lib/management/jmxremote.access
ファイルを開き、次の役割を追加します。cassandra readwrite
- ファイルの所有者が「apigee」で、ファイルモードが 400 であることを確認します。
chown apigee:apigee ${JAVA_HOME}/lib/management/jmxremote.access
chmod 400 ${JAVA_HOME}/lib/management/jmxremote.access
- Cassandra で
configure
を実行します。/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
- Cassandra を再起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
- このプロセスを他のすべての Cassandra ノードで繰り返します。
Cassandra の JMX 認証を無効にする
Cassandra の JMX 認証を無効にするには:
/opt/apigee/customer/application/cassandra.properties
を編集します。- ファイルから次の行を削除します。
conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
- Cassandra で configure を実行します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
- Cassandra を再起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
- このプロセスを他のすべての Cassandra ノードで繰り返します。
JConsole の使用: タスク統計をモニタリングする
JConsole と次のサービス URL を使用して、JMX 経由で提供される JMX 属性(MBeans)をモニタリングします。
service:jmx:rmi:///jndi/rmi://IP_address:7199/jmxrmi
IP_address は Cassandra サーバーの IP アドレスです。
Cassandra JMX の統計
JMX MBeans | JMX 属性 |
---|---|
ColumnFamilies/apprepo/environments ColumnFamilies/apprepo/organizations ColumnFamilies/apprepo/apiproxy_revisions ColumnFamilies/apprepo/apiproxies ColumnFamilies/audit/audits ColumnFamilies/audit/audits_ref |
PendingTasks |
MemtableColumnsCount |
|
MemtableDataSize |
|
ReadCount |
|
RecentReadLatencyMicros |
|
TotalReadLatencyMicros |
|
WriteCount |
|
RecentWriteLatencyMicros |
|
TotalWriteLatencyMicros |
|
TotalDiskSpaceUsed |
|
LiveDiskSpaceUsed |
|
LiveSSTableCount |
|
BloomFilterFalsePositives |
|
RecentBloomFilterFalseRatio |
|
BloomFilterFalseRatio |
nodetool でクラスタノードを管理する
nodetool
ユーティリティは、クラスタノードを管理する Cassandra のコマンドライン インターフェースです。このユーティリティは /opt/apigee/apigee-cassandra/bin
にあります。
次の呼び出しは、すべての Cassandra クラスタノードで実行できます。
- 一般的なリング情報(単一の Cassandra ノードでも可能): すべてのノードでステータスが「Up」と「Normal」になっているかどうか確認します。
nodetool [-u username -pw password] -h localhost ring
ユーザー名とパスワードを渡す必要があるのは、Cassandra の JMX 認証を有効にした場合のみです。
上記のコマンドの出力は次のようになります。
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
- ノードに関する一般情報(ノードごとの呼び出し)
nodetool [-u username -pw password] -h localhost info
上記のコマンドの出力は次のようになります。
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
- Thrift サーバーのステータス(サービスを提供するクライアントの API)
nodetool [-u username -pw password] -h localhost statusthrift
上記のコマンドの出力は次のようになります。
running
- データ ストリーミング処理のステータス: Cassandra ノードのトラフィックを確認できます。
nodetool [-u username -pw password] -h localhost netstats
上記のコマンドの出力は次のようになります。
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
nodetool
の詳細については、nodetool ユーティリティについてをご覧ください。
Cassandra のリリース
次の URL(http://www.datastax.com/docs/1.0/operations/monitoring)をご覧ください。
Apache ZooKeeper
ZooKeeper のステータスを確認する
- ZooKeeper プロセスが実行されていることを確認します。ZooKeeper は PID ファイルを
opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid
に書き込みます。 - ZooKeeper のポートでテストを行い、ポート 2181 で TCP 接続が確立し、各 ZooKeeper サーバーとポート 3888 で接続していることを確認します。
- ZooKeeper データベースの値を参照できることを確認します。ZooKeeper クライアント ライブラリ(または
/opt/apigee/apigee-zookeeper/bin/zkCli.sh
)を使用して、データベースから値を読み込みます。 - ステータスを確認します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status
ZooKeeper の 4 文字コマンドを使用する
少数のコマンドセット(4 文字コマンド)を netcat (nc) または telnet でポート 2181 に送信することで、ZooKeeper をモニタリングできます。
ZooKeeper コマンドの詳細については、Apache ZooKeeper コマンド リファレンスをご覧ください。
例:
srvr
: サーバーの詳細情報を表示します。stat
: 接続済みのクライアントとサーバーに関する概要を表示します。
次のコマンドを ZooKeeper ポートに実行します。
- 4 文字コマンドの ruok を実行して、エラーのない状態でサーバーが稼働しているかどうかを確認します。成功レスポンスであれば、"imok" が返されます。
echo ruok | nc host 2181
戻り値:
imok
- 4 文字コマンド
stat
を実行して、接続済みのクライアントの統計とサーバーのパフォーマンスを表示します。echo stat | nc host 2181
戻り値:
Zookeeper version: 3.4.5-1392090, built on 09/30/2012 17:52 GMT Clients: /0:0:0:0:0:0:0:1:33467[0](queued=0,recved=1,sent=0) /192.168.124.201:42388[1](queued=0,recved=8433,sent=8433) /192.168.124.202:42185[1](queued=0,recved=1339,sent=1347) /192.168.124.204:39296[1](queued=0,recved=7688,sent=7692) Latency min/avg/max: 0/0/128 Received: 26144 Sent: 26160 Connections: 4 Outstanding: 0 Zxid: 0x2000002c2 Mode: follower Node count: 283
- netcat (nc) が使用できない場合、代わりに python を使用します。次の情報を含むファイルを
zookeeper.py
という名前で作成します。import time, socket, sys c = socket.socket(socket.AF_INET, socket.SOCK_STREAM) c.connect((sys.argv[1], 2181)) c.send(sys.argv[2]) time.sleep(0.1) print c.recv(512)
python の次の行を実行します。
python zookeeper.py 192.168.124.201 ruok
python zookeeper.py 192.168.124.201 stat
LDAP レベルのテスト
OpenLDAP をモニタリングして、特定のリクエストが正しく提供されているかどうか確認できます。つまり、正しい結果を返す特定の検索を確認できます。
ldapsearch
(yum install openldap-clients
)を使用して、クエリでシステム管理者のエントリを取得します。このエントリはすべての API 呼び出しの認証で使用されます。ldapsearch -b "uid=admin,ou=users,ou=global,dc=apigee,dc=com" -x -W -D "cn=manager,dc=apigee,dc=com" -H ldap://localhost:10389 -LLL
LDAP 管理者のパスワードを入力するように指示されます。
Enter LDAP Password:
パスワードを入力すると、次のようなレスポンスが表示されます。
dn: uid=admin,ou=users,ou=global,dc=apigee,dc=com objectClass: organizationalPerson objectClass: person objectClass: inetOrgPerson objectClass: top uid: admin cn: admin sn: admin userPassword:: e1NTSEF9bS9xbS9RbVNXSFFtUWVsU1F0c3BGL3BQMkhObFp2eDFKUytmZVE9PQ= = mail: opdk@google.com
- 次のコマンドを実行して、Management Server が LDAP に接続しているかどうか確認します。
curl -u userEMail:password http://localhost:8080/v1/users/ADMIN
戻り値:
{ "emailId" : ADMIN, "firstName" : "admin", "lastName" : "admin" }
OpenLDAP のキャッシュもモニタリングできます。キャッシュにより、ディスクへのアクセス数が減少し、システムのパフォーマンスが向上します。OpenLDAP サーバーでキャッシュをモニタリングし、サイズを調整すると、ディレクトリ サーバーのパフォーマンスに多大な影響を及ぼす可能性があります。ログファイル(opt/apigee/var/log
)でキャッシュの情報を確認します。