モニタリング方法

Edge for Private Cloud v4.18.05

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

概要

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

サービス JMX:*
メモリ使用量
管理 API:
サービス チェック
管理 API:
ユーザー/組織/ デプロイ ステータス
管理 API:
axstatus
データベースのチェック apigee-service のステータス
管理サーバー
Message Processor
Postgres
Qpid
ルーター
詳細 詳細 詳細 詳細 詳細 詳細
* JMX を使用するには、JMX を有効にするの説明に従って JMX を有効にする必要があります。

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 認証はデフォルトでは有効になっていません。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 認証を有効にするで説明されているように、Cassandra を除くすべてのコンポーネントで JMX 認証を有効にできます。

JMX 認証を有効にする

JMX 認証はデフォルトでは有効になっていません。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

この例では、ポート 1099(Management Server の JMX ポート)を指定していることに注意してください。他のポートについては、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 アドレス
  • リージョンとポッド
  • <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. エラーがないかサーバーログを確認してください。ログは次の場所にあります。
    • 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
    • ルーター: 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 サーバーにオンボーディングされている組織名と環境名を確認できます。

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

PostgresSQL データベース

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

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

PostgresSQL データベースをモニタリングするには、標準のモニタリング スクリプトである 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 プロセスのヘルス ステータスを確認する

Postgres マシンで API チェックを実行するには、次の curl コマンドを実行します。

curl -v http://postgres_IP:8084/v1/servers/self/health

postgres プロセスがアクティブな場合、このコマンドは ACTIVE ステータスを返します。Postgres プロセスが稼働していない場合は、INACTIVE ステータスを返します。

Postgres リソース

Postgres サービスのモニタリングの詳細については、以下をご覧ください。

Apache Cassandra

JConsole の使用: タスク統計情報のモニタリング

JConsole と次のサービス URL を使用して、JMX 経由で提供される JMX 属性(MBeans)をモニタリングします。

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

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

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

Cassandra JMX 統計情報

JMX MBeans JMX 属性

ColumnFamilies/apprepo/environments

ColumnFamilies/apprepo/organizations

ColumnFamilies/apprepo/apiproxy_revisions

ColumnFamilies/apprepo/apiproxies

ColumnFamilies/監査/監査

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 ノードでも可能): すべてのノードで「稼働中」と「標準」を探します。
    nodetool -h localhost ring

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

    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 -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 -h localhost statusthrift

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

    running

  4. データ ストリーミング オペレーションのステータス: Cassandra ノードのトラフィックを確認します。
    nodetool -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 モニタリング(UI)

Datastax opscenter の URL(http://www.datastax.com/products/opscenter)を参照してください。

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 文字の単語を使用する

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