モニタリング方法

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

概要

Edge では、サービスに関する詳細情報を取得したり、ステータスを確認したりするための方法がいくつかサポートされています。次の表に、対象となる各サービスで実行できるチェックの種類を示します。

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

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

  1. コンポーネントの構成ファイルを編集します。このファイルは opt/apigee/edge-component_name/bin/start にあります。本番環境では、これらの構成ファイルは異なるマシンに配置されます。

    各サーバーの次のファイルの場所から選択します。

    • 管理サーバー: /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_name 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 属性（MBean）をモニタリングします。

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 MBean 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（ポート 8081）の Router のステータスを取得します。

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. サーバーログでエラーを確認します。ログは次の場所にあります。
    • 管理サーバー: 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 コマンドでステータスを確認する

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

apigee-service を使用してサービスのステータスを確認するには:

  1. サーバーにログインして、次のコマンドを実行します。
    /opt/apigee/apigee-service/bin/apigee-service service_name status

    ここで、service_name は次のいずれかです。

    • 管理サーバー: 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 で組織と環境を確認する

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

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

データベース チェックを実行する

PostgreSQL データベースに適切なテーブルが作成されていることを確認できます。次のコマンドを使用して 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 がデフォルトで有効になっており、Cassandra へのリモート JMX アクセスにパスワードは必要ありません。

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 で SSL を使用して JMX を有効にする

SSL で JMX を有効にすると、Cassandra との JMX ベースの通信のセキュリティと暗号化が強化されます。SSL で JMX を有効にするには、Cassandra に鍵と証明書を提供して、SSL ベースの JMX 接続を受け入れる必要があります。また、SSL 用に nodetool（および JMX 経由で Cassandra と通信するその他のツール）を構成する必要もあります。

SSL 対応の JMX は、平文と暗号化された JMX パスワードの両方をサポートしています。

Cassandra で SSL を使用して JMX を有効にするには、次の操作を行います。

  1. JMX を有効にします。必要に応じてパスワードの暗号化を有効にします。
  2. Cassandra の JMX 認証を有効にします。を呼び出します。nodetool が、構成されたユーザー名とパスワードで動作していることを確認します。
    /opt/apigee/apigee-cassandra/bin/nodetool -u <JMX_USER> -pw <JMX_PASS> ring

  3. キーストアとトラストストアを準備します。

    • キーストアには鍵と証明書が含まれている必要があります。これは、Cassandra サーバーの構成に使用されます。キーストアに複数の鍵ペアが含まれている場合、Cassandra は最初の鍵ペアを使用して SSL を有効にします。

      キーストアと鍵のパスワードは同じにする必要があります（keytool を使用して鍵を生成する場合のデフォルト）。

    • トラストストアには証明書のみが含まれている必要があります。これは、クライアント（apigee-service ベースのコマンドまたは nodetool）が JMX 経由で接続するために使用されます。

    上記の要件を確認したら、次の手順を行います。

    1. キーストア ファイルを /opt/apigee/data/apigee-cassandra に配置します。
    2. キーストア ファイルが Apigee ユーザーのみが読み取り可能であることを確認するには、次のように入力します。
      chown apigee:apigee /opt/apigee/data/apigee-cassandra/keystore.node1
chmod 400 /opt/apigee/data/apigee-cassandra/keystore.node1
  4. 次の手順で、SSL を使用して JMX 用に Cassandra を構成します。
    1. 次のコマンドを入力して Cassandra ノードを停止します。
      apigee-service apigee-cassandra stop
    2. /opt/apigee/customer/application/cassandra.properties ファイルを開き、次の行を追加して、Cassandra で SSL を有効にします。
      conf_cassandra-env_com.sun.management.jmxremote.ssl=true

      ファイルのオーナーは apigee:apigee にする必要があります。

    3. Cassandra で SSL 関連の構成を次のように有効にします。/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh ファイルを開き、次の行のコメント化を解除します。必要に応じて、パス /opt/apigee/data/apigee-cassandra/keystore.node1 とキーストアのパスワードを変更します。
      JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node1"
JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keystore-password"
JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true"
       ファイルのオーナーが apigee:apigee であることを確認します。
    4. 次のコマンドを入力して Cassandra ノードを起動します。
      apigee-service apigee-cassandra start
  5. apigee-service Cassandra コマンドを構成します。apigee-service コマンドを実行する際は、以下のような特定の環境変数を設定する必要があります。
    apigee-service apigee-cassandra stop
