モニタリング方法

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

概要

Edge では、いくつかの方法でサービスの詳細情報やステータスを確認できます。次の表に、対象のサービスで実施可能な確認の種類を示します。

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

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

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

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 を有効にするには:

  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
    • Router: /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

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

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

  • 構成のプロパティ
  • 開始時間と稼働時間
  • ビルド、RPM、UUID の情報
  • 内部 / 外部のホスト名と IP アドレス
  • リージョンとポッド
  • <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 です。

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

サーバーからすべての呼び出しに「deployed」ステータスが返されます。そうでない場合は、次の手順に従います。

  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 サービスを実行しているサーバーにログインしてそのサービスのトラブルシューティングを行うときは、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
    • Router: 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 でステータスを確認する場合は、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 をご覧ください。

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

  1. 各 Postgres ノードに check_postgres.pl スクリプトをインストールします。
  2. perl-Time-HiRes.x86_64 がインストールされていることを確認します。これは、高分解能アラーム、スリープ、gettimeofday、インターバル タイマーを実装した Perl モジュールです。たとえば、このモジュールは次のコマンドを使用してインストールできます。
    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 プロセスのヘルス ステータスを確認する

API を使用して PostgreSQL マシンの状態を確認するには、次の 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
    3. cassandra.properties ファイルを保存します。
    4. 次の例のように、ファイルの所有者を「apigee:apigee」に変更します。
      chown apigee:apigee /opt/apigee/customers/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}/lib/management/jmxremote.access ファイルを開き、次の役割を追加します。
      cassandra readwrite
    2. ファイルの所有者を「apigee」に設定し、ファイルのモードを 400 にします。
      chown apigee:apigee ${JAVA_HOME}/lib/management/jmxremote.access
          chmod 400 ${JAVA_HOME}/lib/management/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 ノードで繰り返します。

Cassandra の JMX 認証を無効にする

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

  1. /opt/apigee/customer/application/cassandra.properties をエディタで開きます。
  2. ファイルから次の行を削除します。
    conf_cassandra-env_com.sun.management.jmxremote.authenticate=true
  3. Cassandra で configure を実行します。
    /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

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 クラスタノードで実行できます。

  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. ldapsearchyum 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)から得られます。