Oracle Enterprise Managerを使用したKubernetesでのWebLogicの監視

※ 本記事は、Yutaka Takatsuによる”Monitor WebLogic on Kubernetes using Oracle Enterprise Manager“を翻訳したものです。

Enterprise Manager Cloud Controlは、Oracle CloudのKubernetesクラスタに設定されているOracle WebLogic Serverを監視できますか?

質問への簡単な回答は「はい」です。Enterprise Manager (EMCC/EM)は、WebLogic Kubernetes Operatorによって管理されるOracle Container Engine for Kubernetes (OKE)のWebLogicサーバーを、Oracle WebLogic Management Pack Enterprise Editionライセンスに付属する即時利用可能なほとんどのメトリックで監視できます。コンテナ化されたアーキテクチャに対する認識が高まる中、DockersとKubernetesの採用に対する関心が高まり続けているため、これは過去数年間に多くのWebLogicのお客様から尋ねられた質問です。

これは、次の3つのステップで実行されます:

• ステップ1: WebLogicサーバーごとにプライベート・サブネットにKubernetesロード・バランサ・サービスを設定し、Virtual Cloud Network (VCN)内のTCP通信を許可します。
• ステップ2: Kubernetesクラスタを含む同じVCNにEMエージェントをインストールします。ここでは、エージェントをインストールするためにOracle Cloudにコンピュート・インスタンスを作成する必要があります。また、VCNにパブリック・サブネットを作成し、別のVCNで設定されているOracle Management Service (OMS)との間のトラフィックを許可するセキュリティ・ルールを構成します。
• ステップ3: EMコンソールを使用して、作成したEMエージェントを使用してロード・バランサ・サービスのIPに接続し、WebLogicドメインをリモートで検出します。

Oracle Help Centerでハンズオン・ワークショップをリリースし、ステップバイステップの手順を記載しています。これにより、一般的なアプローチを理解したり、Enterprise Managerを使用してKubernetes上でWebLogicサーバーの監視を設定した経験を積んだりしてから、自分のサイトで実行できます。次のリンクからワークショップにアクセスできます: 「Oracle Enterprise Managerを使用したKubernetes上のWebLogicサーバーのモニター」

このワークショップでは、ターゲットのWebLogicドメインがWebLogic Kubernetes Operatorによってプロビジョニングされ、OKE上のOracle Cloudにデプロイされます。WebLogic Kubernetes Operatorの詳細は、WebLogic Kubernetes Operatorのドキュメントを参照してください。

このワークショップではOKEを例として使用していますが、EMを使用してWebLogic Operatorが管理するWebLogicサーバーをモニターする場合、Azure Kubernetes Service (AKS)などの他のクラウド・プラットフォーム上のホスト・ソリューションでも、ロード・バランサ・サービスを使用するアプローチを使用できます。

背景

考えている場合、WebLogicターゲットpodにEMエージェントをインストールするだけでよいのはなぜですか? まあ、ターゲット・ホストにEMエージェントをインストールし、OMSと通信する従来の方法は、多くの理由でKubernetes環境では実用的ではありません。これは、Kubernetes podは、通常、VCNの外部との直接トラフィックが許可されていないプライベート・サブネットに存在し、OMSは双方向のネットワーク接続でエージェントと通信する必要があるためです。

EMエージェントのライフサイクルを管理する際に別の課題が表示されます。Kubernetes podは本質的に一時的なものであるため、podが失敗した場合、Kubernetesはpodの新しいレプリカを自動的に作成して操作を続行します。EMエージェントがpodに存在する場合は、podが破棄されて再生成されるたびに、インストールおよび検出プロセスを実行する必要があります。

Kubernetesロード・バランサ・サービス

このワークショップでは、Kubernetes Load Balancerサービスを使用してWebLogicドメインを検出します。この方法を使用すると、EMエージェントは、WebLogicサーバーにマップされているLoad Balancerの外部IP (プライベートIP)に接続できるため、Kubernetes podにデプロイされたWebLogicドメイン・ターゲットからモニタリング・データを収集できます。Load BalancerはクラスタIPサービスに接続し、新しいWebLogicサーバーpodに自動的に再接続するため、podの再生成時にはEMエージェントの再構成は必要ありません。

Kubernetes Load Balancerサービスの使用は、サポートされているクラウド・プラットフォームでのみ機能し、Kubernetesはプロバイダのネイティブ・ロード・バランサを活用し、構成に統合できます。

設定詳細

WebLogicドメインは、ワークショップ「OCI上のKubernetesへのWebLogicサーバーの移行」で説明されているステップに従ってOKEでプロビジョニングされ、プライベート・サブネットではWebLogic podへのアクセスが制限されます。