apigee-service apigee-cassandra wait_for_ready
apigee-service apigee-cassandra ring
apigee-service apigee-cassandra backup

    JMX 認証と SSL 用に apigee-service を構成するには、いくつかのオプションがあります。ユーザビリティとセキュリティ プラクティスに基づいてオプションを選択します。

    オプション 1（SSL 引数をファイルに保存する）

    次の環境変数を設定します。

    export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y

    Apigee ユーザーのホーム ディレクトリ（/opt/apigee）にファイルを作成します。

    $HOME/.cassandra/nodetool-ssl.properties

    ファイルを編集して次の行を追加します。

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true

    Apigee ユーザーがトラストストア ファイルを読み取れることを確認します。

    次の apigee-service コマンドを実行します。エラーなしで実行された場合、構成は正しいです。

    apigee-service apigee-cassandra ring

    オプション 2（環境変数に保存された SSL 引数）

    次の環境変数を設定します。

    export CASS_JMX_USERNAME=ADMIN
# Provide encrypted password here if you have setup JMX password encryption
export CASS_JMX_PASSWORD=PASSWORD
export CASS_JMX_SSL=Y
# Ensure the truststore file is accessible by Apigee user.
export CASS_JMX_TRUSTSTORE=<path-to-trustore.node1>
export CASS_JMX_TRUSTSTORE_PASSWORD=<truststore-password>

    次の apigee-service コマンドを実行します。エラーなしで実行された場合、構成は正しいです。

    apigee-service apigee-cassandra ring

    オプション 3（SSL 引数を apigee-service に直接渡す）

    次のような apigee-service コマンドを実行します。環境変数を構成する必要はありません。

    CASS_JMX_USERNAME=ADMIN CASS_JMX_PASSWORD=PASSWORD CASS_JMX_SSL=Y CASS_JMX_TRUSTSTORE=<path-to-trustore.node1> CASS_JMX_TRUSTSTORE_PASSWORD=<trustore-password> /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra ring

  6. nodetool を設定します。Nodetool には、JMX パラメータを渡す必要があります。SSL 対応の JMX で実行するように nodetool を構成するには、次の 2 つの方法があります。

    これらのオプションは、SSL 関連の構成を nodetool に渡す方法が異なります。どちらの場合も、nodetool を実行するユーザーには、トラストストア ファイルに対する読み取り権限が必要です。ユーザビリティとセキュリティ プラクティスに基づいて、適切なオプションを選択してください。

    nodetool パラメータの詳細については、 DataStax のドキュメントをご覧ください。

    構成オプション 1

    nodetool を実行しているユーザーのホーム ディレクトリにファイルを作成します。

    $HOME/.cassandra/nodetool-ssl.properties

    このファイルに次の行を追加します。

    -Djavax.net.ssl.trustStore=<path-to-truststore.node1>
-Djavax.net.ssl.trustStorePassword=<truststore-password>
-Dcom.sun.management.jmxremote.registry.ssl=true

    上記で指定したトラストストアのパスには、nodetool を実行するすべてのユーザーがアクセスできる必要があります。

    --ssl オプションを指定して nodetool を実行します。

    /opt/apigee/apigee-cassandra/bin/nodetool --ssl -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

    構成オプション 2

    以下に示す追加のパラメータを指定して、nodetool を単一のコマンドとして実行します。

    /opt/apigee/apigee-cassandra/bin/nodetool -Djavax.net.ssl.trustStore=<path-to-truststore.node1> -Djavax.net.ssl.trustStorePassword=<truststore-password> -Dcom.sun.management.jmxremote.registry.ssl=true -Dssl.enable=true -u <jmx-user-name> -pw <jmx-user-password> -h localhost ring

SSL 構成を元に戻す

上記の手順で説明した SSL 構成を元に戻す必要がある場合は、次の手順を行います。

  1. apigee-cassandra を停止するには、次のように入力します。 
    apigee-service apigee-cassandra stop
  2. ファイル /opt/apigee/customer/application/cassandra.properties から conf_cassandra-env_com.sun.management.jmxremote.ssl=true の行を削除します。
  3. /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh の次の行をコメントアウトします。
    # JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStore=/opt/apigee/data/apigee-cassandra/keystore.node0"
# JVM_OPTS="$JVM_OPTS -Djavax.net.ssl.keyStorePassword=keypass"
# JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.registry.ssl=true”
  4. apigee-cassandra を開始するには、
    5. apigee-service apigee-cassandra start
  5. 環境変数 CASS_JMX_SSL が設定されている場合は削除します。

    unset CASS_JMX_SSL
  6. ring、stop、backup などの apigee-service ベースのコマンドが機能していることを確認します。
  7. nodetool で --ssl スイッチの使用を停止する

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 属性（MBean）をモニタリングします。

service:jmx:rmi:///jndi/rmi://IP_address:7199/jmxrmi

ここで、IP_address は Cassandra サーバーの IP です。

Cassandra JMX の統計情報

JMX MBean 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 リソース

次の URL を参照してください。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 文字の単語を使用する

ZooKeeper は、netcat（nc）または telnet を使用してポート 2181 に送信される一連の短いコマンド（4 文字の単語）でモニタリングできます。

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）を表示して、キャッシュに関する情報を取得できます。