モニタリング方法

Edge for Private Cloud v4.19.01

このドキュメントでは、Apigee Edge のオンプレミス デプロイメントでサポートされているコンポーネントのモニタリング方法について説明します。

概要

Edge では、サービスの詳細情報の取得や、そのステータスの確認を行う複数の方法がサポートされています。次の表に、対象サービスごとに実行できるチェックの種類を示します。

Management API
サービス メモリ使用量 [JMX*] サービスの確認 ユーザー/組織/ デプロイ ステータス axstatus データベース チェック apigee-service ステータス apigee-monit**
Management Server
Message Processor
Postgres
QPD
ルーター
詳細 詳細 詳細 詳細 詳細 詳細 詳細

* JMX を使用するには、その前に JMX を有効にするの手順に沿って JMX を有効にする必要があります。

** apigee-monit サービスは、コンポーネントが起動しているかどうかを検査し、起動していない場合は再起動を試みます。詳細については、apigee-monit による自己修復をご覧ください。

JMX と Management API のモニタリング ポート

各コンポーネントは、異なるポートでの JMX と Management API のモニタリング呼び出しをサポートしています。次の表に、それぞれの種類のサーバーで使用される JMX と Management API のポートを示します。

コンポーネント JMX ポート Management API ポート
管理サーバー 1099 8080
ルーター 1100 8081
Message Processor 1101 8082
QPD 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 を有効にするには:

  1. コンポーネントの構成ファイルを編集します。このファイルは 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
    • ルーター: /opt/apigee/edge-router/bin/start

    たとえば、Management Server のサーバー上の構成ファイルは /opt/apigee/edge-management-server/bin/start にあります。

  2. コンポーネントを起動する 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
  3. 構成ファイルを保存します。
  4. 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

使用状況

Management API でモニタリングする

Edge には、サーバー上でサービス チェックを行い、ユーザー、組織、デプロイをチェックするために使用できる API がいくつか用意されています。このセクションでは、これらの API について説明します。

サービス チェックを実行する

Management API には、サービスの問題をモニタリングし、診断するためのエンドポイントがいくつか用意されています。これらのエンドポイントには、次のものがあります。

エンドポイント 説明
/servers/self/up

サービスが実行されているかどうかを確認します。この API 呼び出しでは、認証する必要はありません。

サービスが実行されている場合、このエンドポイントは次のレスポンスを返します。

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

サービスが実行されていない場合は、次のようなレスポンスが返されます（使用するサービスと確認方法によって異なります）。

curl: Failed connect to localhost:port_number; Connection refused
/servers/self

次のようなサービスに関する情報を返します。

  • 構成プロパティ
  • 開始時間と開始時間
  • ビルド、RPM、UUID 情報
  • 内部および外部のホスト名と IP アドレス
  • リージョンと Pod
  • サービスが実行されているかどうかを示す <isUp> プロパティ

この 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」として指定します。

次の例では、localhost の Router のステータス（ポート 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:password
curl 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 です。

この呼び出しを行うには、システム管理者のユーザー名とパスワードで認証を行う必要があります。

サーバーはすべての呼び出しに対して「デプロイ済み」ステータスを返します。失敗した場合は、次の手順を行います。

  1. サーバーログにエラーがないか確認します。ログは次の場所にあります。
    • Management Server: opt/apigee/var/log/edge-management-server
    • Message Processor: opt/apigee/var/log/edge-message-processor
  2. サーバーを呼び出して、正しく機能しているかどうかを確認します。
  3. サーバーを ELB から削除した後、再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service service_name restart

    ここで、service_name は次のようになります。

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

apigee-service コマンドでステータスを確認する

Edge Service のトラブルシューティングを行うには、サービスを実行しているサーバーにログインしているときに、apigee-service コマンドを使用します。

apigee-service でサービスのステータスを確認するには:

  1. サーバーにログインし、次のコマンドを実行します。 
    /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
    • ルーター: edge-router

    次に例を示します。

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor status
  2. サービスが実行されていない場合は、サービスを起動します。 
    /opt/apigee/apigee-service/bin/apigee-service service_name start
  3. サービスを再起動したら、上記の apigee-service status コマンドを使用するか、Management API でモニタリングするで説明した Management API を使用して、サービスが正常に機能していることを確認します。

    次に例を示します。

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

    port_number は、サービスの Management API ポートです。

    この例では、サーバーにログインしており、ホスト名に "localhost" を使用できることを前提としています。Management API を使用してリモートでステータスを確認するには、サーバーの IP アドレスを指定し、システム管理者のユーザー名とパスワードを API 呼び出しに含める必要があります。

