モニタリング方法

Edge for Private Cloud v4.18.05

このドキュメントでは、オンプレミスでサポートされているコンポーネントの監視手法について説明します。 デプロイする方法を説明します

概要

Edge では、複数の方法でサービスの詳細を取得したり、サービスを確認したりできます。 ステータスです。次の表に、対象ごとに実施できるチェックの種類を示します。 service:

サービス JMX:*
メモリ使用量		 Management API:
サービス チェック		 Management API:
ユーザー/組織/ デプロイ ステータス		 Management API:
axstatus		 データベース チェック apigee-service のステータス
Management Server
Message Processor
Postgres
Qpid
ルーター
詳細 詳細 詳細 詳細 詳細 詳細
* 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 に対してのみ有効になり、すべての 使用できます。したがって、事前にコンポーネントごとに JMX を有効にしておく必要があります。 モニタリングできます。

JMX 認証は、デフォルトでは有効になっていません。すべてのエンドポイントで JMX 認証を Cassandra 以外のコンポーネントを使用します。

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. 次の com.sun.management.jmxremote オプションを exec に追加します。 この行で次の作業を行います。 
    -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 のモニタリング ポートをご覧ください。

    たとえば、管理サーバーで JMX を有効にするには、管理サーバーに次のように追加します。 サーバーの構成ファイル:

    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 認証を有効にするを参照）が必要です。

JMX 認証を有効にする

JMX 認証は、デフォルトでは有効になっていません。すべてのエンドポイントで JMX 認証を Cassandra 以外のコンポーネントを使用します。

JMX 認証を有効にするには、すべてのサービスで次の change_jmx_auth アクションを実行します。 ノード:

/opt/apigee/apigee-service/bin/apigee-service component change_jmx_auth [options|-f config_file]

ここで

  • component は、次のいずれかです。 <ph type="x-smartling-placeholder">
      </ph>
    • edge-management-server
    • edge-message-processor
    • edge-postgres-server
    • edge-qpid-server
    • edge-router
  • options には、以下を指定します。 <ph type="x-smartling-placeholder">
      </ph>
    • -u username
    • -p password
    • -e [y|n]（有効または無効）
  • config_file には、定義する構成ファイルの場所を指定します。 次のとおりです。 <ph type="x-smartling-placeholder">
      </ph>
    • 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:

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

この例では、管理サーバーの 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 アドレスです。Google アカウントにログインしている場合 "localhost" を使用できます。それ以外の場合は、サーバーの IP アドレスも指定します。 使用します。
  • port_number は、確認するサーバーの Management API ポートです。これは、 コンポーネントのタイプごとに異なるポートを使用します。たとえば、Management Server の Management API のポートは 8080 です。使用する Management API ポート番号の一覧については、以下をご覧ください。 JMX および Management API モニタリング ポート

レスポンスの形式を変更するには、Accept ヘッダーを次のように指定します。 &quot;application/json&quot;または「application/xml」と指定します。

次の例では、localhost（ポート 8081）上の Router のステータスを取得します。

curl http://localhost:8081/v1/servers/self/up -H "Accept: application/xml"

次の例では、216.3.128.12（ポート: 216.3.128.12）にある Message Processor の情報を取得します。 8082）:

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 は、8080（管理サーバー）または 8082（メッセージ）のいずれかです。 データ処理者

この呼び出しでは、システム管理ユーザー名と あります。

サーバーは「deployed」というメッセージを返しますステータスが表示されます。失敗した場合は、次の操作を行います。

  1. エラーがないかサーバーログを確認してください。ログは次の場所にあります。 <ph type="x-smartling-placeholder">
      </ph>
    • 管理サーバー: 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. perl-Time-HiRes.x86_64 がインストールされていることを確認します。Perl モジュールとは、 高精度アラーム、スリープ、gettimeofday、インターバルタイマーを実装しています。たとえば、 次のコマンドを使用してインストールできます。
    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 を呼び出します。 command:

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

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

Postgres リソース

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

Apache Cassandra

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

JConsole と次のサービス URL を使用して、 JMX:

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

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

JMX はデフォルトで Cassandra に対して有効になっています。Cassandra へのリモート JMX アクセスには、 あります。

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 ノードでも可能）: 「上」「Normal」自動的に適用されます。 
    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 ポートをテストして、ポート 2181 とポート 2181 への TCP 接続を確立できることを確認する すべての ZooKeeper サーバーで 3888。
  3. ZooKeeper データベースから値を読み取れることを確認します。ZooKeeper を使用して接続する クライアント ライブラリ（または /opt/apigee/apigee-zookeeper/bin/zkCli.sh）を使用して値を読み取り、 取得します
  4. ステータスを確認します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper status

ZooKeeper の 4 文字の単語を使用する

ZooKeeper は、サービス アカウントに送信される少数のコマンド（4 文字の単語）を netcat（nc）または telnet を使用してポート 2181 に接続し、

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 キャッシュをモニタリングして、ディスク アクセスの回数を減らすこともできます。 システムの性能向上につながりますGoogle Cloud コンソールでキャッシュ サイズをモニタリングして OpenLDAP サーバーは、ディレクトリ サーバーのパフォーマンスに大きな影響を与える可能性があります。ログは ファイル（opt/apigee/var/log）を使用して、キャッシュに関する情報を取得します。