このドキュメントでは、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 認証は有効になっていません。すべてのコンポーネントで 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 は、Management Server の場合は 8080、Message Processor の場合は 8082 です。
この呼び出しを行うには、システムの管理者のユーザー名とパスワードで認証を行う必要があります。
すべての呼び出しでサーバーから「デプロイ済み」ステータスが返されるはずです。そうでない場合は、次の操作を行います。
- サーバーのログでエラーを確認します。ログは次の場所にあります。
- 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 の組織と環境を検査する
PostgreSQL サーバーにオンボーディングされている組織名と環境名を確認するには、次の 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
次の例のように、すべての分析サーバーのステータスが「SUCCESS」になっていれば問題ありません。
{ "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
スクリプトを使用する
PostgreSQL データベースのモニタリングには、標準のモニタリング スクリプトである 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 プロセスのヘルス ステータスを検査する
API を使用して PostgreSQL マシンの状態を検査するには、次の 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/cassandra.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 のリリース
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 のポートをテストします。すべての ZooKeeper サーバーのポート 2181 と 3888 への TCP 接続を確立できることを確認します。
- ZooKeeper データベースから値を読み取れることを確認します。ZooKeeper クライアント ライブラリ(
/opt/apigee/apigee-zookeeper/bin/zkCli.sh
)を使用して接続し、データベースから値を読み取ります。 - ステータスを確認します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status
ZooKeeper の 4 文字コマンドを使用する
netcat(nc)または telnet を使用してポート 2181 に 4 文字コマンド(小さなコマンドセット)を送ることで、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
)から得られます。