グローバル監視の構成¶
注釈
グローバル管理者、Monitor 管理者 (monitor_admin ロールを持つユーザー)、および対象の環境に対する Monitor 権限を持つユーザーのみが監視操作を実行できます。詳細については、「 認可 」を参照してください。
Solution Manager を使用すると、 Denodo Monitor を起動して、1 つの Virtual DataPort サーバーから、あるいはクラスタまたは環境内のすべてのサーバーから実行ログを収集できます。
次のセクションで、(環境ごとの監視の構成 とは異なる) 全般的な監視の構成の作成方法について説明します。正しく構成した後に Solution Manager で監視を起動する手順については、「 監視 」のセクションを参照してください。
Solution Manager を使用すると、全般的なログ監視構成を作成して、すべての環境のデフォルト構成を設定することができます。これを構成するには、Solution Manager Administration Tool に管理者アカウントでログインし、[Configuration] メニュー > [Monitoring configuration] の順にクリックしてください。
グローバル監視の構成メニュー¶
この構成は、 個別の監視構成 を指定していない全環境に適用されます。
このメニューセクションでは、以下の監視パラメータを構成できます。
List of active monitors: 監視対象の環境に適用するモニターのリスト。
Cloud storage appenders: 有効にすると、AWS S3 および Azure Blob ストレージにログファイルを保存できます。
JDBC appenders: 有効にすると、ログイベントを次のいずれかの DBMS に保存できます (Oracle、MySQL、PostgreSQL、DB2、および SQL Server (Microsoft または jTDS ドライバ))。
Autostart active monitors: 有効にすると、Solution Manager サーバーの起動時にアクティブなモニターが存在するのに動作していない場合、その起動を試みます。
注釈
Solution Manager の通常の再起動時は、 com.denodo.solutionmanagerserver.monitoring.stopRunningMonitorsOnShutdown プロパティが true に設定されている場合、Autostart active monitors プロパティの値に関係なく、モニターは起動されません。
ユーザーが上記のパラメータを構成するまでの間、グローバル監視の構成セクションには、テンプレートファイル ConfigurationParametersGeneral.template および ConfigurationParametersServer.template に構成されている値が表示されます。ユーザーはこれらのデフォルト値を変更することができ、変更すると、Solution Manager データベースに保持されている値が優先されます。
表示されていないその他の監視パラメータは手動で構成できます。詳細については、「 監視 」を参照してください。
クラウドストレージアペンダー¶
クラウドストレージアペンダーを構成すると、ログイベントを、AWS S3 と Azure Blob ストレージの一方または両方のクラウドストレージサービスに保存されるファイルに送信することができます。このオプションが有効であっても、ローカルログファイルは引き続き生成されることを考慮します。[Enable Cloud storage] ボタンをクリックすると、それらのストレージを有効に構成することができます。
グローバル監視の構成タブ¶
AWS S3¶
クラウドストレージオプションを有効にすると、AWS のサブタブで S3 アペンダーのパラメータを構成することができます。
グローバル監視の構成の S3 タブ¶
以下の必須フィールドに値を入力します。
Access key ID ** と **Secret access key: 組織の AWS アカウントのアクセスキー ID とシークレットアクセスキーを入力します。
詳細については、AWS のドキュメントの アクセスキー に関するページを参照してください。Solution Manager はシークレットアクセスキーを暗号化して保存します。
Region: バケットが属しているリージョン。
S3 base location URL: Solution Manager がログファイルを保存するバケットの URL (たとえば、s3://my-bucket/denodo/)。
Azure Blob¶
AWS のサブタブでは、Azure Blob ストレージアペンダーのパラメータを構成することができます。
グローバル監視の構成の Azure Blob タブ¶
以下の必須フィールドに値を入力します。
Storage account connection string: 共有キーによる認可を通じて、ストレージアカウントのデータにアクセスする権限を与えるために使用できるコネクション文字列。Solution Manager はコネクション文字列を暗号化して保存します。
Blob storage base location URL: Solution Manager がログファイルを保存するコンテナーとプレフィックスを含む Blob ストレージの URL (たとえば、https://my-storage-account.blob.core.windows.net/my-container/denodo-logs/)。
Advanced Options¶
このサブセクションでは、すべてのクラウドアペンダーに適用される全般パラメータを構成することができます。
グローバル監視の構成の高度なオプション¶
以下を構成できます。
Rotation type: ログローテーションの方法。ローテーションは、一定の時間またはログイベントのサイズで設定することができます。[Time] か [Size] のいずれかを選択します。
Time: 時間によるローテーションが有効な場合、ファイルがクラウドストレージサービスに公開されるまでの待ち時間 (分単位)。
Size: サイズによるローテーションが有効な場合、コンテンツがファイルとしてストレージサービスに公開されるまでのログイベントの数。
Compression: 有効にすると、ログファイルがストレージサービスに送信され、圧縮して保存されます。
JDBC アペンダー¶
JDBC アペンダーを構成すると、ログイベントを次のいずれかの DBMS プロバイダにあるデータベーステーブルへ送信することができます(Oracle、MySQL、PostgreSQL、DB2、SQL Server (Microsoft または jTDS ドライバ))。このオプションが有効であっても、ローカルログファイルは引き続き生成されることを考慮します。[Enable DB storage] ボタンをクリックして、データベースログストレージの詳細を構成します。
グローバル監視の構成の DB タブ¶
以下のデータを入力する必要があります。
Database: Monitor のデータベーステーブルが作成される DBMS。
Oracle
MySQL
PostgreSQL
DB2
Microsoft SQL Server (Microsoft ドライバーを使用する必要があります)
Microsoft SQL Server (jTDS ドライバー) (jTDS ドライバーを使用する必要があります)
重要
選択した DBMS に適した JDBC ドライバーは、フォルダ
<SOLUTION_MANAGER_HOME>/resources/solution-manager-monitor/denodo-monitor/libに配置してください。そうすれば、Denodo Monitor アプリケーションが JDBC 接続を確立してログイベントを保存できるようになります。また、このドライバーをフォルダ<SOLUTION_MANAGER_HOME>/lib/solution-manager-extensionsにも配置して、Solution Manager が Monitor のメタデータを自動管理できるようにします。詳細については、「 Monitor のテーブルの自動作成 」を参照してください。Driver Class: JDBC ドライバのクラス名。たとえば、Oracle の場合は
oracle.jdbc.OracleDriverです。URL: データベースサーバーへの接続に使用する JDBC URL。
Authentication type: JDBC 接続を作成するときに使用される認証タイプ。 以下の認証タイプがサポートされており、新しい依存データが必要です。
ユーザー名とパスワード。
Kerberos のユーザー名とパスワード。
Kerberos のユーザー名とキータブ。
ユーザー名とパスワード¶
認証タイプで "[User and password]" を選択すると、以下のフィールドが表示されます。
グローバル監視の構成の DB タブ: ユーザー名とパスワードによる認証¶
[User] フィールドと [Password] フィールドは、必須です。これらはデータベースに接続するための資格情報です。このユーザーアカウントには、テーブルに行を挿入する権限が必要です。パスワードは、Solution Manager により暗号化されて保存されます。
Kerberos のユーザー名とパスワード¶
グローバル監視の構成の DB タブ: Kerberos のユーザー名とパスワードによる認証¶
以下のフィールドに入力する必要があります。
Kerberos User と Kerberos Password: データベースに接続するための資格情報。このユーザーアカウントには、テーブルに行を挿入する権限が必要です。Kerberos パスワードは、Solution Manager により暗号化して保存されます。
Kerberos configuration file: (任意) Solution Manager がインストールされたホストのデフォルトの場所に配置しない場合の、krb5.conf ファイルのパス。詳細については、Kerberos の構成に関するドキュメント を参照してください。
Kerberos のユーザー名とキータブ¶
グローバル監視の構成の DB タブ: Kerberos のユーザー名とキータブによる認証¶
以下のフィールドに入力する必要があります。
Kerberos User と Keytab: データベースに接続するための資格情報。Kerberos ユーザー名は、この場合はサービスプリンシパル名となります。サービスプリンシパル名と一致するユーザーアカウントには、テーブルに行を挿入するための権限が必要です。キータブは、keytab ファイルへのパスを表し、Solution Manager により暗号化して保存されます。keytab ファイルの詳細については、 Kerberos の keytab に関するドキュメント を参照してください。
Kerberos configuration file: (任意) Solution Manager がインストールされたホストのデフォルトの場所に配置しない場合の、krb5.conf ファイルのパス。詳細については、Kerberos の構成に関するドキュメント を参照してください。
Monitor のテーブルの自動作成¶
Solution Manager を使用すると、Monitor のメタデータ (Denodo Monitor がログイベントを保存したり、Monitor の構成の一部を保存したりするために必要なテーブル) を、Monitor がサポートする DBMS 内で自動的に作成または更新することができます。
そのため、ユーザーが監視の構成を保存するときに、JDBC 構成が含まれていると、Solution Manager は Monitor がログイベントを保存するために必要なテーブルが JDBC ソースに含まれているかどうかを確認しようとします。そして、そのために、構成した接続データを使用して JDBC 接続を確立し、Monitor のメタデータ (存在する場合) の状態を確認して、実行すべきアクションを決定します。
重要
構成した DBMS に適した JDBC ドライバーをパス <SOLUTION_MANAGER_HOME>/lib/solution-manager-extensions に配置してください。そうすることで、Solution Manager が JDBC 接続を確立して、メタデータの状態を確認したり、メタデータを作成または更新したりできるようになります。この場合、JDBC 接続を確立しようとしているのは、(Denodo Monitor ではなく) Solution Manager であることに注意してください。
重要
ユーザーアカウントには、テーブルの作成、削除、変更、およびそれらのテーブルの行の挿入/更新/削除を行うための権限が必要です。
Monitor のメタデータの状態の確認の後の結果は、以下のいずれかとなります。
Empty: 構成の JDBC セクションで参照されるスキーマが、Monitor のテーブルに関しては空です。つまり、Monitor のテーブルが配置されていません。ユーザーはそのスキーマで Monitor のメタデータを作成するための権限を求められます。
Invalid: いくつかのテーブルが見つかりましたが、不整合な状態です。メタデータには、Solution Manager GA バージョンの Monnitor テーブルすら含まれていません (REQUEST_NOTIFICATION および CACHE_NOTIFICATION )。ユーザーはすべてのテーブルを再作成するための権限を求められ、Monitor に存在するテーブルのデータはすべて失われます。
Outdated: いくつかのテーブルが見つかりましたが、Monitor のメタデータのバージョンが古い状態のまま (Solution Manager の以前のアップデートで、手動または自動で作成されたもの) になっています。ユーザーはメタデータを更新するための権限を求められ、実行中の Solution Manager の古いバージョンから最新バージョンまでの変更が適用されます。
Up to date: すべてのテーブルは最新バージョンです。変更は不要です。必要な変更についてユーザーに報告されることはありません。
状態の確認後、ユーザーはメタデータの状態に応じて、JDBC ソースを変更するための権限を求められる場合があります。たとえば、Solution Manager から、Monitor のメタデータを更新するための権限を求められる場合があります。
グローバル監視の構成の DB タブ: Monitor のメタデータの更新¶
ユーザーは、ソースの変更をキャンセルして、その JDBC 構成を使用する監視を起動するときまで変更を延期することができ、その際には再度変更を求められます。ただし、その時点でユーザーが推奨されるアクションを実行しない場合、または JDBC ソースに接続されていない場合、監視は起動しません。