OCI Stack Monitoring Enterprise Editionによる充実した監視 (2023/10/31)

https://blogs.oracle.com/observability/post/enriched-stack-monitoring-enterprise-edition

投稿者： Aaron Rimel | Principal Product Manager, Observability and Management

Stack Monitoring Enterprise Editionをご紹介します。スタック・モニタリングは、Oracle E-Business Suiteなどのアプリケーションの検出と監視、およびOracle WebLogic Server、Oracle Database、ホストなどの基礎となるテクノロジ・スタック・コンポーネントをサポートするOracle Cloud Infrastructure (OCI)サービスです。Enterprise Editionでは、Stack Monitoringは、環境に固有の条件を監視するためのカスタム・メトリックの作成、機械学習を使用したパフォーマンスの異常の識別、Stack Monitoringの組込み機能以外の他のリソースへの監視の可視性の拡張など、一連の高度な監視機能を導入しています。これらの拡張性機能により、他のソリューションやサービスからリソースをインポートして、モニタリングを統合し、アプリケーション・トポロジを充実させることができます。

スタック・モニタリング・メトリック拡張による固有の要件の監視

メトリック拡張は、スタック・モニタリングによって提供される即時利用可能なメトリック・セットを拡張して、一意のIT環境を監視するときに必要なユースケースを満たします。メトリック拡張は、単一のリソースまたはコンパートメント内のすべてのリソースでメトリック拡張を作成、テスト、公開および有効化する機能を提供します。

Stack Monitoring Enterprise Editionでのメトリック拡張の作成

スタック・モニタリングでOracle Databaseを監視するDBAは、バックアップされていないデータファイルを追跡し、過去3日以内にバックアップが発生していない場合は通知する場合があります。スタック・モニタリングを使用すると、DBAはメトリック拡張を使用してこのユース・ケースに対処できます。

開始するには、スタック・モニタリングの「メトリック拡張」ページに移動し、「メトリック拡張の作成」をクリックします。次の例で、Oracle DBAは、まずメトリック拡張名、表示名および説明を定義します。次に、DBAは、コンテナDBのリソース・タイプ、SQLの収集方法、および1日に1回の収集頻度を含む収集方法のプロパティを完了します。次に、カスタムSQL問合せを入力するか、SQLを含むファイルをアップロードします。

図1のメトリック拡張は、コンテナ・データベース(CDB)を問い合せ、過去3日間にバックアップされていないPDBデータファイルの数を決定します。問合せの結果は、PDBの名前とバックアップされていないデータファイルの数という2つの列になります。メトリック拡張には、PDBの名前のディメンション列と、バックアップされていないデータファイルの数のメトリック列が含まれます。

DBAは、CDBリソースに対してメトリック拡張をテストし、出力を確認できます。出力に基づいて、メトリックを改訂する必要がある場合、DBAは問合せを更新してメトリックを再テストできます。テストが完了すると、メトリック拡張を公開する準備ができました。公開されたメトリック拡張は、一度に1つ以上のリソースで有効にできます。リソースでメトリック拡張が有効になっている場合、メトリック収集が開始され、DBAはデータファイルのバックアップ・ステータスをモニターできます。

図1: バックアップされていないデータファイルの数をカウントするメトリック拡張の作成

スタック・モニタリングでのメトリック拡張の表示

データベース・リソースでメトリック拡張が有効になっている場合、メトリックはスタック・モニタリングのホームページのパフォーマンス・チャートに自動的に表示されます。これらのパフォーマンス・チャートを使用すると、DBAはデータファイルがバックアップされていないかどうかを迅速に判断できます。メトリック拡張を示すチャートには、名前の横に"*" (アスタリスク)があります。

図2: バックアップされていないメトリック拡張データファイルを示すチャート

DBAは、データファイル・バックアップのステータスを注意深く監視できます。このメトリックをエンタープライズ・サマリーに追加すると、監視対象のすべてのデータベースでデータファイルのバックアップが発生しているかどうかを簡単に監視できます。エンタープライズ・サマリーの変更の詳細は、ドキュメントを参照してください。

メトリック拡張でのアラームの構成

メトリック拡張による監視の最後のステップは、アラームの定義です。OCI Monitoringを使用すると、DBAに待機中に通知するアラームを簡単に作成して、データファイルがバックアップされていない理由を調査できます。図3は、バックアップされていないデータファイルの数が0より大きい場合にDBAがコール時にDBAに通知するためのアラームを作成する方法を示しています。このアラームを作成する場合は、oracle_metric_extension_appmgmtネームスペースとoracle_cdbのリソース・グループを利用します。アラームの作成の詳細については、ドキュメントを参照してください。

図3: 3日以内にバックアップされないデータファイルのアラーム・ルール。

スタック・モニタリングの異常検出でパフォーマンスの問題を迅速に特定