WebLogicサーバーとVCNのEMエージェント間の通信を可能にするために、Kubernetes Load Balancerサービスはプライベート・サブネットに設定され、各WebLogicサーバーpodに接続されました。各Load Balancerサービスには外部IP (プライベートIP)があり、同じVCNからのアクセスが許可されます。ポート(管理サーバーの場合は7001、管理対象サーバーの場合はポート8001)がロード・バランサで開かれ、WebLogicサーバー・サービスとEMエージェント間の通信がブリッジされました。

VCN内で、EMエージェント・インストール用のパブリック・サブネットに新しいコンピュート・インスタンスが作成され、Oracle Management Service (OMS)インスタンスと通信するようにファイアウォールが構成されました。OMSはEMの中心的な要素であり、Oracle Cloud内の別のVCNで実行されます。

最後に、EMエージェントがOMSからプッシュされ、エージェント・コンピュート・インスタンスにインストールされました。WebLogicドメインおよび関連ターゲットは、検出パラメータとしてLoad Balancerのポートおよび外部IPを使用して、EMコンソールのミドルウェア・ホームページから検出されました。

設定の視覚的な参照を次に示します

制限事項

EMはKubernetes Load Balancerを介してWebLogicサーバーをリモートで監視するため、いくつかの制限が存在することを認識することが重要です。たとえば、シェルスクリプトベースのメトリックまたはファイルベースのメトリックは、WebLogicターゲット・メトリックおよび構成について監視できません。これは、EMエージェントがこのモデルのターゲット・ホストに存在しないが、スクリプトまたはファイルベースのメトリックにはローカル・エージェントが必要なためです。

ただし、EMのWebLogicサーバー管理に含まれる即時利用可能なメトリックが主にJMXベースであることを考慮すると、このドキュメントで説明する方法は、例外が理解されるときに、Kubernetes上のWebLogicに対する効果的なモニタリング・ソリューションとみなされます。このモデルを使用してWebLogicを監視する場合の既知の制限事項:

• 即時利用可能なWebLogicターゲット・メトリックは、JMXベースでのみ収集されます。
• ターゲット・ホストにログオンする必要がある修正アクションはサポートされていません。
• WebLogic構成は、JMXベースでのみ収集されます。ファイルベースの構成は使用できません。例: bin/startWebLogicServer.sh あるいは config/config.xml
• OMSがターゲット・ホストにログオンする必要がある機能は使用できません。これには、WebLogicサーバーの起動と停止、パッチの自動化、プロビジョニングおよびWLSTジョブ発行が含まれます。ライフサイクル管理機能については、WebLogic Kubernetes Operatorによって提供されるオプションを使用することをお薦めします。詳細は、WebLogic Kubernetes Operatorのドキュメントを参照してください。
• OMSがWebLogic管理コンソールに直接ログオンする必要があるEM機能は使用できません。このモデルでは、エージェントはWebLogic管理サーバーにログインできますが、OMSはログインできません。機能には、ログ、JDBCデータ・ソース、システムMBeanブラウザ、および「WebLogicサーバー」→「管理」メニュー項目にリストされているオプションがあります。ただし、これらの機能を使用するには、WebLogic管理コンソールWebアプリケーションに直接ログオンできます。
• JVM Diagnostics (JVMD)は手動で設定できますが、podの再生成時には再デプロイメントが必要です。詳細は、ワークショップのチュートリアル 8を参照してください

この方法を使用すると、ほとんどのWebLogicサーバー・ターゲット・メトリックをEMでモニターできます。これらのメトリックに対するアラートを構成し、EMのモニタリング機能を使用して通知を受信できます。JVMDはパフォーマンス診断用に設定でき、限定された一連のWebLogic構成が収集されます。一方、OMSがターゲット・ホストまたはWebLogic管理コンソールにログオンする必要があるオプションはサポートされていません。

まとめ

DockerやKubernetesなどのコンテナ化された環境を新規および既存のアプリケーションのプラットフォームとして採用する開発者や企業が増えるにつれ、運用チームは、この新しい構造に対する可観測性と管理の提供に苦労しています。WebLogic Kubernetes Operatorを使用してWebLogicを管理しているユーザーの場合、その苦労は、すでに使用しているか、ビジネスのどこかにあるソリューションを使用して排除できます。

Oracle Enterprise Managerは、オンプレミス、Oracle CloudのKubernetesクラスタ、または他のクラウド・プラットフォームにデプロイされたOracle WebLogic Serverの監視ソリューションを提供するオンプレミス・ベースのソリューションです。

Oracleは、エンドツーエンド、インスタンス・レベル、トランザクション・トレース – Application Performance Monitoring(OCI – APM)を可能にする新しいクラウド・サービスも提供しています。このサービスは、前述したソリューションに対して独立して使用できます。ステップバイステップの手順については、このブログ「LiveLabsワークショップでOracle Cloud Infrastructure Application Performance Monitoringを体験する」とこのLivelab「Oracle Application Performance Monitoringを利用したKubernetes上のWebLogicには、OpenTracingを使用」を参照してください。このサービスの詳細は、Oracle Application Performance Monitoringを参照してください。