Postgres のモニタリング

Postgres は、ステータスを確認するために使用できるいくつかのユーティリティをサポートしています。以降のセクションで、このユーティリティについて説明します。

Postgres の組織と環境を確認する

次の curl コマンドを実行すると、Postgres Server にオンボーディングされている組織名と環境名を確認できます。

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"
}

PostgreSQL データベース

このセクションでは、Postgres データベースのモニタリングに特に使用できる手法について説明します。

check_postgres.pl スクリプトを使用する

PostgreSQL データベースをモニタリングするには、標準のモニタリング スクリプトである check_postgres.pl を使用します。詳しくは、http://bucardo.org/wiki/Check_postgres をご覧ください。

スクリプトを実行する前に:

  1. 各 Postgres ノードに check_postgres.pl スクリプトをインストールする必要があります。
  2. 高解像度アラーム、スリープ、gettimeofday、インターバル タイマーを実装する Perl モジュールである perl-Time-HiRes.x86_64 がインストールされていることを確認します。たとえば、次のコマンドを使用してインストールできます。
    yum install perl-Time-HiRes.x86_64
  3. CentOS 7: CentOS v7 で check_postgres.pl を使用する前に、perl-Data-Dumper.x86_64 RPM をインストールします。

check_postgres.pl の出力

check_postgres.pl を使用した API 呼び出しのデフォルト出力は、Nagios と互換性があります。スクリプトをインストールしたら、以下の点を確認します。

  1. データベースのサイズを確認します。 
    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. データベースへの受信接続数を確認し、最大許容接続数と比較します。 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action backends
  3. データベースが実行中で、使用可能かどうかを確認します。 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action connection
  4. ディスク容量を確認します。 
    check_postgres.pl -H 10.176.218.202 -db apigee -u apigee -dbpass postgres -action disk_space --warning='80%' --critical='90%'
  5. 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 サービスのモニタリングの詳細については、以下をご覧ください。

Apache Cassandra

Cassandra では JMX がデフォルトで有効になっており、リモートの JMX では Cassandra へのアクセスにパスワードは必要ありません。

Cassandra の JMX 認証を有効にする

Cassandra の JMX 認証を有効にできます。その後、nodetool ユーティリティのすべての呼び出しにユーザー名とパスワードを渡す必要があります。

Cassandra の JMX 認証を有効にするには:

  1. cassandra.properties ファイルを作成して編集します。
    1. /opt/apigee/customer/application/cassandra.properties ファイルを編集します。ファイルが存在しない場合は作成します。
    2. ファイルに以下を追加します。 
      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. cassandra.properties ファイルを保存します。
    4. 次の例に示すように、ファイルの所有者を「apigee:apigee」に変更します。 
      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

    プロパティ ファイルを使用したトークンの設定について詳しくは、Edge の構成方法をご覧ください。

  2. jmx_auth.sh を作成して編集します。
    1. 次の場所にファイルを作成します（ 
      /opt/apigee/customer/application/jmx_auth.sh
      ）。
    2. ファイルに次のプロパティを追加します。 
      export CASS_JMX_USERNAME=JMX_USERNAME
export CASS_JMX_PASSWORD=JMX_PASSWORD
    3. jmx_auth.sh ファイルを保存します。
    4. ファイルのソース: 
      source /opt/apigee/customer/application/jmx_auth.sh
  3. jmxremote.password ファイルをコピーして編集します。
    1. 次のファイルを $JAVA_HOME ディレクトリから /opt/apigee/data/apigee-cassandra/ にコピーします。 
      cp ${JAVA_HOME}/lib/management/jmxremote.password.template $APIGEE_ROOT/data/apigee-cassandra/jmxremote.password
    2. jmxremote.password ファイルを編集して、次の構文を使用して JMX のユーザー名とパスワードを追加します。 
      JMX_USERNAME JMX_PASSWORD

      ここで、JMX_USERNAME と JMX_PASSWORD は、以前に設定した JMX のユーザー名とパスワードです。

    3. ファイルの所有者を「apigee」に設定し、ファイルのモードを 400 にします。 
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.password
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.password
  4. jmxremote.access ファイルをコピーして編集します。
    1. 次のファイルを $JAVA_HOME ディレクトリから /opt/apigee/data/apigee-cassandra/ にコピーします。 
      cp ${JAVA_HOME}/lib/management/jmxremote.access $APIGEE_ROOT/data/apigee-cassandra/jmxremote.access
    2. jmxremote.access ファイルを編集して、次のロールを追加します。 
      JMX_USERNAME readwrite
    3. ファイルの所有者を「apigee」に設定し、ファイルのモードを 400 にします。 
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/jmxremote.access
chmod 400 /opt/apigee/data/apigee-cassandra/jmxremote.access
  5. Cassandra で configure を実行します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  6. Cassandra を再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  7. このプロセスを他のすべての Cassandra ノードで繰り返します。