現在のIT環境での監視は、通常、厳格なサービス・レベル合意(SLA)と結合されています。パフォーマンスの問題を特定すると、すぐに特定および解決されなければコストがかかります。ユーザーが低速を報告している場合、リソースが履歴標準外で実行されている場合、異常によって視覚的な識別が迅速に行われます。スタック・モニタリングは、機械学習を使用して、主要なパフォーマンス・メトリックのベースラインを自動的に計算します。メトリックがベースラインの外部で実行される場合、スタック・モニタリングによってこれらの値が異常としてフラグ付けされます。ベースライン対応のパフォーマンス・チャートは「+」で識別され、異常なパフォーマンスはオレンジ色のプロット・ポイントで示されます。DevOpsエンジニアは、ベースライン対応のチャートをすばやく確認し、オレンジ色のドットで示されているようにメトリックが異常であるかどうかを識別できます。その後、エンジニアはプロット・ポイントにカーソルをあわせて、次の図4に示すように、現在の異常なパフォーマンスとベースライン値の範囲を比較する方法を理解できます。

図4: 異常なCPU使用率が強調表示されているホスト

拡張性により、監視を統合し、アプリケーション・トポロジを強化

今日の複雑なIT環境では、アプリケーション・スタックはアプリケーション・サーバーやデータベース以上のものです。スタック・モニタリングの拡張機能を使用すると、スタック・モニタリングにリソースをインポートすることで、他のサービスからのモニタリングを統合できます。スタック・モニタリングにリソースをインポートすると、インポートされたリソースと既存のスタック・モニタリング・リソース間のアソシエーションを作成することで、アプリケーションのトポロジを完了できます。これにより、ロード・バランサ、アプリケーション・サーバー、データベース、ストレージなど、アプリケーション・スタック全体のすべてのリソースとその可用性およびパフォーマンス・メトリックに1箇所でアクセスできるため、トラブルシューティングの時間が短縮されます。リソースがインポートされると、Stack Monitoringは可用性メトリックとパフォーマンス・メトリック、および構成詳細を含むホーム・ページを作成し、オープン・アラームを報告します。

Load Balancerをインポートして速度を最大化し、アプリケーションの可用性を確保

ロード・バランサの監視は、ほぼすべてのアプリケーションを実行する際に重要です。ロード・バランサは、速度と容量を最大化するためにトラフィック・リクエストをルーティングします。ロード・バランサはトラフィックを振り分けて、1つのサーバーが過負荷にならないようにし、アプリケーション・サーバーが停止してもアプリケーションは使用可能なままにします。スタック・モニタリングでは、すでにE-Business Suiteアプリケーションとそのコンポーネント(コンカレント・マネージャ、Oracle Database、WebLogicなど)を監視できます。アプリケーション・トポロジを完了し、アプリケーション・スタック全体の監視を統合するには、リソースのインポート拡張機能を使用して、ロード・バランサをスタック・モニタリングにインポートします。ロード・バランサをインポートするには、リソースのインポートUIに移動し、oci_lbaasネームスペースを選択します。インポート作業リクエストが完了すると、インポートされたリソースのリストと、それぞれのホーム・ページへのリンクが提供されます。

リソース名をクリックすると、可用性およびパフォーマンス・メトリックを含むロード・バランサの新しいホームページにナビゲートします。ホーム・ページには、ロード・バランサとそれに依存するWebLogicクラスタとの間のアソシエーションを作成する機能もあります。アプリケーションのアプリケーション・トポロジを完了すると、アプリケーション・スタック間でのパフォーマンス相関が容易になり、トラブルシューティング時間を短縮できます。これらの関係は、現在のアプリケーション・トポロジを拡張して、ロード・バランサやブロック・ストレージなどのリソースを含めます。WebLogicのJDBC接続数がベースライン・パフォーマンスを下回っている場合、運用チームはアソシエーションを活用してロード・バランサのホーム・ページに移動し、パフォーマンス、構成および可用性を迅速かつ簡単に確認できます。次の図5は、PeopleSoftロード・バランサのホーム・ページとそれに依存するWebLogicクラスタを示しています。

図5: ロード・バランサのホームページには、それを使用するWebLogicクラスタが表示されています。

Stack Monitoring Enterprise Editionを有効にし、ライセンスを簡単に設定

スタック・モニタリングの魅力的な新しいEnterprise Edition機能は、ライセンスUIで有効にできます。スタック・モニタリングの「ライセンス」ページから、コンパートメント内の1つ以上のリソースでEnterprise Editionを有効にできます。ライセンスの設定を容易にするには、デフォルトのライセンスとして「Enterprise Edition」を選択します。Stack Monitoringは、リソースの検出中にライセンスを定義する機能も提供することで、ライセンスの設定を容易にします。

図6: Stack Monitoring Enterprise Edition機能の有効化

メトリック拡張を使用して独自のITニーズを監視する場合でも、アプリケーションのパフォーマンスが異常であるかを簡単に特定する場合でも、拡張性機能によって監視を統合してアプリケーション・トポロジを拡張する場合でも、Stack Monitoring Enterprise Editionは監視目標の達成に役立ちます。スタック・モニタリング・ライセンスUIに移動して、Enterprise Editionを有効にし、これらのエキサイティングな新機能を今すぐ始めましょう。ハッピーモニタリング!

リソース