Edge for Private Cloud v4.16.09
このドキュメントでは、Apigee Edge のオンプレミス デプロイメントでサポートされているコンポーネントのモニタリング方法について説明します。
JMX の有効化
JMX は Cassandra ではデフォルトで有効になっており、他のすべての Edge コンポーネントではデフォルトで無効になっています。したがって、JMX をコンポーネントごとに有効にする必要があります。
各コンポーネントは異なるポートで JMX をサポートします。次の表に、JMX ポートと、そのポートで JMX を有効にするように変更するファイルを示します。
コンポーネント | JMX ポート | File |
---|---|---|
管理サーバー | 1099 | /opt/apigee/edge-management-server/bin/start |
Message Processor | 1101 | /opt/apigee/edge-mesage-processor/bin/start |
QPD | 1102 | /opt/apigee/edge-qpid-server/bin/start |
Postgres | 1103 | /opt/apigee/edge-postgres-server/bin/start |
たとえば、Management Server で JMX を有効にするには、エディタで /opt/apigee/edge-management-server/bin/start を開きます。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 $* $debug_options com.apigee.kernel.MicroKernel
この行を編集して、以下を追加します。
-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
この行では、Management Server の JMX ポート番号を 1099 に指定しています。上記の表で定義されているように、各コンポーネントのポート番号を設定します。次に例を示します。
exec $JAVA -classpath "$classpath" -Xms$min_mem -Xmx$max_mem $xx_opts -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 -Djava.security.auth.login.config=$conf_path/jaas.config -Dinstallation.dir=$install_dir $sys_props -Dconf.dir=$conf_path -Ddata.dir=$data_dir $* $debug_options com.apigee.kernel.MicroKernel
ファイルを保存してから、コンポーネントを再起動します。たとえば、Management Server を再起動するには、次のコマンドを実行します。
> /opt/apigee/apigee-service/bin/ apigee-service edge-management-server restart
JMX 認証を有効にして JMX パスワードを設定する
Management Server、Message Processor、Qpid、Postgres のモニタリング プロセスでは JMX が使用されます。JMX はデフォルトで有効になっており、リモートの JMX アクセスではパスワードは必要ありません。
JMX 認証を有効にするために、各コンポーネントには認証の有効化と無効化、および JMX 認証情報の設定に使用する change_jmx_auth アクションがあります。
JMX 認証を有効にするには、次のコマンドを使用します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service comp change_jmx_auth optionsOrConfigFile
ここで
- comp は、edge-management-server、edge-message-processor、edge-qpid-server、または edge-postgres-server のいずれかです。
- 以下のオプションがあります。
- -u: ユーザー名
- -p: パスワード
- -e: y(有効化)または n(可変)
- 構成ファイルには次の内容が含まれています。
- JMX_USERNAME=ユーザー名
- JMX_ENABLED=y/n
- (JMX_PASSWORD=パスワード)-(-p で設定しないか渡さない場合、プロンプトが表示されます)
たとえば、コマンドラインでオプションを使用するには、次のようにします。
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -u foo -p bar -e y
構成ファイルがある場合:
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -f configFile
複数のノードで Edge を実行している場合は、すべてのノードで同じユーザー名とパスワードを指定してこのコマンドを実行します。
後で JMX 認証を無効にするには、次のコマンドを使用します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server change_jmx_auth -e n
管理サーバー
JConsole を使用してシステムのヘルスチェックとプロセス情報をモニタリングする
JConsole(JMX 準拠ツール)を使用して、ヘルスチェックとプロセス統計を管理し、モニタリングします。JConsole を使用すると、Management Server(または任意のサーバー)によって公開された JMX 統計情報をグラフィカル インターフェースで使用できます。JConsole の使用の詳細については、http://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html をご覧ください。
JConsole と次のサービス URL を使用して、JMX 経由で提供される JMX 属性(MBeans)をモニタリングします。
service:jmx:rmi:///jndi/rmi://<ip address>:<port>/platform
ここで、<ip address> は Management Server(またはそれぞれのサーバー)の IP アドレスです。デフォルトでは、Management Server のポートは 1099 です。
次の表に、一般的な JMX の統計情報を示します。
JMX MBeans |
JMX 属性 |
---|---|
メモリ |
HeapMemoryUsage |
NonHeapMemoryUsage |
|
使用状況 |
|
注: 属性値は、commit、init、max、used の 4 つの値で表示されます。 |
Edge Application API チェックを使用する
Management Server(または任意のサーバー)で API チェックを行うには、次の CURL コマンドを実行します。
curl http://<host>:8080/v1/servers/self/up
ここで、<host> は Management Server の IP アドレスです。
この呼び出しは、「true」と「false」を返します。true の場合、ノードは稼働しており、Java サービスが実行されています。
HTTP 200(OK)レスポンスを受信しない場合、Edge はポート 8080 リクエストに応答できません。
トラブルシューティング
- サーバーにログインして、次のコマンドを実行します。
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server status - サービスが実行されていない場合は、サービスを起動します。
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server start
Edge アプリケーションの使用 - ユーザー、組織、デプロイに関するチェック
Management Server は、オンプレミスの各インストールで他のすべてのパッケージを接続する際に重要な役割を果たします。Management Server でユーザー、組織、デプロイのステータスを確認するには、次のコマンドを実行します。
curl -u userEmail:password http://localhost:8080/v1/users curl -u userEmail:password http://localhost:8080/v1/organizations curl -u userEmail:password http://localhost:8080/v1/organizations/orgname/deployments
すべての呼び出しに対して「デプロイ済み」ステータスが表示されます。失敗した場合は、次の操作を行います。
- Management Server のログ(<inst_root>/apigee/var/log/edge-management-server)でエラーを確認します。
- Management Server に対して呼び出しを行い、適切に機能しているかどうかを確認します。
- サーバーを ELB から削除した後、Management Server を再起動します。
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-management-server restart
ルーター
次の CURL コマンドを呼び出すと、Router(または任意のサーバー)で API チェックを実行できます。
curl http://<host>:8081/v1/servers/self/up
ここで、host は Router の IP アドレスです。
この呼び出しは、「true」と「false」を返します。true の場合、ノードは稼働しており、Router サービスは実行中です。
HTTP 200(OK)レスポンスを受信しない場合、Edge はポート 8081 リクエストに応答できません。
トラブルシューティング
- サーバーにログインして、次のコマンドを実行します。
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-router status - サービスが実行されていない場合は、サービスを起動します。
/<inst_root>/apigee/apigee-service/bin/apigee-service edge-router start - 再起動後、機能していることを確認します。
curl -v http://localhost:port/v1/servers/self/up
ここで、port は Router の場合は 8081、Message Processor の場合は 8082 です。
Message Processor
JConsole を使用してシステムのヘルスチェックとプロセス情報をモニタリングする
前述の Management Server と同じ手順を行います。
注: 必ずポート 1101 を使用してください。
Edge Application API チェックを使用する
Router については、上記と同じ手順を行います。
注: 必ずポート 8082 を使用してください。
JMX メッセージ フロー チェックの使用
前述の Management Server と同じ手順を行います。
注: 必ずポート 1101 を使用してください。
Qpid Server
JConsole を使用してシステムのヘルスチェックとプロセス情報をモニタリングする
前述の Management Server と同じ手順を行います。
注: 必ずポート 1102 を使用してください。
Edge Application API チェックを使用する
前述の Management Server と同じ手順を行います。
注: 必ずポート 8083 を使用してください。Qpid Server では、次の CURL コマンドも使用できます。
curl http://<qpid_IP>:8083/v1/servers/self
Postgres Server
JConsole を使用してシステムのヘルスチェックとプロセス情報をモニタリングする
前述の Management Server と同じ手順を行います。
注: 必ずポート 1103 を使用してください。
Edge Application API チェックを使用する
前述の Management Server と同じ手順を行います。
注: 必ずポート 8084 を使用してください。Postgres Server では、次の CURL コマンドもサポートされます。
curl http://<postgres_IP>:8084/v1/servers/self
Edge アプリケーションの組織チェックと環境チェックを使用する
Postgres Server にオンボーディングされている組織名と環境名を確認するには、次の CURL コマンドを実行します。
curl http:// <postgres_IP>:8084/v1/servers/self/organizations
注: 必ずポート 8084 を使用してください。
組織と環境の名前が表示されます。
Edge アプリケーションの axstatus チェックの使用
次の CURL コマンドを実行して、分析サーバーのステータスを確認できます。
curl -u userEmail:password http://<host>:<port>/v1/organizations/<orgname>/environments/<envname>/provisioning/axstatus
すべての分析サーバーに SUCCESS ステータスが表示されます。上記の CURL コマンドの出力を以下に示します。
{ "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" }
PostgreSQL データベース
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
このスクリプトを使用した API 呼び出しのデフォルト出力 check_postgres.pl は 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 backend - データベースの可用性とパフォーマンス - データベースが実行中で使用可能かどうかを確認します。
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 -actiondisk_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(*) with pg_tables from 'namename'act--=' 'Q%E'
注: 上記のコマンドの使用についてヘルプが必要な場合は、http://bucardo.org/check_postgres/check_postgres.pl.html をご覧ください。
DB チェック
適切なテーブルが PostgresSQL データベースに作成されていることを確認します。次のコマンドを使用して PostgreSQL データベースにログインします。
psql -h /opt/apigee/var/run/apigee-postgresql/ -U apigee -d apigee
次のコマンドを実行します。
\d analytics."<org>.<env>.fact"
postgres プロセスのヘルス ステータスを確認する
次の CURL コマンドを実行して、postgres マシンで API チェックを実行できます。
http://<postgres_IP>:8084/v1/servers/self/health/
注: 必ずポート 8084 を使用してください。
postgres プロセスがアクティブになると、ACTIVE ステータスが返されます。postgres プロセスが稼働していない場合は、ステータス「INACTIVE」が返されます。
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
JConsole の使用 - タスク統計をモニタリングする
JConsole と次のサービス URL を使用して、JMX 経由で提供される JMX 属性(MBeans)をモニタリングします。
service:jmx:rmi:///jndi/rmi://<ip address>:7199/jmxrmi
<ip address> は Cassandra サーバーの IP です。
Cassandra では JMX がデフォルトで有効になっており、リモートの JMX では Cassandra へのアクセスにパスワードは必要ありません。
JMX 認証を有効にしてパスワードを追加するには:
- /<inst_root>/apigee/customer/application/cassandra.properties を編集します。ファイルが存在しない場合は作成します。
- 次のファイルを追加します。
conf_cassandra-env_com.sun.management.jmxremote.authentication=true - ファイルを保存します。
- $JAVA_HOME ディレクトリ内にある以下のファイルを /<inst_root>/apigee/data/apigee-cassandra/ にコピーします。
cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password
cp ${libG_HOME} - jmxremote.password を編集し、ファイルにユーザー名とパスワードを追加します。
cassandra password
ここで、password は JMX のパスワードです。 - jmxremote.access を編集して、次のロールを追加します。
cassandra readwrite - ファイルの所有者を「apigee」に設定し、ファイルのモードを 400 にします。
> chown apigee:apigee /<inst_root>/apigee/data/apigee-cassandra/jmxremote.*
> chmod 400 /<inst_root>/apigee/data/apigee-cassandra/jmxremote.* - Cassandra で configure を実行します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Cassandra を再起動します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
後で認証を無効にするには:
- /<inst_root>/apigee/customer/application/cassandra.properties を編集します。
- ファイルから次の行を削除します。
conf_cassandra-env_com.sun.management.jmxremote.authentication=true - Cassandra で configure を実行します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra configure - Cassandra を再起動します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
Cassandra JMX の統計
JMX MBeans |
JMX 属性 |
---|---|
ColumnFamilies/apprepo/environments ColumnFamilies/apprepo/organizations ColumnFamilies/apprepo/apiproxy_revisions ColumnFamilies/apprepo/apiproxies 列ファミリー/監査/監査 ColumnFamilies/audit/audits_ref |
保留中のタスク |
メモリ列数 |
|
メモリテーブルのデータサイズ |
|
読み取り数 |
|
最近の読み取りのレイテンシ(マイクロ秒) |
|
合計読み取りレイテンシ マイクロ |
|
WriteCount |
|
最近の書き込みレイテンシのマイクロ |
|
合計書き込みレイテンシ マイクロ |
|
合計ディスク使用量 |
|
LiveDiskSpace が使用されている |
|
LiveSSTableCount |
|
BloomFilterFalsePositives |
|
最近の BloomFilterFalseRatio |
|
BloomFilterFalseRatio |
nodetool ユーティリティを使用してクラスタノードを管理する
クラスタツールの管理には、Cassandra のコマンドライン インターフェースである nodetool ユーティリティを使用します。このユーティリティは <inst_root>/apigee/apigee-cassandra/bin にあります。
nodetool ユーティリティの詳細については、http://www.datastax.com/docs/1.0/references/nodetool をご覧ください。
次の呼び出しは、すべての Cassandra クラスタノードで行うことができます。
- 一般的なリング情報(単一の Cassandra ノードでも可能): すべてのノードで「Up」と「Normal」を探します。
[host]# nodetool -h44
4 - ノードに関する一般的な情報(ノードあたりの呼び出し)
nodetool -h localhost info
上記のコマンドの出力は、次のようになります。
Token : 0
Gossip active : true
Load: 1.67 MB
Generation No : 1361968765
Uptime - thrift サーバーのステータス(サービング クライアント API)
host]# nodetool -h localhost statusthrift
上記のコマンドの出力には、「running」というステータスが表示されます。 - データ ストリーミング オペレーションのステータス: cassandra ノードのトラフィックを監視する
nodetool -h localhost netstats 192.168.124.203
上記のコマンドの出力は次のようになります。
モード: NORMAL
/192.162.162.162.122.222.22.22.22.22.124.22.22.124.22.22.22.124.22.124.22.22.124.22.124.22.22.124.22.22.124.22.22.22.22.128 から 202.168.26.22.22 にレスポンスがあります。
Cassandra Monitoring(UI)
datastax opscenter の URL(http://www.datastax.com/products/opscenter)を参照してください。
Cassandra のリソース
http://www.datastax.com/docs/1.0/operations/monitoring をご覧ください。
Apache ZooKeeper
ZooKeeper のステータスの確認
- ZooKeeper プロセスが実行されていることを確認します。ZooKeeper が PID ファイルを <inst_root>/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid に書き込みます。
- ZooKeeper ポートをテストして、すべての ZooKeeper サーバーのポート 2181 および 3888 との TCP 接続を確立できることを確認します。
- ZooKeeper データベースから値を読み取れるようにします。ZooKeeper クライアント ライブラリ(または /<inst_root>/apigee/apigee-zookeeper/bin/zkCli.sh)を使用して接続し、データベースから値を読み取ります。
- ステータスを確認します。
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-zookeeper status
ZooKeeper の 4 文字の使用
netcat(nc)または telnet を使用してポート 2181 に小さなコマンドセット(4 文字コマンド)を送ることで、ZooKeeper をモニタリングできます。
ZooKeeper コマンドの詳細については、http://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_zkCommands をご覧ください。
次に例を示します。
- srvr: サーバーの詳細を一覧表示します。
- stat: サーバーと接続されたクライアントの簡単な詳細を一覧表示します。
ZooKeeper ポートに次のコマンドを発行できます。
- 4 文字のコマンド ruok を実行して、サーバーがエラー以外の状態で実行されているかどうかをテストします。成功すると、「imok」が返されます。
echo ruok | nc <host> 2181
戻り値:
imok - 4 文字コマンド stat を使用して、サーバーのパフォーマンスと接続済みのクライアントの統計情報を一覧表示します。
- netcat(nc)を使用できない場合は、代わりに python を使用できます。zookeeper.py というファイルを作成し、次の内容を含めます。
import time, socket,
sys c = socket.socket(socket.AF_INET, 書か?
OpenLDAP
LDAP レベルのテスト
OpenLDAP をモニタリングして、特定のリクエストが正しく処理されているかどうかを確認できます。つまり、正しい検索結果が返される特定の検索を探します。
- ldapsearch(yum install openldap-clients)を使用してシステム管理者のエントリをクエリします。このエントリは、すべての API 呼び出しの認証に使用されます。
- Management Server が LDAP の問題にまだ接続していないことを確認します。
curl -u <userEMail>:<password> http://localhost:8080/v1/users/<ADMIN>
戻り値:
{
"emailId" : <ADMIN>,
"firstName" :
" "lastName" : "
また、OpenLDAP キャッシュをモニタリングしてディスク アクセスの数を減らすと、システムのパフォーマンスを改善できます。OpenLDAP サーバーのキャッシュ サイズのモニタリングと調整は、ディレクトリ サーバーのパフォーマンスに大きな影響を与える可能性があります。ログファイル(<inst_root>/apigee/var/log)を表示して、キャッシュに関する情報を取得できます。