JMX のパスワード暗号化を有効にする

JMX のパスワード暗号化を有効にする手順は次のとおりです。

  1. source/conf/casssandra-env.sh ファイルを開きます。
  2. ファイル内の次の行のコメントを解除します。
    • 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. コマンドラインで「echo -n 'Secret' | openssl dgst -sha1」と入力して、目的のパスワードの SHA1 ハッシュを生成します。
  4. jmxremote.password のユーザー名に対応するパスワードを設定します。
  5. 更新後にファイル cassandra-env.sh を読み取り専用に戻します。

Cassandra の JMX 認証を無効にする

Cassandra の JMX 認証を無効にするには:

  1. /opt/apigee/customer/application/cassandra.properties を編集します。
  2. ファイルから次の行を削除します。 
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Cassandra で構成を実行します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure
  4. Cassandra を再起動します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart
  5. このプロセスを他のすべての 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_ref

保留中のタスク

メモリ列数

メモリテーブルのデータサイズ

読み取り数

最近の読み取りのレイテンシ（マイクロ秒）

合計読み取りレイテンシ マイクロ

WriteCount

最近の書き込みレイテンシのマイクロ

合計書き込みレイテンシ マイクロ

合計ディスク使用量

LiveDiskSpace が使用されている

LiveSSTableCount

BloomFilterFalsePositives

最近の BloomFilterFalseRatio

BloomFilterFalseRatio

nodetool でクラスタノードを管理する

nodetool ユーティリティは、クラスタノードを管理する Cassandra のコマンドライン インターフェースです。このユーティリティは /opt/apigee/apigee-cassandra/bin にあります。

次の呼び出しは、すべての Cassandra クラスタノードで行うことができます。

  1. 一般的なリング情報（単一の 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

  2. ノードに関する一般的な情報（ノードあたりの呼び出し） 
    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
  3. thrift サーバーのステータス（サービング クライアント API） 
    nodetool [-u username -pw password] -h localhost statusthrift

    上記のコマンドの出力は次のようになります。

    running

  4. データ ストリーミング オペレーションのステータス: 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 のステータスを確認する

  1. ZooKeeper プロセスが実行されていることを確認します。ZooKeeper が PID ファイルを opt/apigee/var/run/apigee-zookeeper/apigee-zookeeper.pid に書き込みます。
  2. ZooKeeper ポートをテストして、すべての ZooKeeper サーバーのポート 2181 および 3888 との TCP 接続を確立できることを確認します。
  3. ZooKeeper データベースから値を読み取れるようにします。ZooKeeper クライアント ライブラリ（/opt/apigee/apigee-zookeeper/bin/zkCli.sh）を使用して接続し、データベースから値を読み取ります。
  4. ステータスを確認します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

ZooKeeper の 4 文字コマンドを使用する

netcat（nc）または telnet を使用してポート 2181 に小さなコマンドセット（4 文字コマンド）を送ることで、ZooKeeper をモニタリングできます。

ZooKeeper コマンドの詳細については、Apache ZooKeeper コマンド リファレンスをご覧ください。

次に例を示します。

  • srvr: サーバーの詳細を一覧表示します。
  • stat: サーバーと接続済みクライアントの詳細情報を表示します。

ZooKeeper ポートに次のコマンドを発行できます。

  1. 4 文字のコマンド ruok を実行して、サーバーがエラー以外の状態で実行されているかどうかをテストします。成功すると、「imok」が返されます。 
    echo ruok | nc host 2181

    戻り値:

    imok
  2. 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
  3. 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 をモニタリングして、特定のリクエストが正しく処理されているかどうかを確認できます。つまり、正しい検索結果が返される特定の検索を探します。

  1. 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
  2. 次のコマンドを使用して、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）を表示して、キャッシュに関する情報を取得できます。