Red Hat Training
A Red Hat training course is available for Red Hat JBoss Operations Network
JBoss Operations Network を使用したリソースの監視、デプロイ、および管理
有効な JBoss および IT インフラストラクチャーを維持するための推奨事項および手順
概要
第1章 JBoss ON Web インターフェースの使用
1.1. サポートされる Web ブラウザー
- Firefox 17 以降
- Internet Explorer 9
1.2. JBoss ON Web UI へのログイン
rhq-server.properties
ファイルのマイナー設定以外に、JBoss ON はその Web インターフェースを介して完全に管理されます。
http://server.example.com:7080
図1.1 JBoss ON へのログイン
1.3. Internet Explorer の設定
- Internet Explorer で、右上隅の歯車アイコンをクリックして選択し Internet optionsます。
- Security タブを開き、Local intranet アイコンを選択します。
- Sites ボタンをクリックします。
- ポップアップウィンドウの下部にある Advanced ボタンをクリックします。
- Add this webiste to the zone: フィールドに JBoss ON サーバーのホスト名または IP アドレスを入力し、をクリックし Addます。
- オプションウィンドウを閉じます。
1.4. ハイレベルックスロー
- トップメニュー
- 左側のメニューテーブル
- ダッシュボード
- リソースインベントリー、サマリーレポート、検索の結果などのリソースベースのテーブル
- リソース、グループ、プラグイン、JBoss ON のサーバー設定など、JBoss ON の要素の詳細とアクセスの両方を提供する設定ページ
図1.2 UI 要素すべて
1.4.1. トップメニュー
図1.3 トップメニュー
- Dashboard には、JBoss ON およびそのリソースに関するグローバル概要が含まれます。異なる設定可能なスナップショットの要約( ポートレットと呼ばれる)は、検出キュー、最近のアラート、最近の操作、リソース数など、リソースとサーバーのさまざまな側面を示しています。
- Inventory タブには、リソースとグループの両方が表示されます。
- Report タブには、事前定義済みのレポートが表示されます。これらはリソース情報のみにフォーカスする Dashboard と若干異なります。レポートは、アラート、操作、メトリクスコレクション、設定履歴などの JBoss ON のサブシステム(または主要な機能領域)の現在のアクションに重点を置いています。
- Bundles タブは、プロビジョニングおよびコンテンツ機能エリアを開きます。これは、新規アプリケーションのプロビジョニングに使用されるコンテンツバンドルのアップロードおよびデプロイに使用されます。
- 管理は、JBoss ON サーバー自体の設定に関連するすべてのエリアに送信されます。これには、サーバー設定、プラグイン、ユーザーおよびセキュリティー、エージェント設定が含まれます。
1.4.2. 左側のメニュー
図1.4 左側のメニュー
図1.5 左側のメニューの折りたたみ
1.4.3. Dashboard
図1.6 ダッシュボードビュー
1.4.4. インベントリーブラウザーおよびサマリー
- タブ、さまざまなエリア、詳細情報のサブタブ
- 結果の表
- 特定エンティティーの設定またはタスクオプションを開くアイコン
- エントリーでアクションを実行するボタン(作成、削除、またはその他の特定のアクション)。エントリーが選択されていなければ、これらのボタンの一部がアクティブにならない
図1.7 インベントリーブラウザー
1.4.5. エントリーの詳細ページ
図1.8 リソースツリー
図1.9 リソースエントリーのタブ
図1.10 リソースエントリーの編集可能なエリア
1.4.6. UI のショートカット
- Message Center は、JBoss ON サーバーによって送信された通知をすべて表示します。これには、アラート、設定の変更、インベントリーの変更、またはサーバーまたは UI のエラーメッセージが含まれます。
- お気に入りボタンを使用すると、選択したリソースやグループへの移動を迅速化できます。一方、リソースページでは、わずかな青の分散を使用して、そのリソースをお気に入りのリストに追加できます。
- リソースの可用性は、リソースが利用できるかどうかが緑色のチェックマークで、リソースがダウンしている場合は赤い X と表示されます。
図1.11 ショートカット
1.4.7. Red Hat Access Menu
- 便宜上、Red Hat の知識およびソリューションに排他的にアクセスできます。
- エラーコード、メッセージ、およびその他の情報を検索し、Red Hat カスタマーポータルから関連する情報を表示します。
- 新しいサポートケースを作成し、既存のサポートケースを表示し、JBoss Enterprise Application Platform 6 インスタンスおよびその他のファイルから収集された JBoss Diagnostic Reporter(JDR)レポートをこれらのケースに添付します。
1.4.7.1. 基本的な使用方法
1.4.7.2. 検索
1.4.7.3. サポート
1.4.7.4. サポートケースの新規作成
1.4.7.5. サポート対象アプリケーションサーバーで新しいサポートケースを作成する
1.4.7.6. 既存のサポートケースの表示
1.4.7.7. ケースの編集
1.5. Message Center での通知の取得
図1.12 Message Center
1.6. テーブルの表示のソートと変更
図1.13 パーティションイベントリスト上の基本的なテーブルソート
図1.14 サーバーリソース一覧の基本的なテーブルソート
図1.15 サーバーリソース一覧の高度なテーブルソート
図1.16 Sort メソッドの変更
1.7. ダッシュボードのカスタマイズ
1.7.1. ポートレットの編集
図1.17 ポートレットアイコン
1.7.2. ダッシュボードの追加および編集
図1.18 タブ付きダッシュボード
- メインの Dashboard の右端にある New Dashboard ボタンをクリックします。注記Dashboards を編集および追加するプロセスは非常に似ています。唯一の違いは、Dashboard を編集するには、Edit Mode ボタンをクリックします。
- 新しい Dashboard が編集モードで開きます。新しい Dashboard の名前を入力します。
- 必要なポートレットを Dashboard に追加します。必要に応じて、ポートレットの数に合わせて列数を変更します。
1.8. お気に入りの設定
図1.19 お気に入りアイコン
図1.20 お気に入りリスト
1.9. エントリーの削除
図1.21 エリアブラウザーの削除された
第2章 リソースおよびグループの動的検索
2.1. 検索の推奨
- 保存済み検索(以前のカスタム検索文字列と、その検索に一致するリソースの数を含む)
- 利用できるリソース特性のプロンプトを提供する検索のクエリー
- テキスト検索。テキストプロンプトに一致するリソースの一部のプロパティーに基づくリソース一覧を提供します。
図2.1 検索推奨のタイプ
図2.2 検索契約の強調表示
2.2. 動的検索構文について
[search_area].[search_property] operator value operator additional_search
図2.3 リソース特性による検索
2.2.1. 基本的な文字列検索
図2.4 契約条件の一致
postgres table myexampletable
"My Compatible Group" 'test box' plugin=jboss 123.4.5.6 trait[partitionName]='my example group' server.example.com
name="Production's Main Group"
resource.xml:id=^100
script$
表2.1 文字列 Operator
operator | description |
---|---|
string | 文字列は結果文字列のどこでも発生する可能性があります。 |
^string | 指定の文字列は結果値の最初に表示される必要があります。 |
string$ | 指定の文字列は結果値の最後に指定されている必要があります。 |
^string$ | 結果は、先頭または末尾の文字を含まない指定の文字列と完全に一致している必要があります。 |
resource.trait[Database.startTime] = null
name = "null"
2.2.2. プロパティー検索
resource.type.plugin = Postgres
表2.2 リソース検索コンテキスト
property | description |
---|---|
resource.id | JBoss ON によって割り当てられるリソース ID 番号。 |
resource.name | UI に表示されるリソース名。 |
resource.version | リソースのバージョン番号。 |
resource.type.plugin | リソースタイプ。リソースの管理に使用するプラグインで定義されます。 |
resource.type.name | 名前でリソースタイプ。 |
resource.type.category | リソースタイプカテゴリー(platform、server、または service)。 |
resource.availability | UP または DOWN のいずれかのリソースの可用性。 |
resource.pluginConfiguration[property-name] | プラグイン内の可能な設定エントリーの値。 |
resource.resourceConfiguration[property-name] | リソース内の可能な設定エントリーの値。 |
resource.trait[property-name] | リソースの測定特性の値。 |
表2.3 グループ検索コンテキスト
property | description |
---|---|
group.name | グループの名前。 |
group.plug-in | 互換性のあるグループの場合、このグループのリソースタイプを定義するプラグイン。 |
group.type | 互換性のあるグループの場合、このグループのリソースタイプです。 |
group.category | リソースタイプカテゴリー(platform、server、または service)。 |
group.kind | 混在または互換性のあるグループのタイプ。 |
group.availability | UP または DOWN のいずれかのグループでリソースの可用性。 |
表2.4 Search String Operator
operator | description |
---|---|
= | 大文字と小文字を区別しない一致。 |
== | case-exact match。 |
!= | 大文字と小文字を区別しない負の一致(つまり、値は文字列では ありません )。 |
!== | case-exact negative match(つまり、値は文字列では ありません )。 |
2.2.3. 複合 AND および OR 検索
postgres server myserver
postgres AND server AND myserver
postgres | jbossas
a | b c
(a | b) (c | d)
(a) (b | (c d))
2.3. 動的検索の保存、再利用、および削除
- 検索を実行します。
- 検索バーの右側にある星をクリックします。フィールドが表示されたら、新しい検索の名前を入力します。検索名は green に表示されます。
第3章 レポートの表示およびエクスポート
3.1. Report の種類
図3.1 インベントリー概要レポート
表3.1 Report の種類
レポート名 | description | フィルターがあるか? |
---|---|---|
サブシステムレポート | ||
メトリクスの疑わしい | 指定のリソースの確立されたベースライン外のメトリクスを一覧表示します。すべてのリソースの疑わしいメトリックがすべて表示されますが、同じタイプのリソース間でも、メトリックをマークするベースラインはリソースごとに異なる場合があります。 | いいえ |
設定履歴 | すべてのリソースの設定変更をすべて表示します。バージョン番号はリソースごとではなく、グローバルに増分されます。設定履歴には、変更のバージョン番号、送信日および完了日、ステータス、変更のタイプ(個別またはグループ経由)が表示されます。 | いいえ |
最近の操作 | 操作が送信された時点ではなく(必ずしも実行されるとは限らず)、操作タイプおよびそのステータスを、すべてのリソースのすべての操作を一覧表示します。 | ◯ |
最近のアラート | リソースに起動されたすべてのアラートを、リソースの名前、起動されたアラート定義、およびアラート条件と共に一覧表示します。 | ◯ |
アラート定義 | すべてのリソースについて設定済みのすべてのアラート定義をそれらの優先順位および有効にされているかどうかを一覧表示します。 | いいえ |
最近のドリフト | すべてのリソースおよびドリフト定義用のスナップショットの一覧が含まれます。 | ◯ |
インベントリーレポート | ||
インベントリーの概要 | リソースタイプとバージョン番号別に分類された、インベントリー内のリソースの完全なリストが含まれます。 | いいえ |
プラットフォームの使用状況 | 現在の CPU パーセンテージ、実際のメモリー、スワップ領域を表示します。 | いいえ |
ドリフトコンプライアンス | は、ドリフトをサポートし、設定されたドリフト定義の数、およびグループが準拠しているかどうかを示すすべてのリソースタイプの一覧を表示します。リソースタイプをクリックすると、ドリフトに設定されたリソースの一覧と、個別のコンプライアンスステータスが表示されます。 | いいえ |
3.2. CSV へのレポートデータのエクスポート
図3.2 エクスポートされたインベントリーの概要
図3.3 日付フィルターを含むレポート
パート I. インベントリー、リソース、およびグループ
第4章 エージェントおよびリソースのシステムユーザーとの対話
- JBoss EAP サーバー
- PostgreSQL データベース
- Tomcat サーバー
- Apache サーバー
- 汎用 JVM
表4.1 Agent and Resource Users のスプレッドシート
resource | ユーザー情報 |
---|---|
PostgreSQL |
監視および検出には影響しません。
設定の表示および編集には、エージェントユーザーに PostgreSQL 設定ファイルへの読み取り/書き込み権限が必要です。
|
apache |
監視および検出には影響しません。
設定の表示および編集には、エージェントユーザーに Apache 設定ファイルへの読み取り/書き込み権限が必要です。
|
Tomcat | 同じユーザーを使用する必要があります。またはエージェントを検出できません。 |
JMX サーバーまたは JVM | JMX リモーティングを使用する場合は、ユーザーごとに問題ありません。異なるユーザーやアタッチ API では検出できません。 |
JBoss AS/EAP |
EAP 5 以前: ユーザーはすべて正常ですが、先行ディレクトリーですべての先行ディレクトリーに読み取り権限と実行
run.jar および検索の権限が必要です run.jar 。
EAP 6 およびそれ以降では、エージェントを実行しているユーザーには、アプリケーションサーバーの設定ファイルへの読み取り権限がなければなりません。
|
4.1. エージェントユーザー
4.2. エージェントユーザーおよび検出
- JBoss EAP リソースでは、エージェントにファイルに対する読み取り権限が必要です。さらに、
run.jar
ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になりrun.jar
ます。 - RPM から JBoss EAP 6 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。
- Tomcat サーバーは、JBoss ON エージェントと Tomcat サーバーが同じユーザーとして稼働している場合にのみ検出できます。エージェントが root として実行されていても、Tomcat サーバーがエージェントとは異なるユーザーとして実行されている場合は検出できません。
- JVM または JMX サーバーが JMX リモーティングで実行されている場合は、エージェントが別のユーザーとして実行されているかどうかを検出できます。ただし、attach API を使用して実行している場合は、リソースを検出するためのエージェントと同じユーザーとして実行する必要があります。
4.3. ユーザーおよび管理タスク
- 検出
- アプリケーションのデプロイ
- スクリプトの実行
- 起動、停止、および再起動の操作の実行
- JBoss ON UI を使用した子リソースの作成
- リソース設定の表示および編集
4.4. JBoss ON 操作での sudo の使用
- パスワードのプロンプトなしでユーザーとの対話を必要としません。
- エージェントが変数をスクリプトに渡すことができるはずです。
- JBoss ON エージェントユーザーに特定のスクリプトまたはコマンドへの sudo 権限を付与します。たとえば、jbossadmin ユーザーとしてスクリプトを実行するには、以下を実行します。
[root@server ~]# visudo jbosson-agent hostname=(jbossadmin) NOPASSWD: /opt/jboss-eap/jboss-as/bin/*myScript*.sh
NOPASSWD オプションを使用すると、パスワードを要求せずにコマンドが実行されます。重要JBoss ON は、EAP インスタンスの開始時に、コマンドライン引数を start スクリプトで渡します。これは、sudoers
エントリーに完全なコマンドラインスクリプト(引数を含む)を含めるか、ラッパースクリプトの sudo -u user コマンドを使用するか、スクリプト接頭辞のいずれかを指定して実行できます。2 つ目のオプションには、簡単なsudoers
エントリーがあります。 - 使用するラッパースクリプトを作成または編集します。リソースのスクリプトを直接呼び出す代わりに、スクリプトの実行 sudo に使用するラッパースクリプトを呼び出します。注記EAP 起動スクリプトでは、別のラッパースクリプトを作成する代わりに、接続設定にスクリプト接頭辞を設定できます。
/usr/bin/sudo -u jbosson-agent
たとえば、開始スクリプトラッパーの場合は、start-myScript.sh
以下を行います。#!/bin/sh # start-myScript.sh # Helper script to execute start-myConfig.sh as the user jbosson-agent # sudo -u jbosson-agent /opt/jboss-eap/jboss-as/bin/start-myConfig.sh
- スクリプトで渡す引数または設定を使用して、開始
run.sh
スクリプトを作成します。たとえば、start-myConfig.sh
以下のようになります。nohup ./run.sh -c MyConfig -b jonagent-host 2>&1> jboss-MyConfig.out &
第5章 リソースインベントリーの管理
5.1. Inventory について: リソース
5.1.1. 管理リソース: プラットフォーム、サーバー、およびサービス
- プラットフォーム(オペレーティングシステム)
- サーバー
- services
図5.1 リソース階層の例
- リソースには親が 1 つだけ指定できます。
- サーバーは、プラットフォーム(Linux 上の JBoss AS など)または別のサーバー(JBoss AS に組み込まれた Tomcat など)の子になります。
- サービスは、プラットフォーム、サーバー(JBoss AS の JMS キューなど)または別のサービス(データベース内のテーブルなど)の子になります。
- プラットフォーム、サーバー、およびサービスには多くの子サービスがあります。
5.1.2. コンテンツバックアップリソース
5.1.3. JBoss ON によって使用される Inventory のリソース
5.2. リソースの検出
5.2.1. 新しいリソースの検索: 検出
5.2.2. 検出スキャンの手動実行
- トップメニューの Inventory タブをクリックします。
- 左側のメニュー Platforms から選択し、スキャンを実行するプラットフォームを選択します。
- Operations タブを開きます。Schedules サブタブで、New ボタンをクリックします。
- 左側の Servers - Top Level Resources リンクを開き、エージェントリソースを選択します。
- ドロップダウンメニューから Manual Discovery 操作を選択し、詳細な検出(サーバーおよびサービス)または簡単な検出(サーバーのみ)を実行するかどうかを選択します。
- この Schedule エリアでラジオボタンを選択してすぐに操作を実行します。
- Schedule ボタンをクリックして操作を設定します。
5.2.3. 検出キューからのリソースのインポート
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューで、を選択し Discovery Queueます。
- インポートするリソースのチェックボックスを選択します。(プラットフォームなど)親リソースを選択すると、その子も自動的にインポートできます。
- UI の下部にある Import ボタンをクリックします。
5.2.4. 検出したリソースの無視
- トップメニュー Inventory から選択します。
- 画面の左側にある Resources メニューの下にある Discovery Queue 項目を選択します。
- 無視するリソースのチェックボックスを選択します。親リソースを選択すると、その子がすべて自動的に選択されます。
- ページ下部の Ignore ボタンをクリックします。
5.2.5. インポートされたリソースの無視
- Inventory Resources ページ
- 親リソースの Inventory ページ。
- Groups リソースインベントリーページ。
5.2.5.1. Resources ページからのリソースの無視
- Inventory メニューから、の該当するリソースビューを選択し Resourcesます。例:
- Inventory > Resources> All Resources、または
- Inventory > Resources > Services.
- 無視するリソースが含まれる行を選択します。必要に応じて複数のリソースを選択できます。
- ページ下部の Ignore ボタンをクリックします。
5.2.5.2. 親リソースの Inventory ページからのリソースの無視
- Inventory メニューから、の該当するリソースビューを選択し Resourcesます。例:
- Inventory > Resources> All Resources、または
- Inventory > Resources > Services.
- リソースリストから親リソースを見つけ、選択します。
- 親リソースページで、Inventory タブ を選択します。
- 親リソース Inventory タブから Child Resources サブタブ を選択します。
- Child Resources 一覧から無視されるリソースを含む行を選択します。必要に応じて複数の行を選択できます。
- ページ下部の Ignore ボタンをクリックします。
5.2.5.3. Groups ページからのリソースの無視
- Inventory メニューから、の該当するリソースグループを選択し Groupsます。例:
- Inventory > Groups> All Groups、または
- Inventory > Groups > Compatible Groups
- 無視するリソースが含まれるリソースグループを見つけます。
- リソースグループページで、Inventory タブ を選択します。
- リソースグループタブから Members サブ Inventory タブ を選択します。
- Members 一覧から無視されるリソースを含む行を選択します。必要に応じて複数の行を選択できます。
- ページ下部の Ignore ボタンをクリックします。
5.2.6. リソース種別の完全な無視
- トップメニューで、Administration タブをクリックします。
- 左側の Configuration メニューテーブルで、Ignored Resource Types 項目を選択します。
- ロードされたエージェントプラグインに基づいて利用可能なすべてのリソースタイプが Ignored Resource Types ページに表示されます。リソースを無視するには、鉛筆アイコンをクリックします。これは、リソースを無視して現在の enabled/disabled 設定をすべて切り替えます。リソースタイプが有効な場合は、エージェントにより検出されます。無効にされている場合は無視されます。
- ページの下部までスクロールし、Save ボタンをクリックします。
5.3. 検出に必要なリソース
5.3.1. EAP インスタンスを検出するエージェントの設定
- JBoss EAP 5 以前では、エージェントにはファイルに対する読み取り権限が必要です。さらに、
run.jar
ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になりrun.jar
ます。 - JBoss EAP 6 および 7 の場合、エージェントはアプリケーションサーバーの設定ファイルへの読み取り権限を持っている必要があります。
- RPM から JBoss EAP インスタンスをインストールする場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。
5.3.2. 検出用 Tomcat/EWS サーバーの設定(Windows)
- を実行し regeditます。
- Tomcat サーバー、
HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun2.0\Tomcat
Ver#の Java 設定キーに移動し\Parameters\Java
ます。 - Options 属性を編集して、以下のパラメーターを追加します。
-Dcom.sun.management.jmxremote.port=9876 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
- Tomcat サービスを再起動します。
5.4. 新規リソースの手動によるインポート
- トップメニューの Inventory タブをクリックします。
- 新しいリソースの親リソースを検索します。2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
- 親リソースの Inventory タブをクリックします。
- Inventory タブ下部の Import ボタンをクリックして、子リソースの種類を選択します。選択メニューは、その親が可能な子リソースのタイプを一覧表示します。
- プロパティーを入力し、新しいリソースを特定して接続します。システム内の各リソースタイプには、必要なプロパティーのセットが異なります。
5.5. 国リソースの作成
- トップメニューの Inventory タブをクリックします。
- 新しいリソースの親リソースを検索します。2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
- 親リソースの Inventory タブをクリックします。
- Inventory タブ下部の Create Child ボタンをクリックして、子リソースの種類を選択します。選択メニューは、その親が可能な子リソースのタイプを一覧表示します。
- 新しいリソースの名前および説明を記入します。
- プロパティーを入力し、新しいリソースを特定して接続します。システム内の各リソースタイプには、必要なプロパティーのセットが異なります。
5.6. リソース情報の表示および編集
図5.2 リソースエントリーの詳細の拡張
5.7. 接続設定の管理
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
- リソースの名前をクリックして、そのエントリーページに移動します。
- リソースの Inventory タブを開き、Connection Settings サブタブをクリックします。
- リソースの接続情報を変更します。フィールドがすぐに編集できない場合は、Unset チェックボックスを選択し、フィールドに新しい情報を入力します。
- Save ボタンをクリックします。
5.8. リソースのアンインベントリーおよび削除
5.8.1. リソースの削除とリソースの比較
5.8.2. リソースの削除時の注意事項の使用
Uninventory Irrevably delete the Resource History and Data(リソース履歴とデータの削除)
リソースのインベントリーを解除すると、そのリソースに対して JBoss ON が必要とするすべてのデータが削除されます。メトリックデータと履歴監視データ、アラート、ドリフトと設定履歴、操作履歴などのデータが削除されます。リソースがインベートされないと、そのデータを復元することはできません。
リソースをすべて削除または削除
JBoss ON から親リソースが削除されると、その子もすべて削除されます。たとえば、EAP サーバーを削除すると、JBoss ON インベントリーからデプロイされた web アプリケーションがすべて削除されます。プラットフォームを削除すると、そのプラットフォーム上のサーバー、サービス、およびリソースがすべて削除されます。
検出される未使用のリソース
リソースが未使用で、JBoss ON のデータが永続的に削除されますが、基礎となるリソースは引き続き存在します。これは、リソースをまだ検出できることを意味します。リソースがインベントリーに検出され、再度追加されないようにするには、にあるようにリソースを無視し 「検出したリソースの無視」 ます。
削除されたリソースに依存するものが失敗しました。
一部のリソースタイプは削除できます。つまり、JBoss ON のインベントリーだけでなく、リソース自体がマシンから削除されます。そのリソースに依存するものはすべて、リソースが削除されるため、エラーが発生する可能性があります。たとえば、EAP サーバーのデータソースが削除されると、データソースは EAP サーバー自体から削除されます。データソースへの接続を試みるアプリケーションは、存在しないため、動作を停止します。
5.8.3. インベントリータブからのインベントリーの解除
- トップメニューの Inventory タブをクリックします。
- 左側の Resources テーブルにあるリソースカテゴリーを選択し、必要に応じてリソースに対してフィルターをかけます。
- 一覧からインベントリーを解除するリソースを選択し、Uninventory ボタンをクリックします。
- プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
- リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。
5.8.4. 親インベントリーからのインベントリーの未使用
- トップメニューの Inventory タブをクリックします。
- リソースの親リソースを検索します。2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
- 親リソースの Inventory タブをクリックします。
- 子リソースの行をクリックして、インベントリーを解除します。複数のエントリーを選択するには、Ctrl キーを使用します。
- Uninventory ボタンをクリックします。
- プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
- リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。
5.8.5. グループインベントリーからのインベントリーの解除
- トップメニューの Inventory タブで、Groups 左側のメニューで互換性のあるグループアイテムまたは混合グループアイテムを選択します。
- グループの名前をクリックします。
- グループの Inventory タブを開き、Members サブメニューを開きます。
- インベントリーを解除するグループメンバーの行をクリックします。複数のエントリーを選択するには、Ctrl キーを使用します。
- Uninventory ボタンをクリックします。
- プロンプトが表示されたら、リソースが適切に行われないようにすることを確認します。
- リソースがインベントリーに再インポートされないようにするには、次の検出スキャンで見つかったときにそのリソースを無視します。これは、で説明してい 「検出したリソースの無視」 ます。
5.8.6. リソースの削除
- 基礎となるマシンからリソースを削除します。
- インベントリーからリソースを削除します。
- JBoss ON から子リソースを削除します。
- アラート、ドリフト定義、メトリクスデータ、設定および操作履歴など、リソースに対してインベントリー情報を JBoss ON に保存します。
- トップメニューの Inventory タブをクリックします。
- 削除するリソースの 親 リソースを検索します。2章リソースおよびグループの動的検索 には、動的検索を使用してリソースを検索する情報があります。
- 親リソースの Inventory タブをクリックします。
- 子の一覧から削除するリソースを選択します。
- Inventory タブの下部にある Delete ボタンをクリックします。
5.9. インベントリーサマリーレポートの表示
- リソースタイプ
- リソースを管理する JBoss ON サーバープラグイン
- リソースの JBoss ON カテゴリー(プラットフォーム、サーバー、またはサービス)
- インベントリーのリソースタイプのバージョン番号
- インベントリー内のそのタイプのリソースの合計数
- トップメニューで、Reports タブをクリックします。
- 左側の Inventory メニューテーブルのメニューボックスで、Inventory Summary レポートを選択します。
- リソースタイプの名前をクリックして、対象のリソースタイプのインベントリー一覧に移動します。
inventorySummary.csv
ます。
第6章 グループの管理
6.1. グループ
表6.1 グループの種類
type | description | 静的または動的 |
---|---|---|
混合グループ | 任意のリソースタイプのリソースが含まれます。混合グループに配置できるリソースの数やタイプには制限はありません。混合グループは、グループ化されたリソースセットに対してユーザーにアクセスパーミッションを付与する際に便利です。 | static |
互換性のあるグループ | 同一タイプのリソースのみが含まれます。互換性のあるグループにより、グループの全メンバーに対して同時に操作を実行でき、同じタイプの複数のリソースを個別にアップグレードする必要がなくなります。また、企業全体のリソースに対して 1 度に他の操作を実行することもできます。 | static |
再帰グループ | グループ内のすべての子リソースが含まれます。再帰グループは、明示的なメンバーの可用性と子リソースの可用性の両方を表示します。 | static(メンバー)および動的(children) |
autogroups | すべてのリソースを、上部のプラットフォームでリソース階層の一部として表示し、プラットフォームの下の子リソースおよび子リソースを表示します。同じタイプの子リソースは自動的に autogroup にグループ化されます。 | 動的 |
6.1.1. 動的および静的グループ
6.1.2. 自動グループについて
図6.1 PostgreSQL 自動グループ
6.1.3. 互換性のあるグループと混合グループの比較
図6.2 互換性のあるグループエントリー
図6.3 混合グループエントリー
6.1.4. 再帰グループの使用
6.2. グループの作成
- トップメニューの Inventory タブをクリックします。
- 左側のメニューで Groups、互換性があるか、または混在するグループのタイプを選択します。互換性のあるグループは、すべて同じタイプのリソースを持ちますが、混合グループは異なるタイプのメンバーを持ちます。メンバーのタイプの違いは、で説明しているように、互換性のあるグループや混合グループを管理する方法が異なることを意味し 「互換性のあるグループと混合グループの比較」 ます。
- グループの名前と説明を入力します。グループを再帰的にマークすると、特にロールのアクセス制御を設定する際にリソースの管理が容易になります。たとえば、管理者はグループにアクセス権を付与し、メンバーリソースの子リソースを自動的に含めることができます。
- グループメンバーを選択します。名前、タイプ、およびカテゴリーに基づいて選択を絞り込むことができます。
6.3. グループメンバーシップの変更
- トップメニューの Inventory タブで、Groups 左側のメニューで互換性のあるグループアイテムまたは混合グループアイテムを選択します。
- グループの名前をクリックします。
- グループの Inventory タブを開き、Members サブメニューを開きます。
- ページ下部の Update Membership ボタンをクリックします。
- 左側のボックスからグループに追加するリソースを選択します。メンバーを削除するには、右側のボックスからメンバーを選択します。選択したリソースを移動するには、矢印を使用します。複数のリソースを選択するには、Ctrl+click を使用します。
- Save ボタンをクリックします。
6.4. 互換性のあるグループ接続プロパティーの編集
- グループ内のすべてのリソースにプロパティーの値が同じである場合、グループコネクションプロパティーはその正確な値になります。
- 1 つのリソースに、グループの残りのリソースとは異なる値がある場合、そのプロパティーには特別なマーカーの値が ~ Mixed Values ~ になります。
- トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
- 互換性のあるグループの名前をクリックします。
- グループの Inventory タブを開き、Connection Settings サブ項目をクリックします。
- プロパティーを編集するには、フィールド別に鉛筆をクリックします。
- すべてのリソースを同じ値に変更するには、フィールドの Unset チェックボックスをクリックし Set all values to...ます。特定のリソースを変更するには、そのリソースの Unset チェックボックスをクリックし、新しい値を指定します。
第7章 動的グループの使用
7.1. 動的グループ構文
7.1.1. 一般的な式構文
- 特定のリソース属性または値( 簡単 な式)
- リソースタイプ(ピボットテーブル 式 )
- 別のグループのメンバー別( 絞り込む 式)
expression 1 exprA1 exprA2 groupby exprB1 groupby exprB2 expression 2 exprA2 exprA1 groupby exprB2 groupby exprB1
表7.1 動的グループプロパティー
type | サポートされる属性 | ||||||
---|---|---|---|---|---|---|---|
リソース自体に関連する | |||||||
resource
|
| ||||||
リソースタイプに関連する | |||||||
resourceType
|
| ||||||
リソース設定に関連する | |||||||
plug-inConfiguration
|
プラグイン設定プロパティー
| ||||||
resourceConfiguration
|
すべてのリソース設定プロパティー
| ||||||
リソースモニタリングデータに関連する | |||||||
traits
|
任意の監視特性
| ||||||
可用性
|
UP または DOWN のいずれかの現在の状態
|
resource.id = 10001
resource.parent.id = 10001
- resource
- resource.child
- resource.parent
- resource.grandParent
7.1.2. 単純な式: 値の検索
resource.attribute[string-expression] = value
resource.parent.type.category = Platform
resource.trait は
汎用リソース属性で、partitionName などのサブ属性は実際のパラメーターを 特定
します。
empty resource.attribute[string-expression]
not empty resource.attribute[string-expression]
7.1.3. ピボットテーブル: 属性によるグループ化
groupby resource.attribute
parent.name
属性はすべての親リソースに基づいて一意のグループを作成します。
groupby resource.parent.name
図7.1 リソースおよび親
7.1.4. 式の絞り込み: グループのメンバー
memberof = "Dev Resource Group" groupby resource.type.name
7.1.5. 複合式
resource.parent.type.category = Platform
resource.parent.type.category = Platform resource.name.contains = JBossAS
groupby resource.type.plugin groupby resource.type.name groupby resource.parent.name
resource.type.category = server groupby resource.type.plugin groupby resource.type.name groupby resource.parent.name
resource.type.plugin = JBossAS resource.type.name = JBossAS Server empty resource.pluginConfiguration[principal]
7.1.6. サポートされない式
すべての式が同じ設定エリアにある必要があります。
式のすべての設定プロパティーはリソース設定からのみ、またはプラグイン設定のみである必要があります。両方から式を取ることはできません。
各プロパティーは一度だけ使用する必要があります。
プロパティーは、dynagroup 定義で 1 回のみ使用できます。
valid resource.trait[x] = foo not valid resource.trait[x] = foo resource.trait[y] = bar
resource.grandParent.trait[Trait.hostname].contains = stage resource.parent.type.plugin = JBossAS5 resource.type.name = Web Application (WAR)
resource.grandParent.trait[Trait.hostname].contains = stage resource.parent.type.plugin = JBossAS5 resource.type.name = Web Application (WAR) resource.trait[contextRoot] = jmx-console
There was a problem calculating the results: java.lang.IllegalArgumentException: org.hibernate.QueryParameterException: could not locate named parameter [arg2]
resource.parent.trait[x] = foo resource.grandParent.trait[y] = bar
7.1.7. Dynagroup 式の例
例7.1 JBoss クラスター
resource.type.plugin = JBossAS resource.type.name = JBossAS Server groupby resource.trait[partitionName]
例7.2 各プラットフォームタイプのグループ
resource.type.plugin = Platforms resource.type.category = PLATFORM groupby resource.type.name
例7.3 autogroups
groupby resource.type.plugin groupby resource.type.name groupby resource.parent.name
例7.4 未加工の測定テーブル
resource.type.plugin= Postgres resource.type.name = Table resource.parent.name = rhq Database resource.name.contains = rhq_meas_data_num_
例7.5 マルチキャスト検出のエージェントのみ
resource.type.plugin= RHQAgent resource.type.name = RHQ Agent resource.resourceConfiguration[rhq.communications.multicast-detector.enabled] = true
例7.6 イベント追跡を含む Windows プラットフォームのみ
resource.type.plugin= Platforms resource.type.name = Windows resource.pluginConfiguration[eventTrackingEnabled] = true
例7.7 マシン別に JBoss AS サーバー
groupby resource.parent.trait[Trait.hostname] resource.type.plugin = JBossAS resource.type.name = JBossAS Server
7.2. 動的グループの作成
- トップメニューの Inventory タブをクリックします。
- 左側の Groups メニューボックスで、Dynagroup Definitions リンクをクリックします。
- New ボタンをクリックして動的グループ定義フォームを開きます。
- 動的グループの名前と説明を入力します。グループの作成に使用するロジックを特定するために、定義で作成されたグループに付加されるため、この名前は重要になります。
- 検索式を入力します。これを行うには、Expression ボックスに式を直接入力するか、保存された式を使用します。保存された式には、式の構築および検証に役立つウィザードがあります。保存された式を作成するには、ドロップダウンメニューのボタンをクリックします。他の選択によって、式がアクティブであるか、非アクティブな式になるオプションもあります。これにより無効な式を防ぐことができます。上部の Expression ボックスに現在作成された式が表示されます。
- 式を入力したら、動的グループを再帰的にするかどうかを設定します。
- オプションの再計算の間隔を設定します。デフォルトでは、動的グループはメンバーを自動的に再計算しないため、再計算値は 0 に設定されます。グループメンバーシップを再計算するには、を Recalculation interval 時間頻度(ミリ秒単位)に設定します。注記大規模な履歴全体でグループ定義を再計算すると、JBoss ON サーバーのリソース集約となる可能性があるため、再計算の間隔を設定する場合は注意して行ってください。大規模の場合、JBoss ON サーバーのパフォーマンスに影響しないようにするため、1 時間などの長い間隔を設定します。
7.3. グループメンバーの再計算
- トップメニューの Inventory タブをクリックします。
- 左側の Groups メニューで、Dynagroup Definitions リンクをクリックします。
- dynagroups の一覧で、計算する dynagroup 定義の行を選択します。
- テーブルの下部にある Recalculate ボタンをクリックします。
第8章 ユーザーアカウントの作成
8.1. rhqadmin アカウントの管理
- トップメニューの Administration タブをクリックします。
- 左側の Security 表で、を選択し Usersます。
- の名前をクリックし rhqadminます。
- ユーザーフォームの編集で、パスワードを新しい複雑な値に変更します。
8.2. 新規ユーザーの作成
- トップメニューの Administration タブをクリックします。
- 左側の Security 表で、を選択し Usersます。
- 現在のユーザーの下部にある NEW ボタンをクリックします。
- 新規ユーザーの説明を入力します。新規ユーザーアカウントがアクティブになるよう Yes に、Enable Login 値を設定する必要があります。
- Available Roles エリアから必要なロールを選択し、をポイントする矢印をクリックしてロール Assigned Roles を割り当てます。
- Save ボタンをクリックして、割り当てられたロールで新規ユーザーを保存します。
8.3. ユーザーエントリーの編集
- トップメニューの Administration タブをクリックします。
- Security メニューから、を選択し Usersます。
- エントリーを編集するユーザーの名前をクリックします。
- 編集ユーザーフォームで、詳細を変更する必要のある内容を変更し、保存します。
8.4. ユーザーアカウントの無効化
- トップメニューの Administration タブをクリックします。
- 左側の Security 表で、を選択し Usersます。
- エントリーを編集するユーザーの名前をクリックします。
- ユーザーフォームの編集で、Enable Login ラジオボタンをに変更し Noます。
- Save ボタンをクリックして、割り当てられたロールで新規ユーザーを保存します。
8.5. ユーザーのロール割り当ての変更
- トップメニューの Administration タブをクリックします。
- Security メニューから、を選択し Usersます。
- 編集するユーザー名をクリックします。
- ロールをユーザーに 追加 するには、そのエリアから必要なロールを選択するには、その Available Roles エリアを指す矢印をクリックし Assigned Roles ます。ロールを 削除 するには、右側に割り当てられたロールを選択し、左側の矢印をクリックします。
- Save をクリックし、ロールの割り当てを保存します。
第9章 ロールおよびアクセス制御の管理
9.1. JBoss ON のセキュリティー
9.1.1. アクセス制御およびパーミッション
- グローバルパーミッションは JBoss ON サーバー設定に適用 されます。ここでは、ユーザーの作成、ロールの編集、グループの作成、インベントリーへのリソースのインポート、JBoss ON サーバープロパティーの変更などの管理タスクについて説明します。
- リソースレベルのパーミッション は、ユーザーが JBoss ON インベントリー内の特定のリソースに対して実行できるアクションに適用されます。アラートの作成、監視の設定、リソース設定の変更などのアクションが対象となります。リソースレベルのパーミッションは、JBoss ON 内のサブシステムエリアに関連付けられます。
図9.1 アクセスオプションの読み取り
表9.1 JBoss ON のアクセス制御定義
アクセス制御の種類 | description |
---|---|
グローバルパーミッション | |
セキュリティーの管理 |
superuser と同等のパーミッションです。Security パーミッションにより、他のユーザー、ロール、リソースなど、JBoss ON のエントリーを作成および編集する権限が付与され、JBoss ON のサーバー設定が変更され、インベントリーを制御することができます。
警告
Security アクセス制御レベルは非常に強力であるため、どのユーザーに割り当てられているかに注意してください。スーパーユーザーの数を必要に応じて制限します。
|
インベントリーの管理 | 新しいリソースのインポートを含む、すべての JBoss ON リソースで操作を実行できます。 |
設定の管理 | JBoss ON サーバー設定自体で設定を追加または変更できるようにします。これには、プラグインのデプロイや LDAP 認証の使用などの操作が含まれます。 |
バンドルグループの管理 |
ユーザーはバンドルグループのメンバーの追加および削除を許可します。暗黙的には、バンドルを表示するパーミッションが含まれます。これは、リソースの Inventory パーミッションの管理に類似しています。
注記
このパーミッションは、すべてのバンドルレベルの create、deploy、および delete パーミッションに必要です。
|
バンドルのグループへのデプロイ | ユーザーがアクセス可能なリソースグループにバンドルをデプロイできるようにします。 |
バンドルの表示 | バンドルグループ割り当てに関係なく、ユーザーはすべてのバンドルを表示できます。 |
バンドルの作成 | ユーザーがバンドルバージョンを作成および更新できるようにします。バンドルの作成時には、ユーザーが View Bundles パーミッションを持たない限り、バンドルグループに割り当てる必要があります。この場合、ユーザーはバンドルを作成して割り当て解除することができます。 |
バンドルの削除 | ユーザーに、表示権限を持つバンドルの削除を許可します。 |
バンドルの管理(非推奨) |
リソースのプロビジョニングに使用するバンドル(パッケージ)のアップロードおよび管理を許可します。
このパーミッションは非推奨となっています。古いバンドル設定およびユーザーロールと後方互換性のために含まれています。ただし、このパーミッションは、特定のバンドル、グループ、またはリソース(デプロイメント用)へのアクセスを制限する機能を提供しませんでした。この詳細な制御を行わずに、このパーミッションは高レベルの管理者にのみセキュリティーを維持できます。
|
リポジトリーの管理 | ユーザーは、指定した所有者なしで、設定されたリポジトリー(プライベートリポジトリーやリポジトリーなど)にアクセスできます。この権限を持つユーザーは、リポジトリーでコンテンツソースを関連付けることもできます。 |
ユーザーの表示 | JBoss ON の他のユーザーのアカウントの詳細(ロール割り当てを除く)をユーザーに許可します。 |
リソースレベルのパーミッション | |
インベントリー | リソースの詳細と接続設定をユーザーが編集できるようにします。つまり、JBoss ON インベントリーのリソースに関する情報を表します。リソース設定を編集する権限は付与されません。 |
測定の管理 | ユーザーがリソースの監視設定を構成できるようにします。 |
アラートの管理 | リソースに関するアラートおよび通知の作成を許可します。新しいアラート送信側を設定するとサーバー設定が変更されるため、グローバルパーミッションの関数になり Settings ます。 |
Control | ユーザーがリソースに対して( コントロールアクションとも呼ばれる)操作を実行できるようにします。 |
設定 |
JBoss ON を使用して、リソースの設定を変更することができます。
注記
設定変更を可能にするには、ユーザーがリソースに対する適切なパーミッションを持っている必要があります。
このアクセスエリアには、以下の 2 つのオプションがあります。
これらのパーミッションのいずれかがロールに付与されない場合、ロールのユーザーはリソース設定へのアクセスは拒否されます。
|
誤差の管理 | リソースおよびテンプレートのドリフト定義を作成、変更、および削除できます。また、ユーザーは、スナップショットの表示や比較などのドリフト情報を管理できます。 |
コンテンツの管理 | リソースで利用可能なコンテンツプロバイダーおよびリポジトリーを管理できるようになります。 |
子リソースの作成 | 指定したリソースタイプの子リソースを手動で作成できるようにします。 |
リージョンリソースの削除 | ユーザーが指定したリソースタイプの子リソースを削除または無効化できるようにします。 |
バンドルレベルのパーミッション | |
グループへのバンドルの割り当て | ユーザーがバンドルをグループに追加できるようにします。明示的なバンドルグループでは、これが唯一必要なパーミッションです。割り当てられて いない グループ(基本的にすべてのグループメンバーシップから削除)にバンドルを追加するには、グローバル View Bundles パーミッションも必要です。 |
グループからのバンドルの割り当て解除 | グループからバンドルを削除することを許可します。 |
グループのバンドルの表示 | ユーザーがパーミッションを持つグループ内の任意のバンドルを表示できるようにします。 |
グループへのバンドルの作成 | ユーザーがパーミッションを持つバンドルグループ内に新しいバンドルを作成できるようにします。これにより、ユーザーはバンドルグループ内の既存のバンドルのバージョンを更新することもできます。 |
グループからのバンドルの削除 | ユーザーがパーミッションを持つグループに属し、バンドルバージョンとバンドル全体の両方を削除できるようにします。 |
バンドルのグループへのデプロイ | ユーザーは、(作成および削除のパーミッションに関係なく)表示できるバンドルを、パーミッションを持つリソースグループ内の任意のリソースにデプロイすることを許可します。 |
9.1.2. アクセスとロール
- superuser ロールは、JBoss ON のすべてのものへの完全なアクセスを提供します。このロールは変更できず、削除できません。JBoss ON サーバーを最初にインストールしたときに作成されたユーザーは、このロールに自動的にメンバーになります。
- JBoss ON の すべてのリソースに完全なパーミッションを提供するすべての resources ロール が存在します(ユーザーの作成などの JBoss ON の管理機能には含まれません)。これは、JBoss ON によって管理されるリソースの設定を変更したり、JBoss ON によって管理されるリソースのアラートを設定できなくても JBoss ON サーバーやエージェントの設定を要求しない場合など、IT ユーザーにとって有用なロールです。
9.1.3. アクセスとグループ
リソースとバンドルへの単一ユーザーのアクセスを定義する 2 つのロール
Bundle Group A Resource Group A | | V V Role 1 <--- User A ---> Role 2 ^ ^ | | Permissions Permissions - view bundles in group - deploy bundles to group - create bundles
9.2. 新規ロールの作成
- ロールに関連付けるリソースグループを作成します。グループの作成については、を参照してください 「グループの作成」。デフォルトでは、JBoss ON は リソースグループ のみを使用してロールに関連付けるため、これらが必要です。ただし、LDAP ディレクトリーのオプションのユーザーグループをロールに割り当てることもできます。これにより、グループメンバーは自動的にロールメンバーとして処理されます。LDAP グループ は、の説明に従ってサーバー設定で設定する必要があり 「LDAP ユーザーグループをロールに関連付ける」 ます。
- トップメニューで、Administration タブをクリックします。
- 左側の Security メニューテーブルで、Roles 項目を選択します。
- メインのタスクウィンドウに現在のロールの一覧が表示されます。一覧の下部にある New ボタンをクリックします。
- ロールに説明的な名前を付けます。これにより、ロール間でパーミッションの管理が容易になります。
- グローバルパーミッションは、JBoss ON サーバーおよび設定のエリアにパーミッションを付与 します。
- リソースパーミッションには、リソース管理のパーミッションが付与 されます。
特定のアクセスパーミッションについては、に記載されてい 「アクセス制御およびパーミッション」 ます。- 必要に応じて、必要なグループを左の Available Resource Groups 領域から Assigned Resource Groups 右側に移動します。
- 下にある Save ボタンをクリックします。
- ロールにユーザーを割り当てる Users タブを選択します。必要に応じて、必要なユーザーを、左側の Available Users 領域から右 Assigned Users に移動します。
- 右上の矢印をクリックして、作成ウィンドウを閉じます。
9.3. 拡張例: ビジネスユーザー向けの読み取り専用アクセス
設定
例ある管理チームが、インフラストラクチャーのパフォーマンスとメンテナンスの追跡、インシデント対応手順の定義、および機器のアップグレードを行うために JBoss ON データの読み取りおよびアクセスを行うことができます。これらのビジネスユーザーは JBoss ON 情報を表示する必要がありますが、IT および開発部門が処理する設定を編集することはできません。
The Plan
Tim the IT Guy は、最初にビジネスユーザー が 実行する必要があるアクションを定義し、すべてを表示できる必要があります。
- リソースを追加および削除するインベントリーおよび履歴のリソースを表示します。
- 測定やイベントなどの監視情報を表示します。
- アラートを表示します。
- コンテンツ、バンドル、およびリソースへのデプロイメントを表示します。
- 設定のドリフトを表示します。
- 設定および操作のすべてのリソース履歴を表示します。
- ユーザーの詳細を表示して、監査アクションの情報を取得します。
結果
ビジネスユーザーは、設定やインベントリーを誤って変更することなく、必要なすべての情報にアクセスできます。
9.4. 拡張例: すべてのリソースの表示、一部のリソースの編集
設定
たとえば、Corp. には、IT インフラストラクチャーに関連する 3 つの主要グループがあります(開発、QE、および実稼働環境)。各グループには、構成の管理、パフォーマンス設定の管理、および新規アプリケーションのロールアウトをサポートするために、他のチームからの情報が必要ですが、独自のシステムを管理できます。
The Plan
Tim the IT Guy は、まずアクセス制御内で表現する必要があるさまざまな関係を定義します。
- インフラストラクチャー内のすべてのスタックのパフォーマンスデータを表示できる必要があります。
- 各部門には、独自のシステムへの書き込みアクセスが必要になります。
- 各グループ内の少なくとも一部の管理者には、システム設定を更新する必要があります。
- 各グループ内の少なくとも一部の管理者には、バンドルを作成およびデプロイして、独自のグループ内でアプリケーションを管理する機能が必要です。
- 各スタック環境内のすべてのリソースが含まれる混合グループ。スタックには、プラットフォーム、Postgres データベース、EAP サーバー、Web コンテキスト、実稼働環境の管理に使用するその他のリソースが含まれます。これにより、Dev Stack、QE Stack、および Production Stack の 3 つのグループが生成されます。
- 3 つのスタックグループすべてを含む「すべてのスタック」ネストされたグループ。このグループは、すべてのリソースに該当せず、スタックグループのみが含まれます。ただし、JBoss ON 関連のリソースや、これらのスタックには関係しないその他の管理リソースが除外されます。
- これらの環境にはアプリケーション開発が含まれるため、デプロイメントを維持するために各組織に独自のバンドルグループも必要です。
- 環境間でバンドルをプロモートするためのメクnism が必要です。Tim the IT Guy は、「Promote Bundles」グループを作成し、別の環境に移動する準備ができたときにバンドルを追加できます。
- 設定ビューのみの権限を含む、すべてのリソースへの表示のみ権限
- スタック内のリソースに対する権限の編集によるモニタリング、アラート、ドリフト、操作、およびインベントリー
- 設定用にスタック内のリソースに対する権限の編集
- スタック内のバンドル権限の表示
- スタック内でのバンドル権限の作成およびデプロイ
- 一般ユーザー
- リソース設定を管理する管理者
- グループ間のバンドルを作成(昇格)できる管理者
Dev Stack
Bundle Group
|
Role BG1
|
V
Regular Joe
^ ^
| |
Role RG1 Role RG2
| |
"All Stack" Dev Stack
Resource Resource
Group Group
^ | Role RG1 <------Permissions | | "All Stack" View.alerts Resource View.inventory Group View.measurements View.etc... View.configuration
^ | Role RG2 <------Permissions | | Dev Stack Edit.alerts Resource Edit.inventory Group Edit.measurements Edit.etc... Deploy.bundles
Dev Stack Bundle Group | Role BG1 <-----Permissions | | V View.bundles Create.bundles
"Regular Joe" roles | V Group Lead <------Role RG3 | Permissions | Edit.configuration
Dev Stack Permission: Bundle Group Create.Bundles \ / \ / Role BG1 | V Role BG2 ----> Group Lead <---- Role BG3 / \ / \ / \ / \ QE Stack Permission: Prod Stack Permission: Bundle Group Create.Bundles Bundle Group Create.Bundles
結果
各グループ内のユーザーには、必要なパフォーマンスや設定情報を表示するアクセス権が付与されますが、変更できるのは指定されたグループ内のリソースのみです。各グループ内の管理者のみが設定変更を行うことができます。
第10章 認証および承認用の LDAP サービスの統合
10.1. サポート対象のディレクトリーサービス
- Red Hat Directory Server 8.1、8.2、および 9.0
- Microsoft Active Directory 2003 および 2008
10.2. ユーザー認証用の LDAP
10.2.1. LDAP 認証およびアカウント作成について
10.2.2. ユーザーストアに LDAP の使用に関連する問題
図10.1 LDAP グループ、JBoss ON ロール、およびロールメンバー
- 通常のユーザーアカウントだけを 1 カ所で作成してください。LDAP が認証に使用される必要がある場合は、LDAP ディレクトリーでユーザーアカウントを追加または削除するだけです。
- 理想的には、JBoss ON ユーザーアカウントを特殊管理ユーザーに限定し、通常のアカウントの LDAP ディレクトリーに依存します。
- LDAP グループを中心にロールを設計しようとします。つまり、これらのロールの JBoss ON ユーザーアカウントは管理アカウントに制限されるべきか、または完全に回避する必要があります。
10.2.3. LDAP ユーザー認証の設定
- トップメニューで、Administration タブをクリックします。
- 左側の Configuration メニューテーブルで、System Settings 項目を選択します。
- その LDAP Configuration Properties エリアにジャンプします。
- Use LDAP Authentication チェックボックスをチェックして、JBoss ON が LDAP ユーザーディレクトリーをアイデンティティーストアとして使用するようにします。
- 特定の LDAP ディレクトリーに接続する接続を設定します。
- LDAP サーバーの LDAP URL を指定します。これは ldap://hostname[:port] のフォーマットです。例:
ldap://server.example.com:389
デフォルトでは、これはポート 389(標準 LDAP ポート)または 636(SSL が選択されている場合はセキュアな LDAP ポート)経由でローカルホストに接続します。 - セキュアな接続を使用するには、チェック Use SSL ボックスを選択します。SSL を使用する場合、LDAP ディレクトリーが SSL で実際に実行されていることを確認し、接続 URL が適切な SSL ポートおよびプロトコルを参照するようにします。
ldap
s
://server.example.com:636
- サーバーへの接続に使用するバインド認証情報を付与します。ユーザー名は、JBoss ON がディレクトリーにバインドするユーザーの完全な LDAP 識別名です。注記JBoss ON で LDAP 設定を行う前に、LDAP ディレクトリーにユーザーが存在している 必要 があります。それ以外の場合は、JBoss ON サーバーへのログイン試行は失敗します。また、JBoss ON ユーザーには LDAP ディレクトリーのユーザーおよびグループサブツリーへの適切な読み取りおよび検索アクセスがあることを確認してください。デフォルトでは、ロールなしで作成されたユーザーはログインできます。ロールについての詳細は、を参照してください 「アクセスとロール」。注記デフォルトでは、ロールなしで作成されたユーザーはログインできます。これは、ユーザーが LDAP に存在する可能性があるが、JBoss ON でロールが割り当てられていないため影響を受けます。ロールについての詳細は、を参照してください 「アクセスとロール」。
- 一致するユーザーエントリーに対して LDAP ディレクトリーを検索する際に JBoss ON が使用する検索パラメーターを設定します。
- 検索ベース は、サーバーがエントリーの検索を開始するディレクトリーツリーのポイントです。これはユーザー認証にのみ使用されるか、またはすべての JBoss ON 関連エントリーが同じサブツリーにある場合に、特定のサブツリーを参照できます。
ou=user,ou=JON,dc=example,dc=com
ユーザーまたはグループがディレクトリー全体に分散されている場合は、ベース DN を選択します。dc=example,dc=com
- 必要に応じて、特定のエントリーのサブセットを検索するために使用する検索フィルターを設定します。これにより、すべての JBoss ON 関連エントリーがカスタム属性などの共通の LDAP 属性を共有すると、検索パフォーマンスおよび結果が向上し
JonUser
ます。フィルターはワイルドカード(objectclass=*)または特定の値(JonUser=true)を使用できます。 - LDAP の命名属性を設定します。これは完全な識別名の左側にある要素です。たとえば uid=jsmith,ou=people,dc=example,dc=com、の left 要素はで uid=jsmith、naming 属性はになり
uid
ます。Active Directory のデフォルトの命名属性はですcn
。Red Hat Directory Server では、デフォルトの命名属性はですuid
。
- LDAP 設定を保存します。注記ユーザー認証に Group Filter および Member Property フィールドは必要ありません。にあるように、ロールに割り当てられる LDAP グループを設定するために使用され 「LDAP ユーザーグループをロールに関連付ける」 ます。
10.3. ロールおよび LDAP ユーザーグループ
10.3.1. グループ承認について
図10.2 ロールに割り当てられたグループ
- LDAP ディレクトリーサーバー接続を設定する必要があります。
- グループエントリー を検索するには、LDAP 属性を指定する必要があります。Active Directory の場合、これは一般的に group オブジェクトクラスになります。Red Hat Directory Server の場合、これは通常です groupOfUniqueNames。他の標準オブジェクトクラスも利用でき、JBoss ON 固有のオブジェクトクラスであってもカスタムを使用することもできます。
- グループの メンバー を識別するために LDAP 属性を指定する必要があります。一般的なメンバー属性は
member
およびですuniqueMember
。
(&(group_filter)(member_attribute=user_DN))
member
属性を検索します。
ldapsearch -h server.example.com -x -D "cn=Administrator,cn=Users,dc=example,dc=com" -W -b "dc=example,dc=com" -x '(&(objectclass=group)(member=CN=John Smith,CN=Users,DC=example,DC=com))'
member
、およびよりも一般的に groupOfUniqueNames グループの uniqueMember
属性を使用し group
ます。例:
/usr/lib64/mozldap6/ldapsearch -D "cn=directory manager" -w secret -p 389 -h server.example.com -b "ou=People,dc=example,dc=com" -s sub "(&(objectclass=groupOfUniqueNames)(uniqueMember=uxml:id=jsmith,ou=People,dc=example,dc=com))"
10.3.2. LDAP ユーザーグループをロールに関連付ける
- トップメニューで、Administration タブをクリックします。
- 左側の Configuration メニューテーブルで、System Settings 項目を選択します。
- その LDAP Configuration Properties エリアにジャンプします。
- の説明に従って、LDAP 接続を設定し 「LDAP ユーザー認証の設定」 ます。LDAP ディレクトリーを LDAP 承認を設定するためにアイデンティティーストアとして使用する必要はありませんが、推奨されます。
- サーバーが LDAP グループとそのメンバーを検索するために使用するパラメーターを設定します。JBoss ON 構成する検索フィルターは以下のようになります。
(&(group_filter)(member_attribute=user_DN))
- Group Search Filter フィールドは、グループエントリーの検索方法を設定します。これは通常、オブジェクトクラスで検索するグループのタイプを指定して行います。
(objectclass=groupOfUniqueNames)
- この Group Member Filter フィールドは、指定されたグループタイプがメンバーの識別名を保存するために使用する属性を指定します。例:
uniqueMember
user_DN は、ユーザーが UI にログインする際に JBoss ON によって動的に提供されます。 - LDAP 設定を保存します。
10.4. 拡張例: memberOf および LDAP 設定
設定
認証 は、他のユーザーの ID を検証するプロセスです。承認 とは、アイデンティティーが持つアクセス権限を決定するプロセスです。ユーザーは、ロールの割り当てに付与されたパーミッションに基づいてタスクを実行することが許可されます。
The Plan
認証用にユーザーを特定する方法と、承認のためにユーザーを整理する方法の 2 つの設定があります。
- LDAP ディレクトリーで JBoss ON ユーザーを識別する単一グループ
- JBoss ON へのアクセスレベルを決定するために使用される既存の LDAP グループが複数になる
memberOf
属性が自動的にユーザーエントリーに追加され、ユーザーが属するグループを示します。
memberOf
属性を自動的に追加/削除します。Tim(IT 管理者)は、認証用の検索フィルターとして、そのユーザーアカウントの memberOf
属性のみを使用する必要があります。
dn: uid=jsmith,ou=people,dc=example,dc=com uid: jsmith cn: John Smith ... memberOf: cn=JON User Group,ou=groups,dc=example,dc=com memberOf: cn=IT Administrators,ou=groups,dc=example,dc=com
memberOf
属性をターゲットとします。
memberOf='cn=JON User Group,ou=groups,dc=example,dc=com'
- Administrators Group は、インベントリーパーミッションの管理でロールにマップされます。
- Manager Group は、すべてのリソースおよび view ユーザーのパーミッションで表示(書き込みがない)パーミッションを持つロールにマップされます。
- Business Manager Group は、すべてのリソース設定、バンドル、ドリフト、測定、操作、およびアラートを読み取るパーミッションを持つロールにマップされますが、書き込み権限はありません。
結果
Tim(IT 管理者)は、JBoss ON のすべての認証とユーザーを設定するために、1 つの LDAP グループである JON Users グループのみを作成して管理する必要があります。LDAP スキーマを変更したり、ユーザーエントリーを直接変更したりする必要がありません。
パート II. リソース設定の管理
第11章 リソース操作の実行
11.1. オペレーション: 概要
11.1.1. 操作のメリットの概要
- コマンド引数や環境変数など、追加のパラメーターを使用することができます(コマンド引数や環境変数など)。
- JBoss ON がリソース設定の変更を検証する場合と同様に、操作パラメーター、コマンドライン引数、または環境変数をすべて検証します。
- これらはすべて同じタイプである限り、リソースのグループで実行できます。
- 操作は、特定の順序でグループリソースで実行するように順序付けできます。
- 定期的なスケジュールまたは 1 つの特定のタイミングで実行できます。
- 操作は、成功と失敗の両方の履歴を保持します。これにより、特定のリソースに対して実行される操作と、そのリソースに対して実行され、そのリソースに対して実行される操作をグループの一部として監査できます。
11.1.2. スケジューリング操作について
- カレンダー設定を使用して時間を選択します。カレンダーを使用してオペレーションをスケジュールする方法は 3 つあります。すぐに、今後設定するか、または繰り返しスケジュールに設定されます。繰り返しスケジュールは無制限にしたり、特定の期間内に実行したりできます。
- cron 式の使用。これは、ほぼ定期的なジョブに使用され、非常に複雑な実行スケジュールを設定するために使用できます。
図11.1 スケジュールされた操作
11.1.3. 運用に関する説明
11.2. 操作の管理: 手順
11.2.1. スケジューリング操作
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- Operations タブをクリックします。
- Schedules タブで、New ボタンをクリックします。利用できる操作のタイプは、リソースの特定のタイプによって異なります。注記この Schedules タブには、スケジュールされた操作の一覧が表示されます。これは、設定済みですが実行されていない操作を示します。スケジュールされた操作がない場合、タブには No items to show を読み取る説明があります。これは、リソースに利用できる操作がないことを意味します。つまり、操作がスケジュールされていないことを意味します。
- ポート番号、ファイルの場所、コマンド引数など、操作に必要なすべての情報を入力します。
- この Schedule エリアで、操作の実行時を設定します。を使用する場合 Calendar、日付ウィジェットから選択したように、指定した時間、または繰り返し可能なスケジュールで操作を実行できます。Cron Expression はジョブに基づいて繰り返し発生するジョブに使用され cron ます。これらの式の形式は、日次月分で、0- 59 0- 23 1-31 1-12 1-7 の潜在的な値で、アスタリスクを使用すると任意の値を設定できます。
- タイムアウト期間や操作自体にメモなど、操作に他のルールを設定します。
- Schedule ボタンをクリックして操作を設定します。
11.2.2. 操作履歴の表示
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- Operations タブをクリックします。
- History サブタブをクリックします。完了した操作または進行中の操作がすべて表示され、現在のステータスを示すアイコンが表示されます。
- 操作の名前をクリックして詳細を表示します。履歴の詳細ページには、操作の開始時間および終了時間、操作またはその他の操作メッセージの標準出力、および操作をスケジュールしたユーザーの名前が表示されます。
11.2.3. 保留中の操作のキャンセル
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- Operations タブをクリックします。
- Schedules タブで、キャンセル操作の行をクリックします。
- をクリックし Delete、アクションを確認します。
11.2.4. グループ操作の順序
- トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
- グループの名前をクリックして、操作を実行します。
- にあるように、操作を設定し 「スケジューリング操作」 ます。
- この Resource Operation Order エリアで、すべてのリソースに対して同時に(並列)または指定順序で実行されるように操作を設定します。操作が特定の順序で発生する必要がある場合は、すべてのグループメンバーが Member Resources ボックスに一覧表示され、必要に応じてドラッグアンドドロップによって再編成できます。オプションで、いずれかのリソースで失敗した場合に操作のグループキューを停止するには、Halt on failure チェックボックスを選択します。
11.2.5. JBoss サーバーの操作としてスクリプトを実行
.bat
Windows の場合.sh
Unix および Linux の場合.pl
Unix および Linux 用のスクリプト
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- Operations タブをクリックします。
- Schedules タブで、New ボタンをクリックします。
- Operation ドロップダウンメニューから操作タイプ Execute CLI script として選択します。注記この Execute script オプションは、デフォルトで JBoss AS および JBoss AS 5 リソースに対してのみ利用でき、スクリプトが実行できる場合にのみ利用できます。
- Parameters テキストボックスにコマンドライン引数を入力します。新しい引数はそれぞれ name=value; の形式を持ち、新しい行に追加されます。変数の値に構文のプロパティーが含まれる場合
%propertyName%
、JBoss ON は値をスクリプトの親リソースの接続プロパティーから対応するプロパティーの現在の値として解釈します。 - にあるように操作の設定を終了し 「スケジューリング操作」 ます。
11.2.6. 操作タイムアウトのデフォルトの設定
rhq-server.properties
ファイルを開きます。vim serverRoot/jon-server-3.3.0.GA/bin/rhq-server.properties
rhq.server.operation-timeout
パラメーターの値を、動作が終了するまでサーバーが待機する時間(秒単位)に変更または追加します。rhq.server.operation-timeout=60
11.2.7. 操作履歴レポート
図11.2 操作履歴レポート
configurationHistory.csv
ます。
第12章 サマリー: JBoss ON を使用したリソース設定の変更
- リソース設定を直接編集します。JBoss ON UI は、JBoss ON UI を使用してさまざまな管理リソースの設定ファイルを編集できます。
- リソース設定の変更を監査および元に戻します。サポートされるリソースに対して JBoss ON が管理する特定の設定ファイルでは、設定プロパティーに対する個別の変更を確認し、以前のバージョンに戻すことができます。
- 設定のドリフトを定義して監視します。システム設定は、特定の設定ファイルの特定の設定プロパティーよりも、より詳細なエンティティーです。アプリケーションの複数のファイルまたはプラットフォーム全体が連携して、最適な設定が作成されます。ドリフト は、その最適な設定から分析される(不可欠)差です。ドリフト管理を使用すると、希望するベースラインの設定を定義し、そのベースラインからのすべての変更を追跡できます。
12.1. 簡単で構造化の設定
key1 = value1 key2 value2
<default-configuration> <ci:list-property name="my-list"> <c:simple-property name="element" type="string"/> <ci:values> <ci:simple-value value="a"/> <ci:simple-value value="b"/> <ci:simple-value value="c"/> </ci:values> </ci:list-property> </default-configuration>
図12.1 Samba サーバーの設定フォーム
- UI で設定されるプロパティーの形式には、即時検証があります。
- すべての設定変更の監査証跡は、外部および JBoss ON-initiated 設定変更のリソース履歴で表示できます。
- 設定変更は、エラーが発生した場合に以前の安定した状態に戻すことができます。
- 設定変更は、同じタイプのリソースのグループに対して行うことができるため、複数のリソース(異なるマシンでも含む)を同時に変更することができます。
- アラートは、設定変更の自動通知を送信するか、設定の変更時に、関連するリソースで操作またはスクリプトを開始する場合に、設定の変更と併せて使用できます。
- アクセス制御ルールは設定変更に有効であるため、JBoss ON ユーザーは特定のリソースの変更を表示または開始できません。
12.2. 変更可能な設定プロパティーの特定
図12.2 設定タブ
12.3. リソース設定の変更の監査および取り消し
12.4. 設定項目の追跡
- 誤差は、追加/削除されたファイルやバイナリーファイルなど、ディレクトリー内のファイル全体を調べます。
- drift は、ドリフトの監視をサポートするすべてのリソースに適用できるユーザー定義のテンプレートをサポートします。
- drift は、各変更セット(snapshot)が以前の一連の変更と比較される変更履歴を継続的に保持できます。JBoss ON では、定義されたベースラインスナップショットに対する各変更を比較できます。
- システムパスワードの変更
- システム ACL の変更
- データベースおよびサーバーの URL の変更
- JBoss の設定変更
- アプリケーションによって使用される JAR、WAR、およびその他のバイナリーファイルが変更されました。
- スクリプトの変更
第13章 リソースの設定変更
13.1. 単一リソースの設定変更
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースの Configuration タブを開きます。
- Current サブタブをクリックします。
- フィールドを編集するには、Unset チェックボックスが選択されて いない ことを確認してください。この Unset チェックボックスは、JBoss ON がそのリソースの値を送信せず、すべての値がリソース自体から取得されることを意味します。次に、設定を変更します。使用できる設定プロパティーと説明は、リソース 『リファレンスのリソースタイプ(Monitoring、Operation、および Configuration Options)』 ごとに一覧表示されます。
- プロパティーリストの上部にある Save ボタンをクリックします。
13.2. 互換性のあるグループの設定変更
- グループメンバーはすべて同じリソースタイプである必要があります。
- すべてのグループメンバーリソースが利用可能である必要があります(UP)。
- グループまたはそのメンバーリソースの他の設定更新要求を続行することはできません。
- 現在のメンバー設定はエージェントから正常に取得される必要があります。
- トップメニューの Inventory タブをクリックします。
- 左側のメニューの Groups ボックスで、Compatible Group リンクを選択します。
- 編集するグループを選択します。
- Configuration タブを開きます。
- Current サブタブをクリックします。
- フィールドを編集するには、Unset チェックボックスが選択されて いない ことを確認してください。この Unset チェックボックスは、JBoss ON がそのリソースの値を送信せず、すべての値がリソース自体から取得されることを意味します。次に、設定を変更します。使用できる設定プロパティーと説明は、リソース 『リファレンスのリソースタイプ(Monitoring、Operation、および Configuration Options)』 ごとに一覧表示されます。注記フォームを直接編集することで、すべてのメンバーの設定を変更することはできますが、グループメンバーのサブセットの設定を変更することもできます。緑色の鉛筆アイコンをクリックして、メンバーの設定を個別に変更します。
- フォームの上部にある Save ボタンをクリックします。
13.3. スクリプト環境変数の編集
- トップメニューの Inventory タブをクリックします。
- スクリプトリソースを検索します。
- スクリプトリソースの Configuration タブを開きます。
- プラス記号(+)をクリックして、環境変数を追加します。
- 環境変数を入力します。新しい環境変数はそれぞれ name=value; の形式を持ち、新しい行に追加されます。変数の値に構文のプロパティーが含まれる場合
%propertyName%
、JBoss ON は値をスクリプトの親リソースの接続プロパティーから対応するプロパティーの現在の値として解釈します。 - 環境変数をリセットしたら、JBoss ON エージェントを再起動して変更を伝播します。エージェントが再起動しないと、設定が正しい場合でも、新しい変数はリソースに伝播されず、スクリプトの実行時に解決されません。
@echo off
に行を追加して、実行結果と共に実行したコマンドの echo を防ぎます。
13.4. Configuring Apache for Configuration Management(非推奨)
13.4.1. Apache Configuration Management に関する考慮事項および注意事項
非推奨の Augeas プラグイン
Apache 設定管理は、Linux インスタンス上の Augeas lens に接続し、管理する特別な Augeas エージェントプラグインを使用してサポートされます。Augeas エージェントプラグインは JBoss ON 3.1.1 で非推奨となり、今後のリリースで削除される可能性があります。
Augeas and Apache Monitoring
Apache 監視には Augeas lens は必要ありません。これは Apache 設定管理にのみ使用されます。Apache リソースは、アラート、操作、およびその他の管理タスクを、追加設定なしで監視できます。Augeas lens は、JBoss ON 経由で Apache 設定ファイルおよび仮想ホストを編集する場合にのみ使用されます。
Apache 設定でサポートされるプラットフォーム
Apache 設定管理は、Linux にインストールされる Apache インスタンスでのみサポートされます。
Apache ディレクトリーの noexec オプションの無効化
/tmp
ディレクトリーが fstab
ファイルに設定されて noexec いる場合、Augeas lens を適切に初期化できないため、エージェントは例外が発生します。この場合、Configuration タブは Apache リソースで利用できません。
/tmp
ディレクトリーがオプションとして noexec 設定されていないことを確認します。
#
# /etc/fstab
#
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
13.4.2. 設定管理の有効化
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、Apache リソースを検索します。
- Apache インスタンスの IP アドレスをクリックします。
- Inventory タブを開き、Connections サブタブをクリックします。
- Augeas Configuration セクションに移動します。
- Augeas lens を有効にするには、Yes ラジオボタンを選択します。
第14章 リソース設定の変更の追跡
14.1. 設定変更の追跡および比較
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースの Configuration タブを開きます。
- History サブタブをクリックします。
- 表示または比較する設定バージョンの行を選択します。Ctrl キーを使用して複数のバージョンを選択します。現在の(最新の成功)設定状態は、緑色のチェックマークが付いています。
- Compare ボタンをクリックします。
- ポップアップウィンドウには、ディレクトリースタイルレイアウトの変更がすべて表示され、各設定エリアはハイレベルディレクトリーになります。変更はすべて red で示され、選択されたバージョンごとに値が表示されます。
14.2. 設定変更を元に戻す
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースの Configuration タブを開きます。
- History サブタブをクリックします。
- ロールバックする設定バージョンの行を選択します。現在の(最新の成功)設定状態は、緑色のチェックマークが付いています。
- Rollback ボタンをクリックします。
14.3. 設定履歴レポートの表示
図14.1 設定履歴レポート
configurationHistory.csv
ます。
第15章 設定項目の管理
15.1. 誤差について
- ドリフト監視に関連するディレクトリー(およびそれらのディレクトリー内のファイル)リソースにドリフト定義が定義されていても、実際のドリフト検出はディレクトリーレベルで実行されます。ドリフト監視は、JBoss ON によって管理される外部でも、プラットフォーム上の任意の場所に移動できます。
- 変更の特定方法これを、作成前のバージョン、または確立されたベースラインと比較するか。
15.1.1. ドリフト定義および検出
- プラグイン設定(pluginConfiguration)から。つまり、リソースの接続プロパティーから取得できます。接続プロパティーには、リソースタイプに応じてログファイル、デプロイメントディレクトリー、およびインストールディレクトリーを含めることができます。
- リソース設定(resourceConfiguration)から。つまり、リソースの設定可能なプロパティーから取得できます。
- 特性(measurementTrayt)から。特性は、リソースの情報測定プロパティーです。
- 明示的なファイルシステムの場所。リソースプロパティーに適切な場所がない場合や、ドリフトに別の場所を使用する場合は、ディレクトリーを fileSystem プロパティーに指定できます。
*.conf
ファイルの変更のみ /etc/
が含まれる場合、drift 定義の要素は以下のようになります。
Value context: fileSystem Value name: /etc Includes: **/*.conf
表15.1 特定のファイルを含めるための組み合わせ
Drift をモニターするファイル | 'includes' パス | 'includes' パターン |
---|---|---|
/etc およびそのすべてのサブディレクトリー | blank | blank |
/etc およびすべてのサブディレクトリーの *.conf ファイルの場合 | . | **/*.conf [a] |
*.conf ファイルについては、/etc ディレクトリーでのみ、サブディレクトリーがない(/etc/*.conf) | . | *.conf |
*.conf ファイルについては、/etc(/etc/*/*.conf)未満のサブディレクトリーでのみ使用されます。 | できない | できない |
/etc の下にある特定のサブディレクトリー(yum.repos.d/)にあるファイル | yum.repos.d(サブディレクトリー名) | blank |
[a]
ディレクトリーの部分には、2 つのアスタリスクが必要です。1 つのアスタリスクでは機能しません。
|
15.1.2. スナップショット、ターミナルイメージ、およびベースラインイメージ
- これは、ファイルの最新のバージョンと比較できます。
- これは、定義した安定したベースラインと比較できます。
図15.1 ローリングスナップショット
図15.2 ピニングされたスナップショット
15.1.3. 特殊なファイル種別を含む宛先のディレクトリー
ln -ls /home/dev/libs /usr/share/jbossas/server/libs
libs/
ディレクトリーのディレクトリーにドリフトが設定されている場合は、シンボリックリンクにしたがって /home/dev/libs
、ドリフトスナップショットにすべてのファイルを含めます。
表15.2 ドリフト定義および Unix ファイルタイプ
ファイルタイプ | Drift でサポートされますか? |
---|---|
file | ◯ |
ディレクトリー | ◯ |
シンボリックリンク | ◯ |
pipe | いいえ |
Socket | いいえ |
device | いいえ |
15.1.4. ドリフトおよびリソースタイプ
rhq-plugin.xml
記述子に定義されている場合、そのリソースタイプは drift をサポートします。テンプレートは開始点です(アラートまたはメトリクスコレクションテンプレートなどの強制された設定ではありません)。
- すべてのプラットフォーム
- JBoss EAP 6(AS 7)および JBoss AS 5 プラグインを使用するすべてのリソース
- JBoss AS/EAP 5、および JBoss AS 5 プラグインを使用するすべてのリソース
- JBoss AS/EAP 4(非推奨)
15.1.5. ドリフト監視の領域の考慮事項
- 監視するディレクトリーのサイズ。状況によっては、大規模なディレクトリーが 1 つではなく、複数の小さなサブディレクトリーを監視する方が望ましい場合があります。
- ドリフト検出の実行頻度。変更をキャプチャーする必要とバックアップコピーの数を分散します。
- ドリフトスナップショットの保存期間。デフォルトでは、未使用のスナップショット(ピニングされていないスナップショット)は 31 日間保存され、その後削除されます。スナップショットの保存期間を変更すると、データベースサイズを管理するのに役に立ちます。
15.1.6. Drift モニタリングに戻る
drift Monitoring
ドリフト監視は、ターゲットの場所への変更を追跡する機能です。JBoss ON GUI を使用すると、スナップショットをすべて表示し、スナップショット間で個々のファイルの変更を比較し、現在の設定を表示し、変更の詳細を表示できます。また、インベントリーおよびドリフトレポートも提供し、リソースが関連付けられたピニングされたスナップショットに準拠しているかどうかを一目で示します。
ドリフトアラート
ドリフトが発生するたびにアラートをトリガーする特定のアラート状態が存在する。ローリングスナップショットの場合、分散スナップショットごとにアラートが 1 度(および 1 回のみ)送信されます。ピニングされたスナップショットでは、後続の変更がない場合でも、リソースがコンプライアンス不足であっても、検出が実行されるたびに誤差アラートが発生します。
15.2. リソースのドリフト定義の追加
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースの Drift タブを開きます。
- 下をクリックし New て新しい定義を追加します。
- 新規定義のベースとして使用するテンプレートを選択します。プラグイン定義のテンプレートは、プラットフォームおよび JBoss サーバーリソースと、ドリフトモニタリングをサポートするその他のリソースで定義されます。ユーザー定義のテンプレートも作成および適用できます。
- 定義に一意の名前を指定します。name と base ディレクトリーは組み合わされ、JBoss ON 内で定義が特定されます。
- 間隔やテンプレートに関連付けられているかどうかなど、定義の設定を定義します。プロパティーはに一覧表示され 表15.3「ドリフト定義プロパティー」 ます。
- ベースディレクトリーを設定します。これは、定義に対してドリフト検出が実行される最上部のディレクトリーで、スキャンが再開します。テンプレート自体は初期ディレクトリーを定義しますが、より具体的なディレクトリーを設定すると便利な場合があります。
- 緑色のプラス(+)記号の付いたボタンをクリックして、include または exclude のサブディレクトリーを追加します。ディレクトリーは、ピリオド(.)をディレクトリーとして指定して、ベースディレクトリーにすることができます。パターンは、明示的に含めるか、または明示的に除外するサービスで、サービスによって認識するディレクトリー内のファイルを特定します。このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。たとえば、を使用して、任意のサブディレクトリーに
.conf
ファイルのみを含める **/*.conf ことができます。include/exclude フィルターは複数になる可能性があります。各ディレクトリーとパターンは個別に追加できます。
表15.3 ドリフト定義プロパティー
property | description |
---|---|
Name | ドリフト検出定義の名前。名前とベースディレクトリーは、定義を一意に識別します。 |
ベースディレクトリー: 値コンテキスト |
ベースディレクトリーの特定に使用される設定プロパティーのタイプ。これは、リソースの要素のタイプを特定し、値を提供します。以下の 4 つのオプションがあります。
|
ベースディレクトリー: 値名 | ベースディレクトリーコンテキストに使用するドリフト検出定義の実際の値。たとえば、ファイルシステムコンテキストの場合、値はディレクトリーパスになります。 |
includes |
誤差検出に、パターン(ベースディレクトリーとの関連)に一致するディレクトリー、ファイル、またはファイルおよびディレクトリーを明示的に含めます。
このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。
パターンを使用する場合は、パスがベースディレクトリーであっても、パスを指定する必要があります。たとえば、ベースディレクトリーに
.conf ファイルのみを含めるには、パターン *.conf とパスがローカルディレクトリーを示すピリオド(. )になります。
|
excludes |
誤差検出から、ベースディレクトリーに対して相対的なパターンに一致するディレクトリー、ファイル、またはファイルおよびディレクトリーを明示的に除外します。
このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。
パターンを使用する場合は、パスがベースディレクトリーであっても、パスを指定する必要があります。たとえば、ベースディレクトリーに
.conf ファイルのみを含めるには、パターン *.conf とパスがローカルディレクトリーを示すピリオド(. )になります。
|
enabled | 定義を有効または無効にします。定義を無効にすると、検出スキャンは実行されません。 |
interval | 定義が検出実行の対象となる頻度を秒単位で設定します。これはハード設定ではありません。エージェントの負荷やその他のスケジュールされた操作により、検出の実行は指定された間隔で実行することが保証されていません。 |
pinned |
誤差がローリング方式で決定されるかどうか、またはベースラインスナップショットと関連付けられる(ピニング)されるかどうかを設定します。定義の作成時にこれを設定すると、初期スナップショットがベースラインとして使用されます。
ピニングされたテンプレートにアタッチされている定義はピニング解除できません。ピニングされていないテンプレート、またはテンプレートにアタッチされていない定義は、ピニングされたり、ピニングされていない状態にすることができます。
|
ドリフト処理モード | 誤差の変更がアラート(デフォルト)または予想通りにトリガーされるイベントとして処理されるかどうかを設定します。これにより、アラートがトリガーされないようにします。 |
テンプレートに添付 |
リソースレベルの定義がテンプレートに従属するかどうかを指定します。テンプレートにアタッチされている場合には、テンプレートが削除された場合など、テンプレートへの変更がリソース定義に反映されます。
デフォルトでは、定義は作成されたテンプレートに割り当てられます。
|
description | 定義の簡単な説明。 |
15.3. 誤差定義テンプレートの作成
15.3.1. リソースおよびドリフト定義テンプレートについて
例15.1 JBoss Server 誤差定義テンプレート
<drift-definition name="Template-Base Files" description="Monitor base application server files for drift. It defines monitoring for some standard sub-directories of the HOME directory. Note, it is not recommeded to monitor all files for an application server. There are many files, and many temp files."> <basedir> <value-context>pluginConfiguration</value-context> <value-name>homeDir</value-name> </basedir> <includes> <include path="bin" /> <include path="lib" /> <include path="client" /> </includes> </drift-definition>
- 誤差テンプレート は、JBoss ON の他のテンプレートタイプとは異なり、リソースに自動的に適用されません。誤差テンプレートは、リソースレベルの定義を作成するためのベースとして使用されます。
- デフォルトのドリフトテンプレートは、プラグイン記述子の一部としてリソースに対して定義されます。カスタムのユーザー定義のテンプレートは、これらのデフォルトと共に追加できます。
- 誤差の定義は、作成後のテンプレートにアタッチされていなくても、すべてのドリフト定義は最初にテンプレートに基づいています。
- スナップショット(ドリフト定義に関連付けられたファイルセット)は、常にドリフト定義のリソース上で開始されます。テンプレートに関連付けるコンテンツには、リソースレベルのスナップショットをテンプレートにプロモートする必要があります。ドリフトテンプレートは、スナップショットやファイルを生成しず、リソースにプッシュします。
15.3.2. 誤差定義テンプレートの作成
- トップメニューの Administration タブをクリックします。
- 左側の Drift Definition Templates メニューテーブルを選択します。
- リソースタイプの鉛筆アイコンをクリックしてテンプレートを追加します。すべてのリソースがドリフトに対応しているわけではないため、選択することはできません。
- 下をクリックし New て、新しいテンプレートを追加します。
- 新規テンプレートのベースとして使用するテンプレートを選択します。プラグイン定義のテンプレートは、プラットフォームおよび JBoss サーバーリソースと、ドリフトモニタリングをサポートするその他のリソースで定義されます。ユーザー定義のテンプレートも作成および適用できます。
- テンプレートに一意の名前を付けます。name と base ディレクトリーは組み合わされ、JBoss ON 内で定義が特定されます。
- 定義の設定(間隔、デフォルトで有効かどうか)を定義します。プロパティーはの表に一覧表示され 「リソースのドリフト定義の追加」 ます。
- ベースディレクトリーを設定します。これは、定義に対してドリフト検出が実行される最上部のディレクトリーで、スキャンが再開します。
- 緑色のプラス(+)記号の付いたボタンをクリックして、include または exclude のサブディレクトリーを追加します。ディレクトリーは、ピリオド(.)をディレクトリーとして指定して、ベースディレクトリーにすることができます。パターンは、明示的に含めるか、または明示的に除外するサービスで、サービスによって認識するディレクトリー内のファイルを特定します。このフィルターは、パスとパターンを使用して Ant のような FilePatterns をサポートします。このパターンは、任意の数の文字と単一文字ワイルドカード(?)のワイルドカードとしてアスタリスク(*)をサポートします。たとえば、を使用して、任意のサブディレクトリーに
.conf
ファイルのみを含める **/*.conf ことができます。
15.4. 誤差定義の編集
15.5. スナップショットの変更の表示
15.5.1. スナップショットの作成
図15.3 スナップショットの表示
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- リソースの Drift タブをクリックします。
- ドリフト定義の名前をクリックします。
- スナップショットキャレットには、デフォルトで 4 つの最新のスナップショットが表示されます。
- 必要に応じて、表示するスナップショットをフィルターします。スナップショットの検索に使用できる要素は 2 つあります。
- ファイルの追加、削除、または変更に関わらず、スナップショット内の変更タイプです。
- スナップショット内の変更のパス。このパスフィルターは、ドリフトエントリー内のパスとファイルに基づくサブ文字列フィルターです。
15.5.2. 誤差変更の比較
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- リソースの Drift タブをクリックします。
- ドリフト定義の名前をクリックします。
- 比較するファイルの名前をクリックします。
- をクリックし Compareます。
図15.4 セットの違いの変更
15.5.3. スナップショットの詳細表示
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- リソースの Drift タブをクリックします。
- ドリフト定義の名前をクリックします。
- スナップショットのサイズで、表示するスナップショットの名前で虫眼鏡をクリックします。
- ディレクトリーを展開して、そのスナップショットの変更の一覧を表示します。
- 特定の変更の詳細を表示するには、(view) リンクをクリックします。
- このファイルの詳細には、ファイルの直前のバージョン、ファイルの変更バージョン、および 2 つのファイル間の diff を表示するリンクが表示されます。view リンクをクリックすると、ページタイトルとファイル名が表示されます。たとえば、のバージョン 6 を表示する場合は
myfile.txt
、タイトルは myfile.txt:6 になります。
15.5.4. タイムラインでのドリフトイベントの表示
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- Summary タブで Timeline サブタブをクリックします。
- 検出は、のタイムラインでドリフトが検出された場合に実行され Drift Detectedます。タイムラインでドリフトイベントのみを表示するには、チェックボックス以外のすべてをクリアし Drift ます。期間をリセットして、タイムラインの期間を調整できます。
15.5.5. 誤差スナップショットレポートの確認
- 上部の Reports ナビゲーションメニューのタブをクリックします。
- レポートリストから Recent Drift Subsystems レポートを選択します。
- すべてのドリフトインスタンスが一覧表示され、スナップショットの作成時間別にソートされます。
- 必要に応じて、ドリフト変更の一覧をフィルタリングします。フィルターオプションは 4 つあります。
- 定義名
- スナップショット番号(ドリフト定義にまたがる)
- ファイルの追加、削除、または変更に関わらず、スナップショット内の変更タイプです。
- スナップショット内の変更のパス。このパスは、ディレクトリー、ファイル名、検索式のいずれかです。
recentDrift.csv
ます。
15.6. スナップショットのピニングとコンプライアンスの管理
15.6.1. Pinning スナップショットの詳細
- そのスナップショットの前に作成されたスナップショットを削除します。たとえば、管理者はスナップショット 7 のピニングを決定し、スナップショット 6 を介してスナップショット 0(初期イメージ)はすべて削除され、スナップショット 7 が新しいスナップショット 0 になります。
- 変更の移動集計ではなく、すべての変更と比較するベースラインイメージが作成されます。
- システム設定が固定されたスナップショットに準拠するまでアラートが継続的に送信されるように、ドリフトアラート(「ドリフトアラートの定義」)の動作を変更します。
- スナップショットのピニングを解除するまで、固定されている定義は削除できません。
- スナップショットがテンプレートに固定されている場合は、そのテンプレートに割り当てられるリソースレベルの定義はすべて、ピニングされたスナップショットをベースラインとして自動的に使用します。
- スナップショットのピニング後に追加された新規ファイル(またはファイルの削除)は、後続のスナップショットごとに新規ファイルとして報告されます。これは、新規スナップショットは常にベースラインのスナップショットと比較されるため、ファイルは常にベースラインに新しいものになります。drift で同じ変更が報告されないようにするロジックがあります。追加すると、エージェント
file1.txt
はスナップショット 1 を作成します。エージェントが次の検出を実行する場合、これfile1.txt
はベースラインに含まれていないことを認識しますが、変更さfile1.txt
れていない限り、エージェントは新しいドリフトとしてこれを報告せず、新しいスナップショットを作成しません。ただし、変更が加えられた場合、エージェントfile1.txt
は新しい SHA を認識し、変更したスナップショットを新規ファイルとして送信します。これは、以前のバージョンではなくベースラインと比較file1.txt
されるためです。
15.6.2. When to a Resource and When to a Template
- スナップショットをリソースレベル定義にピニングすると、そのリソースのベースラインが作成されます。これは、理想のベースラインイメージや、他のリソースに移行しない一意の環境では、引き続き理にかなっています。リソース定義にピニングすることで、多くの柔軟性が得られます。ピニングおよびアンピン解除して、新しいスナップショットをベースラインとして簡単に選択し、変更が含まれているため、ドリフトイベント、アラート、およびモニタリングへの影響を最小限に抑えた理想的な設定を開発することができます。
- スナップショットをテンプレートに固定すると、そのテンプレートを使用するすべてのリソースにベースラインを適用でき、1 つのスナップショットを複数のリソースに適用できるようになります。これは、あらゆる種類の繰り返し可能な設定エリアと、一貫した設定が必要となる実稼働または重要なシステムでは理にかなっています。テンプレートへのピニングは、理想的な設定が開発されると、インフラストラクチャー全体で一貫性を維持する非常に強力なものです。
15.6.3. リソースレベルの定義へのピニング
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- Drift タブをクリックします。
- ドリフト定義の名前をクリックします。
- スナップショットのキャレットで、ピン留めするスナップショットの名前で虫眼鏡をクリックします。注記最初のスナップショットは、carousel には表示されません。初期スナップショットを固定するには、ドリフト定義一覧の Pinned コラムにあるサムネックアイコンをクリックします。これにより、初期スナップショットが開きます。スナップショットがすでにピニングされている場合は、サムネックアイコンをクリックすると、ピニングされたスナップショットが開きます。
- 変更リストの下部にある Pin to Definition ボタンをクリックします。
15.6.4. テンプレートへのピニング
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- Drift タブをクリックします。
- ドリフト定義の名前をクリックします。
- スナップショットのキャレットで、ピン留めするスナップショットの名前で虫眼鏡をクリックします。注記最初のスナップショットは、carousel には表示されません。初期スナップショットを固定するには、ドリフト定義一覧の Pinned コラムにあるサムネックアイコンをクリックします。これにより、初期スナップショットが開きます。スナップショットがすでにピニングされている場合は、サムネックアイコンをクリックすると、ピニングされたスナップショットが開きます。
- 変更リストの下部にある Pin to Template ボタンをクリックします。
- リソースレベルのテンプレートが既存のテンプレートをベースまたは割り当てられている場合には、スナップショットを既存のテンプレートに関連付けることができます。リソースレベルのスナップショットのベースディレクトリーが既存のドリフトテンプレートと一致しない場合は、新しいテンプレートを作成する必要があります。
- にあるように、drift テンプレートを作成し 「誤差定義テンプレートの作成」 ます。
15.6.5. 誤差コンプライアンスレポートの確認
- 上部の Reports ナビゲーションメニューのタブをクリックします。
- レポートリストから Drift Compliance Inventory レポートを選択します。
- ドリフト定義を持つすべてのリソースは、タイプおよびアイコンで一覧表示さ れ、それが準拠しているかどうかを確認します( )またはコンプライアンス違反( ).
- 特定のリソースに関する情報を取得するには、リソース種別名をクリックします。これにより、メインレポートの下に 2 番目のインベントリーレポートが開きます。このタイプのすべてのリソースは、コンプライアンス状態で一覧表示されます。
driftCompliance.csv
ます。
15.6.6. スナップショットのピニング解除
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- Drift タブをクリックします。
- ドリフト定義のピンアイコンをクリックします。
15.7. 拡張例: 必要な EAP 設定の定義
設定
Tim the IT Guy at Example Corp. には、実稼働環境で稼働中の EAP サーバーが 1 つあります。実稼働環境の負荷により、EAP サーバーは通常のメモリーが不足していたため、パフォーマンスが低下し、Example Corp. の Web サイトのダウンタイムが発生していました。
操作方法
Tim は、EAP のパフォーマンスを維持したい 3 つの要素があります。
- EAP インスタンスに一貫して設定を適用する方法を見つけます。JBoss EAP インスタンス(「誤差定義テンプレートの作成」)のテンプレートを定義します。一貫性を維持するために、テンプレートは Attach to template 値を true に設定し、各リソースレベルのドリフト定義はその設定を保持します。これにより、テンプレートへの変更が JBoss リソースずれの定義に自動的に適用されます。
- 現在の実稼働設定を、今後の EAP インスタンスのベースとして使用します。テンプレート定義(「テンプレートへのピニング」)により高いヒープ設定で最新のスナップショットをピニングします。すべての EAP インスタンスがそのベースラインと比較されます。したがって、誤ったヒープ設定を持つものはすべて、即座にコンプライアンスから除外されます。
- 現在の EAP 設定と希望の設定の相違点に注意してください。これは、とくに
bin/run.conf
ファイルをターゲットとするアラート定義(「ドリフトアラートの定義」)を作成します。これにより、ヒープ設定およびその他の JVM 設定が新規インスタンスで間違っているかどうかを正確に認識します。CLI スクリプトを使用して現在の EAP 設定をピニングされたスナップショットと比較し、diff を送信するなど、アラートを使用して EAP インスタンスの設定の方法に関する詳細情報を取得することもできます。
予想される結果
Tim は新しいサーバーをオンラインにし、実稼働環境用の新しい EAP インスタンスを提供します。誤差テンプレートを新しいリソースに適用し、数分以内に、希望の設定に準拠し run.conf
ていないという通知を受け取ります。パフォーマンスの低下が変更を書き込むまで待機せずに、新しい EAP インスタンスのヒープ設定を変更します。
15.8. ドリフトアラートの定義
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- 一覧のリソース名をクリックします。
- リソースの Alerts タブをクリックします。
- Definitions サブタブで New ボタンをクリックして新しいアラートを作成します。
- General Properties タブで、アラートに関する基本情報を指定します。誤差定義に重要な設定ファイルが含まれている場合は、優先度 を設定すると便利です。
- Conditions タブで、conditions 一覧から Drift Detection オプションを選択します。すべてのドリフト変更にアラートを使用するには、フィールドを空白のままにしておきます。それ以外の場合は、特定のドリフト定義名と(任意)アラートをトリガーするために変更する必要のあるディレクトリーまたはファイルを入力します。注記複数の条件セットを使用してアラートをトリガーすることができます。つまり、複数のドリフト定義またはファイルに同じアラートを使用できます。
- Notifications タブで Add をクリックし、アラートの通知を設定します。Sender オプションでアラート通知を送信するために使用する方法を選択し、必要な情報を入力します。Sender オプションは、最初に特定のタイプのアラートメソッド(電子メールや SNMP など)を設定し、適切なフォームを開いてその方法の詳細を入力します。
- 必要に応じて、Dampening タブで、ドリフトの通知を送信する頻度について、mensepening(または頻度)ルールを指定します。注記ピニングされたスナップショットの場合は、ドリフトの問題を修正する前にアラートがあふれるのを防ぎます。破損は、固定のスナップショットを使用した定義のみに限定されます。ピニングされた定義は、追加の変更がない場合でも、コンプライアンス不足である限り、すべてのアラートスキャン(すべてのアラートスキャンすべて)でアラートを出力します。ローリング定義は、ドリフトが検出されるとアラートが一度だけ実行されます。破損ルールのいずれかを使用できます。最適なゴールは、固定された定義を満たさないリソースに対して同じアラートが設定された回数を制限することです。たとえば、期間は、アラート条件が発生した場合にアラートが発行される期間に制限を設定します。発生を 1 に、かつ 4 時間に設定すると、ドリフトが 1 回検出されると、サーバーはアラートを送信してから次の 4 時間待機してから次のアラートを送信します。
- OK をクリックし、アラート定義を保存します。
15.9. 拡張例: バンドルおよびサーバースクリプトを使用した元の設定に戻す
設定
では 「拡張例: 必要な EAP 設定の定義」、Tim the IT Guy が例に記載されています。ずれのテンプレートとアラートを設定して、実稼動の EAP サーバーでの設定を管理します。ただし、解決は手動で行われました。誤差アラートが EAP サーバーがコンプライアンス不足であることを通知すると、ヒープサイズを調整するために run.conf
直接編集しました。
操作方法
この目的は、Tim(IT 管理者)からのアクションを必要とせずに、JBoss ON がドリフトに対してインテリジェントに応答することが目的です。自動応答を許可する 2 つの機能があります。
- バンドル を使用して、更新されたファイルまたはアプリケーションをプロビジョニングします。バンドルは、Ant レシピと、アプリケーションに必要なコンテンツ(設定ファイルや JAR など)を含む ZIP ファイルです。JBoss ON では、指定のディレクトリーにあるプラットフォームまたは JBoss サーバーにこのコンテンツをプロビジョニングできます。
- アラートの応答で JBoss ON CLI スクリプトを起動します。可能なアラート通知の 1 つがサーバー側のアラート送信者です。JBoss ON CLI スクリプトはコンテンツとしてロードされ、JBoss ON サーバーに保存されます。アラートが発生すると、指定の保存された CLI スクリプトが開始されます。
- ピニングされたスナップショット設定に基づいてバンドルファイルを作成します。バンドルの内容は、デプロイメントのニーズにより異なります。この設定ファイルには、のような特定の設定ファイルを使用でき
bin/run.conf
、完全な EAP サーバーになります。注記バンドルに完全な EAP サーバーが含まれている場合は、初期 EAP サーバーの作成に使用できます。 - バンドルを完全な EAP サーバーと共にデプロイし、新しい EAP インスタンスを作成します。または、バンドルに設定ファイルのみが存在する場合は EAP インスタンスを作成します。
- 新しい EAP インスタンス用に、以前に設定したテンプレート(「拡張例: 必要な EAP 設定の定義」)に基づいてドリフト定義を設定します。
- 指定されたバンドルを適切な宛先に自動的にデプロイする JBoss ON CLI スクリプト(JavaScript で)を作成します。の例は次のとおりです 例15.2「fix-eap.js スクリプト」。そのスクリプトでは、
destinationId
およびbundleVersionId
を JBoss ON の宛先エントリーおよびバンドルバージョンエントリーの実際の ID 番号に置き換えます。 - ドリフト検出条件でトリガーされ、作成した JavaScript ファイルを参照する CLI スクリプト通知タイプを使用するアラート定義を作成します。
予想される結果
EAP サーバーでドリフトが検出されると、にあるようにアラートがトリガーされ 「拡張例: 必要な EAP 設定の定義」 ます。この場合、アラートは CLI スクリプトを応答して起動し、承認された EAP 設定がすでにあるバンドルをリソースに自動的にデプロイします。つまり、EAP サーバーはコンプライアンスから数分以上発生せず、1 つのアラートスキャンの長さが大きくなります。IT 保証Tim の介入なしにすべて。
例15.2 fix-eap.js スクリプト
/** * If obj is a JS array or a java.util.Collection, each element is passed to * the callback function. If obj is a java.util.Map, each map entry is passed * to the callback function as a key/value pair. If obj is none of the * aforementioned types, it is treated as a generic object and each of its * properties is passed to the callback function as a name/value pair. */ function foreach(obj, fn) { if (obj instanceof Array) { for (i in obj) { fn(obj[i]); } } else if (obj instanceof java.util.Collection) { var iterator = obj.iterator(); while (iterator.hasNext()) { fn(iterator.next()); } } else if (obj instanceof java.util.Map) { var iterator = obj.entrySet().iterator() while (iterator.hasNext()) { var entry = iterator.next(); fn(entry.key, entry.value); } } else { // assume we have a generic object for (i in obj) { fn(i, obj[i]); } } } /** * Iterates over obj similar to foreach. fn should be a predicate that evaluates * to true or false. The first match that is found is returned. */ function find(obj, fn) { if (obj instanceof Array) { for (i in obj) { if (fn(obj[i])) { return obj[i] } } } else if (obj instanceof java.util.Collection) { var iterator = obj.iterator(); while (iterator.hasNext()) { var next = iterator.next(); if (fn(next)) { return next; } } } else if (obj instanceof java.util.Map) { var iterator = obj.entrySet().iterator(); while (iterator.hasNext()) { var entry = iterator.next(); if (fn(entry.key, entry.value)) { return {key: entry.key, value: entry.value}; } } } else { for (i in obj) { if (fn(i, obj[i])) { return {key: i, value: obj[i]}; } } } return null; } /** * Iterates over obj similar to foreach. fn should be a predicate that evaluates * to true or false. All of the matches are returned in a java.util.List. */ function findAll(obj, fn) { var matches = java.util.ArrayList(); if ((obj instanceof Array) || (obj instanceof java.util.Collection)) { foreach(obj, function(element) { if (fn(element)) { matches.add(element); } }); } else { foreach(obj, function(key, value) { if (fn(theKey, theValue)) { matches.add({key: theKey, value: theValue}); } }); } return matches; } /** * A convenience function to convert javascript hashes into RHQ's configuration * objects. * <p> * The conversion of individual keys in the hash follows these rules: * <ol> * <li> if a value of a key is a javascript array, it is interpreted as PropertyList * <li> if a value is a hash, it is interpreted as a PropertyMap * <li> otherwise it is interpreted as a PropertySimple * <li> a null or undefined value is ignored * </ol> * <p> * Note that the conversion isn't perfect, because the hash does not contain enough * information to restore the names of the list members. * <p> * Example: <br/> * <pre><code> * { * simple : "value", * list : [ "value1", "value2"], * listOfMaps : [ { k1 : "value", k2 : "value" }, { k1 : "value2", k2 : "value2" } ] * } * </code></pre> * gets converted to a configuration object: * Configuration: * <ul> * <li> PropertySimple(name = "simple", value = "value") * <li> PropertyList(name = "list") * <ol> * <li>PropertySimple(name = "list", value = "value1") * <li>PropertySimple(name = "list", value = "value2") * </ol> * <li> PropertyList(name = "listOfMaps") * <ol> * <li> PropertyMap(name = "listOfMaps") * <ul> * <li>PropertySimple(name = "k1", value = "value") * <li>PropertySimple(name = "k2", value = "value") * </ul> * <li> PropertyMap(name = "listOfMaps") * <ul> * <li>PropertySimple(name = "k1", value = "value2") * <li>PropertySimple(name = "k2", value = "value2") * </ul> * </ol> * </ul> * Notice that the members of the list have the same name as the list itself * which generally is not the case. */ function asConfiguration(hash) { config = new Configuration; for(key in hash) { value = hash[key]; if (value == null) { continue; } (function(parent, key, value) { function isArray(obj) { return typeof(obj) == 'object' && (obj instanceof Array); } function isHash(obj) { return typeof(obj) == 'object' && !(obj instanceof Array); } function isPrimitive(obj) { return typeof(obj) != 'object'; } //this is an anonymous function, so the only way it can call itself //is by getting its reference via argument.callee. Let's just assign //a shorter name for it. var me = arguments.callee; var prop = null; if (isPrimitive(value)) { prop = new PropertySimple(key, new java.lang.String(value)); } else if (isArray(value)) { prop = new PropertyList(key); for(var i = 0; i < value.length; ++i) { var v = value[i]; if (v != null) { me(prop, key, v); } } } else if (isHash(value)) { prop = new PropertyMap(key); for(var i in value) { var v = value[i]; if (value != null) { me(prop, i, v); } } } if (parent instanceof PropertyList) { parent.add(prop); } else { parent.put(prop); } })(config, key, value); } return config; } /** * Opposite of <code>asConfiguration</code>. Converts an RHQ's configuration object * into a javascript hash. * * @param configuration */ function asHash(configuration) { ret = {} iterator = configuration.getMap().values().iterator(); while(iterator.hasNext()) { prop = iterator.next(); (function(parent, prop) { function isArray(obj) { return typeof(obj) == 'object' && (obj instanceof Array); } function isHash(obj) { return typeof(obj) == 'object' && !(obj instanceof Array); } var me = arguments.callee; var representation = null; if (prop instanceof PropertySimple) { representation = prop.stringValue; } else if (prop instanceof PropertyList) { representation = []; for(var i = 0; i < prop.list.size(); ++i) { var child = prop.list.get(i); me(representation, child); } } else if (prop instanceof PropertyMap) { representation = {}; var childIterator = prop.getMap().values().iterator(); while(childIterator.hasNext()) { var child = childIterator.next(); me(representation, child); } } if (isArray(parent)) { parent.push(representation); } else if (isHash(parent)) { parent[prop.name] = representation; } })(ret, prop); } (function(parent) { })(configuration); return ret; } /** * A simple function to create a new bundle version from a zip file containing * the bundle. * * @param pathToBundleZipFile the path to the bundle on the local file system * * @return an instance of BundleVersion class describing what's been created on * the RHQ server. */ function createBundleVersion(pathToBundleZipFile) { var bytes = getFileBytes(pathToBundleZipFile) return BundleManager.createBundleVersionViaByteArray(bytes) } /** * This is a helper function that one can use to find out what base directories * given resource type defines. * <p> * These base directories then can be used when specifying bundle destinations. * * @param resourceTypeId * @returns a java.util.Set of ResourceTypeBundleConfiguration objects */ function getAllBaseDirectories(resourceTypeId) { var crit = new ResourceTypeCriteria; crit.addFilterId(resourceTypeId); crit.fetchBundleConfiguration(true); var types = ResourceTypeManager.findResourceTypesByCriteria(crit); if (types.size() == 0) { throw "Could not find a resource type with id " + resourceTypeId; } else if (types.size() > 1) { throw "More than one resource type found with id " + resourceTypeId + "! How did that happen!"; } var type = types.get(0); return type.getResourceTypeBundleConfiguration().getBundleDestinationBaseDirectories(); } /** * Creates a new destination for given bundle. Once a destination exists, * actual bundle versions can be deployed to it. * <p> * Note that this only differs from the <code>BundleManager.createBundleDestination</code> * method in the fact that one can provide bundle and resource group names instead of their * ids. * * @param destinationName the name of the destination to be created * @param description the description for the destination * @param bundleName the name of the bundle to create the destination for * @param groupName name of a group of resources that the destination will handle * @param baseDirName the name of the basedir definition that represents where inside the * deployment of the individual resources the bundle will get deployed * @param deployDir the specific sub directory of the base dir where the bundles will get deployed * * @return BundleDestination object */ function createBundleDestination(destinationName, description, bundleName, groupName, baseDirName, deployDir) { var groupCrit = new ResourceGroupCriteria; groupCrit.addFilterName(groupName); var groups = ResourceGroupManager.findResourceGroupsByCriteria(groupCrit); if (groups.empty) { throw "No group called '" + groupName + "' found."; } var group = groups.get(0); var bundleCrit = new BundleCriteria; bundleCrit.addFilterName(bundleName); var bundles = BundleManager.findBundlesByCriteria(bundleCrit); if (bundles.empty) { throw "No bundle called '" + bundleName + "' found."; } var bundle = bundles.get(0); return BundleManager.createBundleDestination(bundle.id, destinationName, description, baseDirName, deployDir, group.id); } /** * Tries to deploy given bundle version to provided destination using given configuration. * <p> * This method blocks while waiting for the deployment to complete or fail. * * @param destination the bundle destination (or id thereof) * @param bundleVersion the bundle version to deploy (or id thereof) * @param deploymentConfiguration the deployment configuration. This can be an ordinary * javascript object (hash) or an instance of RHQ's Configuration. If it is the former, * it is converted to a Configuration instance using the <code>asConfiguration</code> * function from <code>util.js</code>. Please consult the documentation of that method * to understand the limitations of that approach. * @param description the deployment description * @param isCleanDeployment if true, perform a wipe of the deploy directory prior to the deployment; if false, * perform as an upgrade to the existing deployment, if any * * @return the BundleDeployment instance describing the deployment */ function deployBundle(destination, bundleVersion, deploymentConfiguration, description, isCleanDeployment) { var destinationId = destination; if (typeof(destination) == 'object') { destinationId = destination.id; } var bundleVersionId = bundleVersion; if (typeof(bundleVersion) == 'object') { bundleVersionId = bundleVersion.id; } var deploymentConfig = deploymentConfiguration; if (!(deploymentConfiguration instanceof Configuration)) { deploymentConfig = asConfiguration(deploymentConfiguration); } var deployment = BundleManager.createBundleDeployment(bundleVersionId, destinationId, description, deploymentConfig); deployment = BundleManager.scheduleBundleDeployment(deployment.id, isCleanDeployment); var crit = new BundleDeploymentCriteria; crit.addFilterId(deployment.id); while (deployment.status == BundleDeploymentStatus.PENDING || deployment.status == BundleDeploymentStatus.IN_PROGRESS) { java.lang.Thread.currentThread().sleep(1000); var dps = BundleManager.findBundleDeploymentsByCriteria(crit); if (dps.empty) { throw "The deployment disappeared while we were waiting for it to complete."; } deployment = dps.get(0); } return deployment; } var destinationId = 10002; var bundleVersionId = 10002; var deploymentConfig = null; var description = "redeploy due to drift"; // NOTE: It's essential that isCleanDeployment=true, otherwise files that have drifted will not be replaced with their // original versions from the bundle. var isCleanDeployment = true; deployBundle(10002, 10002, deploymentConfig, description, true);
15.10. 手動でドリフト検出の実行
- トップメニューの Inventory タブをクリックします。
- リソースを検索します。
- Drift タブをクリックします。
- スキャンを実行するためにドリフト定義を選択します。
- Detect Now ボタンをクリックします。
15.11. 計画的な変更の設定またはドリフト定義の無効化
- 誤差処理モードを 計画変更 に設定します。これにより、ドリフト検出のスキャンおよび変更が記録されます。ただし、変更は想定されているため、ドリフト検出イベントはトリガーされないため、ドリフトアラートは発行されません。
- 実際 にドリフト定義を無効に します。これにより、ドリフトイベントだけでなく、定義に対してドリフト検出が実行されます。
図15.5 ドリフト処理モードおよびオプションの有効化
15.12. 長期リンクスナップショットの保存方法の変更
- Configuration メニューで System Settings 項目を選択します。
- Data Manager Configuration Properties セクションまでスクロールします。
- ドリフトスナップショットのストレージ時間を変更します。未使用のスナップショットは固定されておらず、孤立したスナップショットは無効化の定義に関連します。
15.13. ドリフトおよび JBoss ON エージェントおよびサーバーについて
15.13.1. drift Inventory
agentRoot/rhq-agent/data/
ディレクトリーに他のエージェントデータとともに保存されます。このディレクトリーの情報は、エージェントが新規設定(--cleanconfig
)で開始されたり、意図的にパージされた場合(--purgedata
)を削除します。ドリフト情報が失われると、エージェントは JBoss ON サーバーから最後のスナップショットを要求します。
15.13.2. ドリフトサーバープラグイン
パート III. 監視
第16章 リソースアクティビティーの監視と応答
16.1. データの監視および種類
- 可用性または「スケールダウン」の監視
- これは、basic と critical の両方です。可用性は、実行中または停止 状態であるかに関わらず、リソースのステータス 情報です。
- 数値メトリクス
- メトリックは、リソースのコアのパフォーマンスデータです。ほとんどのソフトウェア製品は、チェックできる測定可能なファセットに関する情報を公開します。通常、この数値の情報は JBoss ON によって定義されたスケジュールで収集されます。メトリック情報はサーバーによって処理されます。使用されるモニタリングデータの状態は 3 つあります。
- Raw データ。エージェントがスケジュールどおりに収集され、サーバーに送信される読み取りです。
- サーバーが処理したデータを 1 時間、6 時間、および 24 時間平均して集計 し、リソースのベースラインおよび通常の操作範囲を計算するために使用されます。これらの集計データはモニタリンググラフに表示される情報であり、メトリクスとして CLI で返されます。
- メトリクスの現在の値に対するアドホック要求であるライブ 値。メトリック値は、リソース状態のローリングライブストリームです。基本的に、エージェントが事前定義のスケジュールの読み取りを実行するスナップショットになります。その後、これらのデータは、リソースのパフォーマンスを追跡するのに使用する手段および平均に集約されます。ライブ値は、即時、集計、メトリクス値の現在の読み取りです。
メトリクス情報は特に重要になります。これは収集され、長期保存されるためです。これにより、リソースパフォーマンスに関する履歴ビューや最近のビューが可能になります。 - ログファイルメッセージ(イベント)
- JBoss ON はログビューアーではありませんが、指定のログを監視し、ログメッセージ内の重大度または文字列に基づいて重要なログメッセージの有無を確認できます。これは イベント 監視で、JBoss ON はリソースのインシデントを識別し、アラート通知を送信し、必要に応じて通常のメトリクス外部の動的な情報に基づいて修正措置を取ることができます。
- 応答時間メトリクス
- 特定のタイプのリソース(Web サーバーまたはセッション Bean の URL)は、全体的なパフォーマンスのコンポーネントとして応答に依存します。応答時間または呼び出し時データは、URL またはセッション Bean がクライアントリクエストに応答する速度を追跡し、アプリケーション全体が実行しているかどうかを判断するのに役立ちます。
- 説明文字列(特性)
- ほとんどのリソースには、インスタンス名、ビルド日、バージョン番号など、リソース自体を記述する比較的静的な情報があります。この情報は 特性です。リソースの他の属性と同様に、これを監視できます。特性は、バージョンの更新など、基礎となるアプリケーションへの変更を特定するのに役立ちます。
16.2. 条件の変更に対するアラートおよび応答
- アラートは、管理者が 定義したパラメーターに基づいて問題があったことを通知します。
- アラートはインシデントに自動的に応答 します。管理者は操作を自動的に開始し、JBoss ON CLI スクリプトを実行して JBoss ON またはリソース設定の変更、コンテンツの再デプロイ、またはシェルスクリプトの実行が、アラート条件に対応して実行できます。管理者定義のアラートに対する自動応答により、管理者はインフラストラクチャーの問題に迅速に対応し、停止の影響を軽減することができます。
16.3. サーバーパフォーマンスに影響を及ぼす可能性のある影響
- データベースのパフォーマンス(ほとんどの環境では主要な要素)
- ネットワーク帯域幅
- 最大メトリクスを毎分収集できます。
- 最大 9000 個のアラートを 1 日あたり最大 4000 に発生する(毎分約 70 個)
16.4. 異なるリソースタイプに基づくモニタリングとの相違点
第17章 レポートおよびデータの監視
- 個別のリソース、互換性のあるグループ、メインダッシュボードのメトリクスポートレットを含むダッシュボード
- 収集したすべてのデータ、イベント、設定、操作、およびその他の変更を集約するタイムライン
- メトリクスのリソースレベルのチャートおよびテーブル
- 範囲外のメトリクスまたは範囲外のメトリクスについてのメトリクスレポート
17.1. ダッシュボードとポートレット
17.1.1. resource-Level Dashboards
図17.1 リソース概要タブ
17.1.2. メインのダッシュボード
- プラットフォーム使用率: 空きメモリー、CPU 使用率、およびプラットフォームのパフォーマンスに関する他のメトリクスを表示します。
- alerted または Unavailable Resources: アラートを発行した最新の 5 つのリソースの一覧を表示するか、または停止として報告されたリソースを表示します。
- 日付/時刻、名前、および優先度でフィルタリングできる最新のアラートおよびイベント。
- 互換性のあるグループの特定のメトリクス用のグラフ。
- リソースの特定のメトリクス用のグラフ。
図17.2 MONItoring Data のあるダッシュボードの Portlets
17.1.3. メインダッシュボードへのモニタリングメトリクスの追加
手順17.1 モニタリングメトリクスを Dashboard に追加する
- トップメニューの Inventory タブをクリックし、Resource に移動します。
- Monitoring タブで Metrics サブタブを選択します。
- 一覧からメトリクスを選択し、Add to Dashboard をクリックします。
17.2. サマリータイムライン
図17.3 サマリータイムライン
17.3. リソースレベルのメトリクスチャート
- 「メトリクスおよびベースラインチャートの表示」 同じメトリクス情報のグラフおよびテーブル
図17.4 メトリクスチャート
図17.5 データポイントへのマウスオーバー
図17.6 グラフのサブセットの選択
17.4. Depend Metrics Report
図17.7 範囲外ポートレット
図17.8 Depend Metrics Report
suspectMetrics.csv
ます。
17.5. プラットフォーム使用状況レポート
- 現在の CPU パーセンテージ
- 利用可能な物理メモリー、バッファー、およびキャッシュに基づく実際のメモリー使用量。
- swap
図17.9 プラットフォーム使用状況レポート
platformUtilization.csv
ます。
第18章 可用性
18.1. コア "Up and down" の監視
図18.1 リソースの可用性
図18.2 可用性のアップタイムパーセント
18.1.1. 長いスキャン時間と非同期アベイラビリティーコレクション
AvailabilityCollectorRunnable
JBoss ON プラグイン API のクラス。このクラスの詳細は、『 Plug-in API』および『Writing Custom Plug-ins Guide』を参照してください。
rhq-agent-env.sh
ファイルの ADDITIONAL_JAVA_OPTIONS パラメーターに追加します。
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="$RHQ_AGENT_ADDITIONAL_JAVA_OPTS -Drhq.agent.plugins.availability-scan.timeout=15000"
18.1.2. 同期の可用性
18.1.3. 可用性の状態
表18.1 可用性の状態
状態 | description | icon |
---|---|---|
利用可能な(UP) | リソースが実行され、可用性ステータスチェックに応答します。 | |
down | リソースは可用性チェックに応答しません。 | |
Unknown | エージェントには、リソースの状態を記録しません。これは、リソースがインベントリーに新たに追加され、最初の可用性チェックがないか、またはエージェントがダウンしているためです。 | |
disabled | リソースは、管理者が利用できないとマークされています。リソース(実際には)が実行中または停止している可能性があります。リソースを無効にすると、サーバーがエージェントからの可用性レポートを無視して、(既知の)停止状態または循環状態に基づいて不必要なアラートが発生しないようにします。 | |
混在(グループのみ) [a]
| グループのリソースには、可用性の状態が異なります。 | |
[a]
リソースの詳細ページの上部で、リソースの可用性の横に同様の警告マークが表示されます。この警告は、リソースに対してエラーメッセージや疑わしいメトリクスが返されたことを示しています。リソースの可用性が警告状態にあるわけではありません。
|
18.1.4. 親およびバックフィル
18.1.5. コレクション間隔とエージェントのスキャン間隔
- エージェントのハートビート ping(プラットフォームの可用性に分析)は、1 分ごとにサーバーに送信されます。
- サーバーの可用性は毎分チェックされます。
- サービスの可用性は 10 分ごとにチェックされます。
> avail -- force
18.2. リソースの可用性チャートの表示
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
- リスト内のリソースの名前をクリックします。
- リソースの Monitoring タブを開きます。
図18.3 可用性チャート
18.3. 詳細なディスカッション: 可用性の期間とパフォーマンス
図18.4 可用性数
- up、down、および disabled 状態の合計時間
- 稼働時間、ダウン状態、および無効な状態の時間の割合
- リソースがダウン状態または無効状態にある回数
- 障害(MTBF)と平均リカバリー時間(MTTR)の平均時間。
図18.5 アップアンドダウンの監視
図18.6 可用性の期間アラート
18.4. 詳細なディスカッション: "Not Up" Alert Conditions
- Up
- down
- Unknown
- disabled
図18.7 可用性変更条件
18.5. グループの可用性の表示
- トップメニューの Inventory タブをクリックします。
- 左側の Groups メニューで、互換性のあるグループまたは混合グループアイテムを選択します。
- グループの名前をクリックします。
- グループの Inventory タブをクリックします。
図18.8 グループの可用性
表18.2 グループアベイラビリティーの状態
リソースの状態が ... である場合は、. | ... Group State Is ... |
---|---|
空のグループ(不明) | empty |
すべての Red(Down) | 赤い(Down) |
Down または Unknown | yellow(Mixed) |
一部の Orange(Disabled) | アジア(Disabled) |
All green(Up) | 緑色の(Up) |
18.6. メンテナンス用のリソースの無効化
- エージェントが稼働している場合は、リソースの可用性が報告されます。JBoss ON サーバーによってのみ無視され、可用性の計算には含まれません。
- 親リソースを無効にすると、その親リソースも自動的に無効になります。
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
- 一覧でリソースを選択します。
- ページ下部の Disable ボタンをクリックします。
- プロンプトが表示されたら、リソースを無効にする必要があることを確認します。
図18.9 無効なリソース
18.7. リソースの自動無効化および有効化プラグインの許可
AvailabilityContext.disable()
および AvailabilityContext.enable()
メソッドは、コンポーネント JAR ファイルの可用性定義の一部として使用します。
18.8. アベイラビリティーチェック間隔の変更
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
- リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- Availability メトリクスを選択し、必要なコレクション期間を適切な時間単位(秒 Collection Interval、分、または時間)で入力します。注記可用性スケジュールは、互換性のあるグループまたはリソースタイプのテンプレートに設定できます。グループまたはリソース種別レベルで設定すると、複数のリソースが同時に変更されます。
- をクリックし Setます。
18.9. エージェントの可用性スキャン期間の変更
- エージェントの設定ファイルを開きます。
vim agentRoot/rhq-agent/conf/agent-configuration.xml
- XML ファイルの行をコメント解除し、新しいスキャン時間(秒単位)を設定します。
<entry key="rhq.agent.plugins.availability-scan.period-secs" value="60"/>
- 端末のフォアグラウンドでエージェントを再起動します。この
--cleanconfig
オプションを使用して、エージェントが設定ファイルから新しい設定を読み取るように強制します。agentRoot/rhq-agent/bin/rhq-agent.sh --cleanconfig
第19章 メトリックおよび測定値
19.1. リソースに関する直接情報
図19.1 メトリクスグラフ
19.1.1. Raw Metrics、Displayed Metrics、および Storing Data
19.1.2. 現在の値
図19.2 ライブ値の列
19.1.3. メトリクスのカウント: 動的な値と値
- 動的値 は、現在の状態であり、一時的な変更可能な値を示しています。これには、アプリケーションサーバーへの接続の現在の数や、プラットフォーム上の CPU 使用率などが含まれます。
- 傾向値 は、リソースが開始した時点の合計、またはその有効期間を超えた合計数です。これらの値は 1 つの方向でのみ続行されます(通常は、常に高い値になるわけではありません)。
図19.3 メトリックの動的な値および値
19.1.4. baselines and Out-of-Bounds Metrics
図19.4 Depend Metrics Report
図19.5 アウトオブバウンドファクトリー
19.1.5. コレクションのスケジュール
19.1.6. メトリクススケジュールおよびリソースタイプテンプレート
19.2. メトリクスおよびベースラインチャートの表示
- リソースレベルのサマリー
- グラフ
- テーブル
図19.6 個別のメトリックグラフ
図19.7 メトリクステーブル
図19.8 テーブル内のメトリクスグラフ
19.3. メトリクスコレクションの定義
19.3.1. ベースラインのプロパティーの設定
- Configuration メニューで System Settings 項目を選択します。
- Automatic Baseline Configuration Properties セクションまでスクロールします。
- 設定を変更して、計算に使用するウィンドウを定義します。
- ベースラインの頻度 は、ベースラインの再計算頻度(日数)を設定します。デフォルトは 3 日です。
- ベースラインデータセットは、ベースラインの計算に使用する期間(日数)を設定します。デフォルトは 7 日です。
19.3.2. 特定のリソースのコレクション間隔の設定
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルで、サーバーやサービスなどのリソースカテゴリーを選択します。次に、リソースを参照または検索します。
- リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- モニタリング頻度を変更するメトリクスを選択します。複数のメトリクスが同じ頻度に変わる場合は、それらを選択することができます。
- 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
- をクリックし Setます。
19.3.3. 特定リソースのメトリクスの有効化および無効化
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- 有効または無効にするメトリクスを選択します。
- Enable または Disable ボタンをクリックします。
19.3.4. メトリクステンプレートの変更
- トップナビゲーションでメニューを開き、Administration Configuration メニューを開きます。
- Metric Collection Templates メニュー項目を選択します。これにより、プラットフォームおよびサーバータイプ両方のリソースタイプが長いリストが開きます。
- テンプレート定義を作成するリソースのタイプを見つけます。
- 鉛筆アイコンをクリックして、メトリクスコレクションスケジュールテンプレートを編集します。
- 有効または無効にする必要のあるメトリクスを選択し、Enable または Disable ボタンをクリックします。
- メトリクスが収集される頻度を編集するには、Update schedules for existing resources of marked type チェックボックスを選択してから Collection Interval for Selected: フィールドに時間枠を入力します。
- Set ボタンをクリックします。
19.3.5. PostgreSQL Query をメトリクスとして追加
- metricColumn
- count(id)
SELECT 'metricColumn', count(id) FROM my_application_user WHERE is_logged_in = true
- トップメニューの Inventory タブをクリックします。
- PostgreSQL リソースを検索します。
- PostgreSQL データベースの Inventory タブをクリックします。
- Inventory タブ下部の Import ボタンをクリックし、を選択し Queryます。
- クエリーメトリクスのプロパティーを入力します。特に 3 つのフィールドが重要になります。
- Table は、データベース内にデータが含まれるテーブルを示します。これはクエリーの FROM ステートメントに含まれるものになります。
- には、実行する完全なクエリー Metric Query が含まれます。SELECT ステートメントは、JBoss ON エージェントがメトリクスとして解釈されるようにクエリーを正しく 'metricColumn',count(id) フォーマットする必要があります。
SELECT 'metricColumn', count(id) FROM my_application_user WHERE is_logged_in = true
- メトリクスの設定ではこの Name フィールドは重要ではありませんが、後でメトリクスの特定が重要になります。
図19.9 Query: ログイン済みユーザー数の合計
第20章 イベント
20.1. イベント、ログ、およびリソース
- Linux(syslog)
- Windows(Windows イベントログ)
- Apache サーバー(ログファイル)
- JBoss EAP サーバー(ログファイル)
20.2. イベント日付の形式
date severity [class] message
YYYY-mm-dd HH:mm:ss,SSS HH:mm:ss,SSS dd MM yyyy HH:mm:ss,SSS
date SEVERITY [org.foo.bar] my message date [SEVERITY] [org.foo.bar] my message date ( SEVERITY ) [org.foo.bar] my message
20.3. 新規イベントの定義
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースエントリーの Inventory タブをクリックします。
- Connection Settings サブタブを選択します。
- Events Log セクションの下にあるプラスアイコンをクリックして、監視するログインスタンスを追加します。
- イベントログコレクションを有効にします。
- イベントログコレクションのパラメーターを設定します。設定されているリソースに応じて、イベントログ設定には若干異なるオプションがあります。すべてのリソースを使用すると、異なるフィルターで以下が含まれるログメッセージを特定できます。
- エラーメッセージの最小重大度。
- ログメッセージ文字列で使用する正規表現またはパターン。
また、アプリケーションサーバーと Linux では、さまざまなログの場所を指定できます。(Windows リソースはシステムイベントログを使用します。) カスタムログの場所に加え、他のロギングサービスも使用できます。Linux では、プラットフォームとプログラムログの両方を監視できます。アプリケーションサービスでは、メッセージングサービス内のログをチェックできます。で説明されているように 「イベント日付の形式」、ロギングに使用できる日付の形式は異なります。log4j 以外のものを使用すると、エージェントがログエントリーを読み取りできるようにパターンを指定できます。図20.1 EAP イベントログの設定
アプリケーションサーバーや Windows のいずれかとは異なり、Linux システムは、システムファイル または リスナーにイベントをログに記録できます。rsyslog サーバーまたはローカル syslog リスナーが設定されている場合は、リスナー(ローカルファイルではなく)を選択し、リモートサーバーのリスナーポートおよびバインドアドレスを追加できます。図20.2 Linux イベントログの設定
20.4. イベントの表示
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースエントリーの Events タブをクリックします。イベントは重大度(debug、info、warn、error、および fatal)でフィルターできます。
- 詳細については、特定のイベントをクリックします。
20.5. 詳細ディスカッション: イベントの相関
図20.3 リソースタイムラインクラスター
第21章 URL 応答時間の監視
21.1. URL の呼び出し時間(または応答時間)の監視
- EJB メソッド呼び出しのセッション Bean。
- URL 応答の Web サーバー(スタンドアロンまたはアプリケーションサーバー埋め込み)。Web サーバーには、応答時間に測定する URL リソースの設定に関する追加の応答時間フィルターが必要です。
21.2. 呼び出し時間メトリクスの表示
図21.1 Web サーバーの URL メトリクス
21.3. 拡張例: Web サイトのパフォーマンス
設定
サンプル Co. のビジネス、サービス、およびサポートは Web サイトに関連付けられています。お客様は、購入した製品へのアクセス、トレーニングまたはコンサルティングのスケジュール、およびほとんどのサポートとサポートを受けることができる必要があります。このサイトの速度が遅い、または一部のリソースにアクセスできない場合は、直ちに否定的な経験があります。
操作方法
Tim the IT Guy は、Web アプリケーションのパフォーマンス情報を取得する 3 つの異なる方法を識別します。
- 個々の URL の応答時間
- リクエストおよび応答の合計数などのスループット情報
- 重要な HTTP レスポンスコードのカウント
- 応答時間が十分で、多数の HTTP エラー 500 応答がある場合は、Web サーバー(「詳細なディスカッション: 操作の開始」)を再起動する操作でアラートを設定できます。
- 応答時間が十分で、多数の HTTP エラー 404 応答がある場合は(リソースが適切に配信されない可能性がある)、データベースを再起動するようにアラートが設定されます。
- 応答時間が十分で、1 分あたりの合計リクエスト数が多い場合は、サーバーへの負荷が大きすぎる可能性があります。アラートは、負荷分散に役立つ別の Web サーバーインスタンスを作成するように設定できます。JBoss ON CLI スクリプトを使用すると、JBoss ON CLI スクリプトを使用すると、必要に応じて新しいリソースを作成し、適切な web アプリケーションのバンドル(「詳細なディスカッション: リソーススクリプトの開始」)をデプロイすることができます。
21.4. EJB 呼び出し時メトリクスの設定
- トップメニューの Inventory タブをクリックします。
- 左側の Services メニューテーブルを選択し、EJB リソースに移動します。注記名前でセッション Bean を検索する方が、できるかもしれません。
- EJB リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- Method Execution Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
- 一覧の Enable 下部にあるをクリックします。
21.5. JBoss EAP の応答時間メトリクスの設定
21.5.1. JBoss EAP 6 の応答時間フィルターのインストール
JBoss EAP での応答時間フィルターのインストール方法
前提条件
- JBoss EAP 6 インスタンスにアクセスするための管理ユーザーを作成します。手順は 、JBoss EAP 6『 『管理および設定ガイド』の「管理』 インターフェースのユーザーの追加 」を参照してください。
- JBoss EAP サーバーをインベントリーで設定します。手順は、「 管理コンソールを使用したサーバーの設定 」を参照してください。
手順21.1
- JBoss ON UI から JBoss の応答時間パッケージをダウンロードします。応答時間フィルターは AS 7 モジュールとしてパッケージ化されます。以下を取得するモジュールは 2 つあります。
rhq-rtfilter-module.zip rhq-rtfilter-subsystem-module.zip
注記これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。[root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-module.zip [root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-subsystem-module.zip
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- rhq-rtfilter-module.zip および rhq-rtfilter-subsystem-module.zip リンクをクリックし、ディレクトリーなどのアクセス可能なディレクトリーにファイルを保存し
/tmp
ます。
- JBoss EAP 6 インスタンスの
modules/
ディレクトリーを開きます。例:[root@server ~]# cd /opt/jboss-eap-6.0/modules/
rhq-rtfilter-module.zip
アーカイブを展開して、応答時間フィルター JAR と関連するmodule.xml
ファイルをインストールします。[root@server modules]# unzip /tmp/rhq-rtfilter-module.zip
- サーバーの設定ファイル
domain.xml
またはを開きstandalone.xml
ます。 - <subsystem> 要素内のグローバルモジュールのリストにモジュールを追加して、応答時間モジュールをグローバルにデプロイします。ファイルが完了したら、保存します。
<profile... <subsystem xmlns="urn:jboss:domain:ee:1.1"> <global-modules> <module name="org.rhq.helpers.rhq-rtfilter" slot="main"/> </global-modules> </subsystem> </profile>
rhq-rtfilter-subsystem-module.zip
アーカイブを展開してサブシステムの応答時間フィルター JAR と関連するmodule.xml
ファイルをインストールします。[root@server modules]# unzip /tmp/rhq-rtfilter-subsystem-module.zip
これにより、フィルターがアプリケーションサーバーまたは個別の Web アプリケーションのサブシステムとしてインストールされます。- フィルターをインストールしたら、JBoss EAP 6 サーバーをサーバーを使用するように設定する必要があります。応答時間フィルターは、EAP/AS インスタンスがホストするすべての Web アプリケーションに対してグローバルにデプロイすることも、特定の Web アプリケーションに対して設定することもできます。フィルターをグローバルサブシステムとしてデプロイするには、以下を行います。
- サーバーの設定ファイル
domain.xml
またはを開きstandalone.xml
ます。 - 応答時間フィルターに <extensions> 要素を追加します。
<extension module="org.rhq.helpers.rhq-rtfilter-subsystem"/>
- 要素の下に <subsystem> <profile> 要素を追加します。応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <subsystem> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.1「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。オプションのパラメーターが設定されていない場合でも、<subsystem> 要素を追加する必要があります。
<subsystem xmlns="urn:rhq:rtfilter:1.0"> <!-- Optional parameters. <init-param> <param-name>chopQueryString</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>logDirectory</param-name> <param-value>/tmp</param-value> </init-param> <init-param> <param-name>logFilePrefix</param-name> <param-value>localhost_7080_</param-value> </init-param> <init-param> <param-name>dontLogRegEx</param-name> <param-value></param-value> </init-param> <init-param> <param-name>matchOnUriOnly</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>timeBetweenFlushesInSec</param-name> <param-value>73</param-value> </init-param> <init-param> <param-name>flushAfterLines</param-name> <param-value>13</param-value> </init-param> <init-param> <param-name>maxLogFileSize</param-name> <param-value>5242880</param-value> </init-param> --> </subsystem>
手順21.2 JBoss EAP 6 で個別の Web アプリケーションに応答時間フィルターを設定する方法
- Web アプリケーションの
web.xml
ファイルを開きます。[root@server ~]# vim WARHomeDir/WEB-INF/web.xml
- フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.1「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
<filter> <filter-name>RhqRtFilter</filter-name> <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class> <!-- Optional parameters. <init-param> <param-name>chopQueryString</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>logDirectory</param-name> <param-value>/tmp</param-value> </init-param> <init-param> <param-name>logFilePrefix</param-name> <param-value>localhost_7080_</param-value> </init-param> <init-param> <param-name>dontLogRegEx</param-name> <param-value></param-value> </init-param> <init-param> <param-name>matchOnUriOnly</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>timeBetweenFlushesInSec</param-name> <param-value>73</param-value> </init-param> <init-param> <param-name>flushAfterLines</param-name> <param-value>13</param-value> </init-param> <init-param> <param-name>maxLogFileSize</param-name> <param-value>5242880</param-value> </init-param> --> </filter> <!-- Use this only when also enabling the RhqRtFilter in the filter <filter-mapping> <filter-name>RhqRtFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> -->
- JBoss EAP サーバーを再起動して、新しい
web.xml
設定を読み込みます。
表21.1 ユーザー定義の <filter> Settings に使用できるパラメーター
パラメーター
|
description
|
---|---|
chopQueryString
|
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
|
logDirectory
|
ログファイルが書き込まれるディレクトリー。デフォルト設定は {
jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt )です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
|
logFilePrefix
|
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
|
dontLogRegEx
|
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
|
matchOnUriOnly
|
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
|
timeBetweenFlushesInSec
|
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
|
flushAfterLines
|
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
|
maxLogFileSize
|
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
|
vHostMappingFile
|
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、../conf/vhost-mappings.properties のようになります。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi pickeldi= %HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。
|
21.5.2. JBoss EAP 7 の応答時間フィルターのインストール
JBoss EAP での応答時間フィルターのインストール方法
前提条件
- JBoss EAP 7 インスタンスにアクセスするための管理ユーザーを作成します。手順は 、JBoss EAP 7『 『管理および設定ガイド』の「管理』 インターフェースのユーザーの追加 」を参照してください。
- JBoss EAP サーバーをインベントリーで設定します。手順は、「 管理コンソールを使用したサーバーの設定 」を参照してください。
手順21.3
- JBoss ON UI から JBoss の応答時間パッケージをダウンロードします。応答時間フィルターは AS 7 モジュールとしてパッケージ化されます。取得するモジュールは 2 つあります。両方は 1 つの zip アーカイブに含まれます。
rhq-rtfilter-wfly-10-dist.zip
注記これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。[root@server ~]# wget http://server.example.com:7080/downloads/connectors/rhq-rtfilter-wfly-10-dist.zip
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- rhq-rtfilter-wfly-10-dist.zip リンクをクリックして、ディレクトリーなどのアクセス可能なディレクトリーにファイルを保存し
/tmp
ます。
- JBoss EAP 7 インスタンスの
modules/
ディレクトリーを開きます。例:[root@server ~]# cd /opt/jboss-eap-7.0/modules/
rhq-rtfilter-wfly-10-dist.zip
アーカイブを展開して JAR と関連するmodule.xml
ファイルをインストールします。[root@server modules]# unzip /tmp/rhq-rtfilter-wfly-10-dist.zip
- サーバーの設定ファイル
domain.xml
またはを開きstandalone.xml
ます。 - <subsystem> 要素内のグローバルモジュールのリストにモジュールを追加して、応答時間モジュールをグローバルにデプロイします。domain:ee サブシステムのバージョンは JBoss EAP のバージョンごとに異なることに注意してください。ファイルが完了したら、保存します。
<profile... <subsystem xmlns="urn:jboss:domain:ee:1.1"> <global-modules> <module name="org.rhq.helpers.rhq-rtfilter" slot="main"/> </global-modules> </subsystem> </profile>
- フィルターをインストールしたら、JBoss EAP 7 サーバーをサーバーを使用するように設定する必要があります。応答時間フィルターは、JBoss EAP インスタンスがホストするすべての web アプリケーションに対してグローバルにデプロイすることも、特定の web アプリケーションに設定することもできます。フィルターをグローバルサブシステムとしてデプロイするには、以下を行います。
- サーバーの設定ファイル
domain.xml
またはを開きstandalone.xml
ます。 - 応答時間フィルターに <extensions> 要素を追加します。
<extension module="org.rhq.helpers.rhq-rtfilter-wfly-10-subsystem"/>
- 要素の下に <subsystem> <profile> 要素を追加します。応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <subsystem> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.2「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。オプションのパラメーターが設定されていない場合でも、<subsystem> 要素を追加する必要があります。
<subsystem xmlns="urn:rhq:rtfilter:1.0"> <!-- Optional parameters. <init-param> <param-name>chopQueryString</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>logDirectory</param-name> <param-value>/tmp</param-value> </init-param> <init-param> <param-name>logFilePrefix</param-name> <param-value>localhost_7080_</param-value> </init-param> <init-param> <param-name>dontLogRegEx</param-name> <param-value></param-value> </init-param> <init-param> <param-name>matchOnUriOnly</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>timeBetweenFlushesInSec</param-name> <param-value>73</param-value> </init-param> <init-param> <param-name>flushAfterLines</param-name> <param-value>13</param-value> </init-param> <init-param> <param-name>maxLogFileSize</param-name> <param-value>5242880</param-value> </init-param> --> </subsystem>
手順21.4 JBoss EAP 7 で個別の Web アプリケーションに応答時間フィルターを設定する方法
- Web アプリケーションの
web.xml
ファイルを開きます。[root@server ~]# vim WARHomeDir/WEB-INF/web.xml
- フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 表21.2「ユーザー定義の <filter> Settings に使用できるパラメーター」 ます。
<filter> <filter-name>RhqRtFilter</filter-name> <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class> <!-- Optional parameters. <init-param> <param-name>chopQueryString</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>logDirectory</param-name> <param-value>/tmp</param-value> </init-param> <init-param> <param-name>logFilePrefix</param-name> <param-value>localhost_7080_</param-value> </init-param> <init-param> <param-name>dontLogRegEx</param-name> <param-value></param-value> </init-param> <init-param> <param-name>matchOnUriOnly</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>timeBetweenFlushesInSec</param-name> <param-value>73</param-value> </init-param> <init-param> <param-name>flushAfterLines</param-name> <param-value>13</param-value> </init-param> <init-param> <param-name>maxLogFileSize</param-name> <param-value>5242880</param-value> </init-param> --> </filter> <!-- Use this only when also enabling the RhqRtFilter in the filter <filter-mapping> <filter-name>RhqRtFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> -->
- JBoss EAP サーバーを再起動して、新しい
web.xml
設定を読み込みます。
表21.2 ユーザー定義の <filter> Settings に使用できるパラメーター
パラメーター
|
description
|
---|---|
chopQueryString
|
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
|
logDirectory
|
ログファイルが書き込まれるディレクトリー。デフォルト設定は {
jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt )です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
|
logFilePrefix
|
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
|
dontLogRegEx
|
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
|
matchOnUriOnly
|
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
|
timeBetweenFlushesInSec
|
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
|
flushAfterLines
|
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
|
maxLogFileSize
|
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
|
vHostMappingFile
|
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、../conf/vhost-mappings.properties のようになります。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi pickeldi= %HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。
|
21.5.3. 呼び出し時メトリックの有効化
図21.2 Web ランタイムリソース
- トップメニューの Inventory タブをクリックします。
- Servers - Top Level Imports 項目をクリックし、JBoss EAP 6 リソースを選択します。
- デプロイメントリソースに移動し、web サブシステムにアプリケーションを展開します。
- Web リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- Response Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
- 一覧の Enable 下部にあるをクリックします。
- Web エントリーの Inventory タブをクリックします。
- Connection Settings サブタブを選択します。
- 応答時間設定のチェックボックスの設定を解除し、Web アプリケーションに適した値を入力します。
- 特定の Web アプリケーションによって使用される応答時間ログ。ログファイルは、call-time データコレクションが機能するのに必須の設定です。
- 応答時間の測定から除外するファイル、要素、またはページ。応答時間ログは、Web サーバーが処理するすべてのリソースの時間を記録します。これには、CSS ファイルやアイコン、背景イメージなどのサポートファイルが含まれます。
- URL で渡された異なるパラメーターを使用して同じページにアクセスできます。この Response Time Url Transforms フィールドは、渡されたパラメーターのストライピングや置き換えに使用できる正規表現を提供します。
21.6. Apache、EWS/Tomcat、および JBoss EAP 5 への応答時間監視の設定
21.6.1. parameters for User-Defined <filter>s
表21.3 parameters for User-Defined <filter>s
パラメーター
|
description
|
---|---|
chopQueryString
|
このパラメーターが true に設定されている場合、クエリーの URI 部分のみがログに記録されます。それ以外の場合は、クエリー行全体がログに記録されます。デフォルトは true です。
|
logDirectory
|
ログファイルが書き込まれるディレクトリー。デフォルト設定は {
jboss.server.log.dir}/rt/ (通常は server/xxx/log/rt )です。このプロパティーが定義されていない場合は、フォールバックは {java.io.tmpdir}/rt/ (/tmp/ on)になります。 UNIX®および ~/Application Data/Local Settings/Temp - TEMP 環境変数が使用されることを確認します。この init パラメーターを指定すると、ディレクトリーは作成 rt/ されませんが、指定したディレクトリーは文字どおりに取得されます。
|
logFilePrefix
|
ログファイルの前に配置される接頭辞。デフォルトは空の文字列です。
|
dontLogRegEx
|
クエリー文字列に適用される正規表現。See java.util.regex.Pattern.パラメーターが指定されていない場合や、空の文字列は適用されません。
|
matchOnUriOnly
|
dontLogRegEx はクエリーの URI 部分(true)またはクエリー文字列(false)全体に適用される必要があります。デフォルトは true です。
|
timeBetweenFlushesInSec
|
ログ行はデフォルトでバッファーされます。指定の秒数を超え、新しいリクエストを受け取ると、(を参照)後にフラッシュする行数がまだ到達していない場合でも、バッファーされた行はディスクにフラッシュされます。デフォルト値は 60 秒(1 分)です。
|
flushAfterLines
|
ログ行はデフォルトでバッファーされます。指定された行がバッファーされると、ディスクにフラッシュされます。デフォルト値は 10 行です。
|
maxLogFileSize
|
ログファイルの最大許容サイズ(バイト単位)。ログファイルがこの制限を超えると、フィルターは切り捨てられます。デフォルト値は 5242880(5 MB)です。
|
vHostMappingFile
|
このプロパティーファイルは、Tomcat プロセスクラスパスに存在する必要があります。たとえば、
conf/vhost-mappings.properties ファイルではです。ファイルには、「着信」 vhost(サーバー名)から応答時間のログファイル名の接頭辞として使用する vhost へのマッピングが含まれます。マッピングがない場合(ファイルまたはエントリーの応答時間が設定されていない場合)、受信 vhost(サーバー名)が使用されます。例:
pickeldi.users.acme.com=pickeldi pickeldi= %HOST%=
最初のマッピングでは、受信 vhost が 'host1.users.acme.com' の場合は、ログファイル名に「host1」の vhost をプレフィックスとして取得し、コンテキストルート部分から _ で区切ります。2 つ目のマッピングでは、「incoming」 vhost が「host1」で、接頭辞なし、_ を使用しない場合が示されます。3 つ目のマッピングは、特別な左端トークンである%HOST%' を使用します。このマッピングでは、「incoming」 vhost が localhost の表現である場合、接頭辞なし、_ を使用すべきです。
%host% は、InetAddress.getLocalHost()の実装によって返されるホスト名、または正規のホスト名または IP アドレスに一致します。
2 つ目のマッピングは空の右側の例ですが、vhost も提供しました。
これはワンタイム置換です。1 行目の結果が 2 番目の行に適用されるという形式の再帰はありません。
|
21.6.2. JBoss EAP/AS 5 への応答時間フィルターのインストール
- JBoss ON UI から JBoss の Response Time パッケージをダウンロードします。注記これは、wget以下のコマンドを使用してコマンドラインから行うこともできます。
[root@server ~]# wget http://server.example.com:7080/downloads/connectors/connector-rtfilter.zip
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- connector-rtfilter.zip リンクをクリックしてファイルを保存します。
- コネクターの展開
[root@server ~]# unzip connector-rtfilter.zip
- プロファイルの
lib/
ディレクトリーにrhq-rtfilter-
バージョン.jar
ファイルをコピーします。[root@server ~]# cp connector-rtfilter/rhq-rtfilter-version.jar JbossHomeDir/server/profileName/lib/
JBoss EAP/AS にはcommons-logging.jar
ファイルがすでに含まれており、応答時間のフィルターにも必要です。 - 次に、EAP/AS インスタンス
web.xml
用に設定します。応答時間フィルターは、EAP/AS インスタンスがホストするすべての Web アプリケーションに対してグローバルにデプロイすることも、特定の Web アプリケーションに対して設定することもできます。これをグローバルに設定するには、グローバルweb.xml
ファイルを編集します。[root@server ~]# vim JbossHomeDir/server/configName/deployers/jbossweb.deployer/web.xml
単一の Web アプリケーション用に設定するには、任意の Web アプリケーションのweb.xml
ファイルを編集します。[root@server ~]# vim WARLocation/WEB-INF/web.xml
- フィルターを追加し、設定に応じてマッピング要素をファイルにフィルターします。これにより、応答時間フィルターが有効になります。応答時間フィルターが機能するために必要となるのは、オプションのパラメーターを除いたデフォルトの <filter> 要素のみです。ただし、パラメーターのコメントを解除して、必要に応じて設定できます。異なるパラメーターについては、で説明してい 「parameters for User-Defined <filter>s」 ます。
<filter> <filter-name>RhqRtFilter</filter-name> <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter</filter-class> <!-- Optional parameters. <init-param> <param-name>chopQueryString</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>logDirectory</param-name> <param-value>/tmp</param-value> </init-param> <init-param> <param-name>logFilePrefix</param-name> <param-value>localhost_7080_</param-value> </init-param> <init-param> <param-name>dontLogRegEx</param-name> <param-value></param-value> </init-param> <init-param> <param-name>matchOnUriOnly</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>timeBetweenFlushesInSec</param-name> <param-value>73</param-value> </init-param> <init-param> <param-name>flushAfterLines</param-name> <param-value>13</param-value> </init-param> <init-param> <param-name>maxLogFileSize</param-name> <param-value>5242880</param-value> </init-param> --> </filter> <!-- Use this only when also enabling the RhqRtFilter in the filter <filter-mapping> <filter-name>RhqRtFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> -->
- JBoss EAP/AS サーバーを再起動して、新しい
web.xml
設定を読み込みます。 - の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。
21.6.3. 応答時間メトリクス向けの Apache サーバーの設定
- Response Time モジュールを使用するには、Apache サーバーが共有オブジェクトサポートでコンパイルされている必要があります。Red Hat Enterprise Linux システムおよび EWS サーバーでは、これはデフォルトで有効になります。共有オブジェクトサポートで Apache サーバーがコンパイルされていることを確認するには、apachectl -l コマンドを使用してコンパイル済みモジュールを一覧表示し、
mod_so.c
モジュールを探します。[root@server ~]# apachectl -l Compiled in modules: core.c prefork.c http_core.c mod_so.c
- -enable-module=so
オプションを使用します。[jsmith@server ~]$ ./configure - -enable-module=so [jsmith@server ~]$ make install
- JBoss ON UI から Apache バイナリーをダウンロードします。
- JBoss ON UI にログインします。
https://server.example.com:7080
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- connector-apache.zip リンクをクリックしてファイルを保存します。
- Apache コネクターを展開します。
[root@server ~]# unzip connector-apache.zip
- Response Time モジュールをコンパイルします。注記apxs ユーザー PATH にインストールされ、インストールされている make 必要があります。
[root@server ~]# cd apacheMOduleRoot/apache-rt/sources [root@server sources]# chmod +x build_apache_module.sh [root@server sources]# ./build_apache_module.sh 2.x apache_install_directory/bin/apxs
- 次に、Apache サーバーに Response Time モジュールをインストールします。
[root@server sources]# cp apache2.x/.libs/mod_rt.so apache_install_directory/modules
httpd.conf
ファイルを開きます。例:[root@server ~]# vim apache_install_directory/conf/httpd.conf
- この行をファイルの最後に追加して、Apache の
httpd.conf
ファイルでモジュールを有効にします。LoadModule rt_module modules/mod_rt.so LogFormat "%S" rt_log
ログ形式を設定する場合、変数に %S は大文字 S が含まれます。 - メインの Apache サーバーに応答時間ロギングを設定するには、ファイルのトップレベルに以下の行を追加します。
CustomLog logs/myhost.com80_rt.log rt_log
仮想ホストの応答時間ロギングを設定するには、<VirtualHost> ブロック内の以下の行を追加します。CustomLog logs/myhost.com8080_rt.log rt_log
メインサーバーと仮想ホストで応答時間ログファイルの名前が異なることを確認します。host _port などのファイル名を形成するのに使用する ServerName ディレクティブのホストおよびポートを使用することを検討してください_rt.log
。 - Apache サーバーを再起動します。
[root@server ~]# apachectl -k restart
- Response Time モジュールが正常にインストールされたことを確認するには、CustomLog ディレクティブで設定した応答時間ログファイルが存在することを確認します。
- の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。
21.6.4. Tomcat に対する応答時間フィルターのインストール
- JBoss ON UI から Tomcat の Response Time パッケージをダウンロードします。
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- connector-rtfilter.zip リンクをクリックしてファイルを保存します。
- 応答時間コネクターの展開
unzip connector-rtfilter.zip
パッケージには 2 つの JAR ファイル(version.jar
およびcommons-logging-
versionrhq-rtfilter-
)が含まれ.jar
ます。Tomcat 5 サーバーはcommons-logging-
バージョン.jar
ファイルのみを使用しますが、Tomcat 6 サーバーには両方のファイルが必要です。 - 適切な JAR ファイルを Tomcat 設定ディレクトリーにコピーします。ディレクトリーの場所は、Tomcat または JBoss インスタンス(組み込み Tomcat の場合)によって異なります。たとえば、スタンドアロン Tomcat 5.5 で以下を行います。
cp commons-logging-version.jar /var/lib/tomcat5/server/lib/
Tomcat 6 の場合:cp rhq-rtfilter-version.jar /var/lib/tomcat6/lib/ cp commons-logging-version.jar /var/lib/tomcat6/lib/
たとえば、埋め込み Tomcat インスタンスでは以下のようになります。cp rhq-rtfilter-version.jar JBoss_install_dir/server/default/deploy/jboss-web.deployer/ cp commons-logging-version.jar JBoss_install_dir/server/default/deploy/jboss-web.deployer/
web.xml
ファイルを開き、フィルター定義を追加します。ファイルの場所は、サーバーインスタンスや、スタンドアロンサーバーか組み込みサーバーかによって異なります。一般的な場所がいくつか一覧表示され 表21.4「web.xml 設定ファイルの場所」 ます。- Tomcat サーバーに Response Time フィルターを設定するために、<filter> または <filter-mapping> エントリーを追加します。a <filter> または a のどちらかは <filter-mapping> 使用できますが、両方を使用することはでき ません。最も基本的なフィルター定義は、<filter> 要素の Response Time フィルター名とクラスのみを参照します。これにより、すべてのデフォルト設定で応答時間フィルターが読み込まれます。
<filter> <filter-name>RhqRtFilter </filter-name> <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter </filter-class> </filter>
フィルターの定義は、<init-param 要素を追加することでユーザー定義の設定値で拡張できます。これにより、すべてのデフォルト設定で応答時間フィルターが読み込まれます。<filter> <filter-name>RhqRtFilter </filter-name> <filter-class>org.rhq.helpers.rtfilter.filter.RtFilter </filter-class> <init-param> <description>Name of vhost mapping file. This properties file must be in the Tomcat process classpath.</description> <param-name>vHostMappingFile</param-name> <param-value>vhost-mappings.properties</param-value> </init-param> ... </filter>
利用可能なパラメーターはに記載されてい 「parameters for User-Defined <filter>s」 ます。監視される URL を照合するために使用する <filter-map> エントリーを設定します。<filter-mapping> <filter-name>RhqRtFilter </filter-name> <url-pattern>/* </url-pattern> </filter-mapping>
注記設定されたフィルターの前に Response Time フィルターを付け、応答時間メトリックに他の応答時間の合計合計が含まれるようにします。 - Tomcat インスタンスを再起動して、新しい設定を読み込む。
- の説明に従って HTTP メトリクスを有効にし 「HTTP 応答時間メトリクスの設定」、JBoss ON はアプリケーションサーバーで応答時間メトリクスをチェックします。
表21.4 web.xml 設定ファイルの場所
Tomcat バージョン | 埋め込みサーバータイプ | ファイルの場所 |
---|---|---|
Tomcat 6 | スタンドアロンサーバー | /var/lib/tomcat6/webapps/project/WEB-INF/web.xml |
Tomcat 5 | スタンドアロンサーバー | /var/lib/tomcat5/webapps/project/WEB-INF/web.xml |
Tomcat 6 | EAP 5 | JBOSS_HOME/server/config/deployers/jbossweb.deployer/web.xml |
Tomcat 6 | JBoss 4.2、JBoss EAP4 | JBOSS_HOME/server/config/deploy/jboss-web.deployer/conf/web.xml |
Tomcat 5.5 | JBoss 4.0.2 | JBOSS_HOME/server/config/deploy/jbossweb-tomcat55.sar/conf/web.xml |
Tomcat 5.0 | JBoss 3.2.6 | JBOSS_HOME/server/config/deploy/jbossweb-tomcat50.sar/conf/web.xml |
Tomcat 4.1 | JBoss 3.2.3 | JBOSS_HOME/server/config/deploy/jbossweb-tomcat41.sar/web.xml |
21.6.5. HTTP 応答時間メトリクスの設定
- Web サーバーの応答時間フィルターをインストールします。Apache では、フィルターをインストールするだけです。Tomcat の場合は、
web.xml
ファイルにフィルターエントリーを設定するために追加の設定が必要になります。必要な場合は、web.xml
ファイルにフィルターエントリーを設定します。を参照してください 「Apache、EWS/Tomcat、および JBoss EAP 5 への応答時間監視の設定」。 - トップメニューの Inventory タブをクリックします。
- 左側の Servers メニューテーブルを選択し、Web アプリケーションに移動し、応答時間監視を実行する Web アプリケーションコンテキストを選択します。
- web アプリケーションコンテキストリソースの Connection Settings タブをクリックし、Response Time configuration セクションまでスクロールします。
- Web サーバーの応答時間プロパティーを設定します。エージェントは、Web サーバーが応答時間データを記録するのに使用するログファイルを認識する必要があります。オプションで、サーバーは収集したデータに対して特定の変換を実行できます。
- 応答時間ログは、Web サーバーが処理するすべてのリソースの時間を記録します。これには、CSS ファイルやアイコン、背景イメージなどのサポートファイルが含まれます。これらのリソースは、Response Time Url Excludes フィールドの応答時間の計算から除外できます。
- URL で渡された異なるパラメーターを使用して同じページにアクセスできます。この Response Time Url Transforms フィールドは、渡されたパラメーターのストライピングや置き換えに使用できる正規表現を提供します。
- Save ボタンをクリックします。
- Web サーバーリソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- HTTP Response Time メトリクスを選択します。このメトリクスは呼び出し時間 タイプ です。
- 一覧の Enable 下部にあるをクリックします。
第22章 リソース特性
図22.1 リソースの詳細
22.1. コレクション間隔
22.2. 特性の表示
- 特性名。リソースに対して監視される特性は、リソースタイプのプラグイン記述子の他の監視設定と定義されます。
- trait 値。
- 特性情報の変更が検出された最後のコレクションの時間。
図22.2 特性チャート
22.3. 拡張例: Alerting and Traits
設定
特性情報は静的である傾向があります。特性は変更し、頻繁に行うことができます。また、状態データや動的な測定値ではなく、リソースの説明的な情報を提供する特性であるため、IT 管理者は密接に追跡することが重要ではありません。
操作方法
たとえば、Tim(IT Guy)には、Red Hat Enterprise Linux 開発および QA サーバー向けに自動更新が設定されています。実稼働環境でアプリケーションおよびシステムの更新が制御されているため、それらのサーバーに対する自動更新はありません。
図22.3 特性のアラート条件
- これは、OR 演算子を使用して 2 つの条件を設定します。アラートは、ディストリビューションバージョンが変更され たり、オペレーティングシステムのバージョンが変更された場合にトリガーされます。これにより、オペレーティングシステムまたはカーネルへのマイナー更新とメジャー更新の両方がキャッチされます。
- 優先度が低いため、情報的には重要ではありませんが、重要ではありません。
- Tim はアラート通知が JBoss ON ユーザーに送信されることを判断するため、ログイン時に通知が表示されます。また、優先順位の高いリソースのメール通知を設定することもできます。
第23章 監視のための特別な設定が必要なリソース
23.1. 監視のための Tomcat/EWS サーバーの設定
23.2. Apache SNMP モジュールの設定
- 編集する
httpd.conf
ファイルを開きます。$ sudo vim JWS_install_directory/conf/httpd.conf
- Dynamic Shared Object Support セクションの下にある
httpd.conf
ファイルにこれらの行を追加して、モジュールを有効にします。LoadModule snmpcommon_module JWS_install_directory/modules/snmpcommon.so LoadModule snmpagt_module JWS_install_directorymodules/snmpmonagt.so SNMPConf JWS_install_directory/conf SNMPVar JWS_install_directory/var
Windows Server の場合:LoadModule snmpcommon_module modules/libsnmpcommon.so LoadModule snmpagt_module modules/libsnmpmonagt.so SNMPConf conf SNMPVar var
httpd.conf
ファイルの主な設定セクションと、各 <VirtualHost> 設定ブロックにポートがある ServerName ディレクティブが含まれていることを確認します。SNMP モジュールはこのディレクティブを使用して、メインサーバーと各仮想ホストを一意に識別するため、各 ServerName ディレクティブに一意の値が含まれている必要があります。例:ServerName main.example.com:80 ... <VirtualHost vhost1.example.com:80> ServerName vhost1.example.com:80 ... </VirtualHost>
- 同じマシン上に複数の Apache インスタンスがある場合は、インスタンスごとに異なる SNMP ファイルを使用できます。
- 各 Web サーバーインスタンスには独自の
httpd.conf
ファイルがあります。各ファイルの SNMPConf ディレクトリーを独自の SNMP 設定ディレクトリーに設定します。たとえば、instance1 の場合は以下のようになります。$ sudo vim instance1-httpd.conf SNMPConf /opt/apache-instance1/conf
次に、たとえば 2 の場合は以下のようになります。$ sudo vim instance2-httpd.conf SNMPConf /opt/apache-instance2/conf
各snmpd.conf
ファイルは、指定したディレクトリーに置く必要があります。 - JWS_install_directoryに agentaddress プロパティーを編集して、各インスタンスの値
/conf/snmpd.conf
が異なるエージェントアドレスとポートの値を持つようにし、インスタンス間で競合が発生しないようにします。このプロパティーの構文の説明は、snmpd.conf ドキュメントを参照してください。
- Restart Red Hat JBoss Web Server.
$ sudo apachectl -k restart
- Red Hat JBoss Web Server エラーログを確認して SNMP モジュールがインストールされ、設定されていることを確認します。
$ grep SNMP JWS_installation_dir/logs/error_log [Wed Mar 19 09:54:34 2008] [notice] Apache/2.0.63 (Unix) CovalentSNMP/2.3.0 configured -- resuming normal operations [Wed Mar 19 09:54:35 2008] [notice] SNMP: CovalentSNMP/2.3.0 started (user '1000' - SNMP address '1610' - pid '26738')
23.2.1. Apache HTTP Server で使用する Apache SNMP モジュールの準備
mod_so.c
モジュールを探します。
$ sudo apachectl -l Compiled in modules: core.c prefork.c http_core.c mod_so.c
--enable-module=so
オプションを使用します。
$ ./configure --enable-module=so $ make install
- Apache コネクターは、にあるソースファイルから Solaris などの他のプラットフォームに対してコンパイルでき
connector-apache.zip
ます。 - JBoss ON UI から Apache モジュールのソースファイルをダウンロードします。
- JBoss ON UI にログインします。
https://server.example.com:7080
- トップメニューの Administration タブをクリックします。
- 左側の Configuration メニューボックスで、Downloads 項目を選択します。
- にスクロールし Connector Downloads、
connector-apache.zip
リンクをクリックして Apache コネクターをダウンロードします。
注記SNMP モジュールのソースファイルを含む zip ファイルは、を参照してくださいJON_SERVER_INSTALL_DIR/modules/org/rhq/server-startup/main/deployments/rhq.ear/rhq-downloads/connectors/connector-apache.zip
。 - SNMP モジュールをコンパイルするには、、、perl make automake およびパッケージをインストールする必要があります libtool。
sudo yum install perl make automake libtool
また、Apache インストールの一部として apxs 使用してください。 - Apache コネクターを展開し、ビルドスクリプトを実行します。
$ sudo unzip connector-apache.zip $ sudo cd apache-snmp/sources/ $ sudo chmod 755 ./build_apache_snmp.sh $ sudo ./build_apache_snmp.sh 2.0 [APACHE_INSTALL_DIR/sbin/apxs]
- 配置
build_apache_snmp.sh
されているディレクトリーからモジュールをインストールします。例:$ sudo cd snmp_module_# $ sudo cp module/* apache_install_directory/modules $ sudo cp conf/* apache_install_directory/conf $ sudo mkdir apache_install_directory/var
# は Apache バージョン(2.0 または 2.2 のいずれか)です。Windows Server の場合:> xcopy /e JON_AGENT_INSTALL_DIR\product_connectors\apache-snmp\binaries\x86
- これで、で説明されている Red Hat JBoss Web Server のモジュールの設定プロセスと同じプロセスを使用して Apache SNMP モジュールを設定する準備が整いました 「Apache SNMP モジュールの設定」。
23.3. Apache および SNMP でのメトリック収集に関する考慮事項
- GET リクエストごとに受信されたバイト数
- POST リクエストごとに受信されたバイト数
- 1 分あたりに受信された合計バイト数
第24章 モニタリングデータの保存
- Raw メトリクスは、数分ごとに収集され、1 時間あたりのローリング平均で集計され、最小値、平均、および最大値が生成されます。
- 1 時間の値は合計され、6 時間の期間に平均されます。
- 6 時間の期間が、24 時間(1 日)のウィンドウに組み合わされます。
24.1. モニタリングデータのストレージの長さの変更
24.1.1. デフォルトのストレージの長さ
表24.1 データのストレージ時間
data | 時間の長さ | 設定可能またはハードコーディング | SQL またはNoSQL データベース |
---|---|---|---|
Raw 測定値 | 7 日 | hardcoded | NoSQL |
1 時間アグリゲート | 14 日 | hardcoded | NoSQL |
6 時間アグリゲート | 31 days | hardcoded | NoSQL |
24 時間アグリゲート | 365 日 | hardcoded | NoSQL |
traits | 365 日 | 設定可能 | SQL |
可用性データ | 365 日 | 設定可能 | SQL |
Events データ | 14 日 | 設定可能 | SQL |
response-time metrics | 31 days | 設定可能 | SQL |
24.1.2. 異なるモニタリングデータのストレージ時間の変更
- Configuration メニューで System Settings 項目を選択します。
- Data Manager Configuration Properties セクションまでスクロールします。
- 異なるタイプのモニタリングデータのストレージ時間を変更します。直接監視データを格納するために関連する 4 つの設定があります。
- Web サーバーおよび EJB リソースの応答時間データ。これは、デフォルトで 1 カ月(31 日)保持されます。
- イベント情報(リソースのエージェントによって生成されたすべてのログファイル)。イベントログのデフォルトストレージ時間は 2 週間です。
- リソースの特性。デフォルトの時間は 1 年間(365 日)です。
- 可用性情報デフォルトの時間は 1 年間(365 日)です。
24.2. Raw データのエクスポート
MeasurementDataManager
クラスには、特定のリソースのメトリック値を特定の時間範囲内で検索する方法があります。
findDataForResource(resourceId,[metricId],startTime,endTime,numberOfRecords)
exporter.file = '/export/metrics/metrics.csv' exporter.format = 'csv' var start = new Date() - 8* 3600 * 1000; var end = new Date() var data = MeasurementDataManager.findDataForResource(10003,[10473],start,end,60) exporter.write(data.get(0))
24.3. ストレージノードのデプロイおよび管理
24.3.1. High-Speed Metrics Storage
- 専用 CPU
- 利用可能な物理メモリーがさらに必要です。
- 高速ディスク
- より多くのディスク領域
- エージェントはストレージノード設定を JBoss ON サーバーに送信します。その後、JBoss ON サーバーは更新されたストレージクラスター情報をストレージノードに関連付けられたすべてのエージェントに送信します。その後、コンパニオンエージェントは、新しいノードの
rhq-storage-auth.conf
ホスト名または IP アドレスでストレージクラスター設定を更新します。(同様に、ノードが削除されると、サーバーは各エージェントに情報を送信し、エージェントはローカルストレージノードのrhq-storage-auth.conf
ファイルのリストからホスト名または IP アドレスを削除します)。 - サーバーは、(ストレージノードに関連するものだけでなく)すべてのエージェントから監視データを受信し、その情報を利用可能なストレージノードに送信して保存します。
- ストレージノードは、高可用性と整合性を確保するために、相互に監視データを複製します。
図24.1 サーバー、エージェント、およびメトリクスストレージノードの通信
- に保管されているすべてのストレージノードのホスト名または IP アドレス
rhq-storage-auth.conf
- JBoss ON サーバーがストレージノード(クライアントポート)との通信に使用する一般的な ポート番号。
- 相互にデータの同期に使用するクラスター内の他のストレージノード用の共通のポート番号( ゴシップポート)
- ストレージノード間のデータの複製(ゴシップポート上)
- ローカルスナップショットの取得およびローカルデータのバックアップ
24.3.2. ストレージノードのデプロイおよびアンデプロイ
- ビットはローカルシステムにインストールされ、ストレージノードが JBoss ON サーバーに登録されます。
- 新しいノード情報はクラスターにデプロイされます。
24.3.2.1. ストレージノードの要件
- すべてのストレージノードのホスト名および IP アドレス、JBoss ON サーバーおよびエージェントのホスト名およびバインドアドレスはすべて DNS で完全に解決できる必要があります。ストレージノード、サーバー、またはエージェントの IP アドレスおよびホスト名が DNS で適切にフォーマットされていない場合は、異なる JBoss ON コンポーネント間の通信はすべて失敗します。
- ファイアウォールは、ストレージノードで使用される 2 つのポートでの通信を許可する必要があります。デフォルトでは、ポートはサーバー/クライアントの 9142 と 7100、ゴシップポートの場合はそれぞれ 9142 と 7100 です。
24.3.2.2. 追加ノードのインストール
rhq-storage.properties
ファイルを編集します。
--agent-preference
オプションを指定してインストールスクリプトを実行し、サーバーバインドアドレスを指定します。例:
[root@server ~]# serverRoot/jon-server-3.3.0.GA/bin/rhqctl install --storage --agent-preference="rhq.agent.server.bind-address=0.0.0.0"
図24.2 クラスターの参加
rhq-storage-auth.conf
ファイルへのアクセスを制限して、攻撃者がクラスターおよび保存されたデータにアクセスできるようにします。
24.3.2.3. ノードの手動によるデプロイ
rhq-storage-auth.conf
ファイルへのアクセスを制限して、攻撃者がクラスターおよび保存されたデータにアクセスできるようにします。
- rhqctl install コマンドを使用してノードをインストールします。
- トップナビゲーションバーの Administration タブをクリックします。
- 左側の Topology エリアで Storage Nodes 項目を選択します。
- Nodes タブで、デプロイするノードの行を選択します。
- Deploy ボタンをクリックします。
// deploy a storage node nodes = StorageNodeManager.findStorageNodesByCriteria(StorageNodeCriteria()); node = nodes.get(0); StorageNodeManager.deployStorageNode(node);
24.3.2.4. ノードの削除
- トップナビゲーションバーの Administration タブをクリックします。
- 左側の Topology エリアで Storage Nodes 項目を選択します。
- Nodes タブで、削除するノードの行を選択します。複数の行を選択するには、Ctrl キーを保持し、希望の行をクリックします。
- Undeploy Selected ボタンをクリックして操作を確認します。
// undeploy a storage node nodes = StorageNodeManager.findStorageNodesByCriteria(StorageNodeCriteria()); node = nodes.get(0); StorageNodeManager.undeployStorageNode(node);
第25章 アラートの定義
25.1. アラートのプランニング
- 名前、優先度、およびアクティブかどうかの特定に使用する特定のアラート定義「リソースに対するアラート設定の基本的な手順」
- アラートをトリガーする条件。これは、監視するリソースのエリア(「アラート条件」)によって異なります。
- アラートの送信に使用する方法および設定「アラートへの対応」
25.1.1. 4 つの質問におけるアラートストラテジー
25.1.1.1. What's the Condition?
25.1.1.2. What's the Frequency?
25.1.1.3. What's the Response to take?
25.1.1.4. 数多くのリソースがこの影響を及ぼすか?
25.1.2. リソースに対するアラート設定の基本的な手順
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- 一覧のリソース名をクリックします。
- リソースの Alerts タブをクリックします。
- Definitions サブタブで New ボタンをクリックして新しいアラートを作成します。
- General Properties タブで、アラートに関する基本情報を指定します。
- 名前。特定のアラート定義の名前を指定します。これはリソースに対して一意である必要があります。
- 説明。アラートのオプションの説明が含まれます。これは、同じリソースに対してさまざまな種類のアラート応答をトリガーする場合に非常に便利です。
- priority。この定義によってトリガーされるアラートに提供される優先度または重大度を設定します。
- Enabledアラート定義がアクティブであるかどうかを設定します。アラート定義を無効にして、リソースにネットワークの停止や定期的なメンテナンスウィンドウがある場合などに不必要で、誤ったアラートを防ぎます。
- Conditions タブで、アラートをトリガーするメトリクスまたは課題を設定します。Add ボタンをクリックして条件フォームを表示します。注記アラートをトリガーするために複数の条件が設定されている可能性があります。たとえば、CPU の CPU が 25% を超え、利用可能なメモリーが 25MB を下回る場合にのみ 、 サーバーの通知を受け取ることができます。条件の ALL 設定では、両方の基準が満たされる場合にのみアラート通知が通知に限定されます。いずれかの状況を把握して、ネットワークの負荷分散設定を即時に変更することができます。この場合、1 つの条件 ANY しきい値が満たされるとすぐに通知が出力されます。
- Add a new condition ボタンをクリックします。
- 初期ドロップダウンメニューから、条件のタイプを選択します。条件のカテゴリーと 「アラートの調整の理由」、すべてのリソースに設定できる正確な条件は、『Resource Monitoring Reference』 に一覧表示されます。
- 条件の値を設定します。
- Notifications タブで Add をクリックし、アラートの通知を設定します。
- Sender オプションでアラート通知を送信するために使用するメソッドを選択します。Sender オプションは、最初に特定のタイプのアラートメソッド(電子メールや SNMP など)を設定し、適切なフォームを開いてその方法の詳細を入力します。
- アラート送信メソッドに必要な情報を入力します。この方法では、選択した内容に応じて、連絡先、SNMP 設定、操作、またはスクリプトが必要になる場合があります。
- Recovery タブで、リソースの状態が復旧するまでアラートを無効にするかどうかを設定します。必要に応じて、このアラートの発生時に別のアラートを選択し(またはリカバリー)。リカバリーアラートは無効なアラートを取得し、再度有効にします。これは、可用性がダウンしてからバックアップされるタイミングを示すアラートのペアなど、状態の変更を示す 2 つのアラートに使用されます。
- Dampening タブで、同じアラートイベントの通知を送信する頻度について、細分化(または頻度)ルールを付けます。アラートを送信する頻度は、リソースの想定される動作によって異なります。アラートの送信が多すぎる場合と、数が多いアラートを送信するには、バランスが必要です。周波数の設定は複数あります。
- 連続 している。条件がメトリック計算のために特定の回数で発生する場合にアラートを送信します。たとえば、これが 3 に設定される場合、アラートを発生させるには、3 つの連続するメトリクスコレクション期間で条件を検出する必要があります。これが 1 に設定されている場合は、条件が発生するたびにアラートを送信します。
- 最後の N 評価これは、アラートを送信する前に、特定の数のモニタリング評価サイクルで条件が発生する回数を設定します。
- 期間。他の 2 つの破損ルールは、JBoss ON のモニタリングサイクルに基づいて再帰を設定しました。これにより、特定の期間に基づいてアラートルールが設定されます。
- OK をクリックし、アラート定義を保存します。
25.1.3. アラート定義の有効化および無効化
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- Alerts タブをクリックします。
- Definitions サブタブで、いずれかの定義を選択して有効または無効にします。
- Enable または Disable ボタンをクリックします。
- アクションを確認します。
25.1.4. グループアラートおよびアラートテンプレート
- アラートテンプレート
- 互換性のあるグループのアラート
25.1.4.1. アラート定義テンプレートの作成
- トップナビゲーションでメニューを開き、Administration Configuration メニューを開きます。
- Alert Templates メニュー項目を選択します。これにより、プラットフォームおよびサーバータイプ両方のリソースタイプが長いリストが開きます。
- テンプレート定義を作成するリソースのタイプを見つけます。
- New ボタンをクリックしてグローバルアラート定義を作成します。アラートを単一のリソースのアラートを設定する場合と全く同じように設定します(を参照 「リソースに対するアラート設定の基本的な手順」)。
- テンプレートを保存します。
25.1.4.2. グループアラートの設定
- トップメニューの Inventory タブで、Groups 左側のメニューの Compatible Groups 項目を選択します。
- メインウィンドウでグループを選択し、アラートを追加します。
- グループの Alerts タブをクリックします。
- Definitions サブタブで、New ボタンをクリックします。
- にあるように、基本的なアラート定義および通知を設定し 「リソースに対するアラート設定の基本的な手順」 ます。
25.2. アラート条件
25.2.1. アラートの調整の理由
表25.1 アラート条件のタイプ
条件のタイプ | description |
---|---|
メトリクス | 確認される特定の監視エリアと、応答をトリガーするその領域のしきい値。通常、メトリクスは何らかの数値の応答です(CPU の使用率、要求数、またはキャッシュヒット比率など)。 |
trait | 特定の設定の値の変更。特性は通常文字列の値です。 |
可用性 | このリソースが利用できるかどうかが突然変更されています。 |
operation | リソースで実行される特定のアクションまたはタスク。 |
イベント | 特定のタイプのエラーメッセージが記録されます。イベントはシステムまたはアプリケーションのログファイルからフィルターされ、JBoss ON で認識されるイベントのタイプは、リソースのイベント設定によって異なります。 |
drift | 事前定義された設定からリソースが変更されました。 |
25.2.2. 詳細なディスカッション: 条件のある Ranges、AND、および OR 演算子
図25.1 アラート条件の範囲
25.2.3. 詳細なディスカッション: ログファイルメッセージに基づく条件
図25.2 ログファイルの条件
25.2.4. 詳細ディスカッション: フレームワーク
図25.3 Dampening Filter
- JBoss ON は、条件が発生するたびにアラートを送信できます。この場合、CPU のパーセンテージがバウンスした場合に複数のアラートが発行されますが、これに一時的にヒットまたはヒットした場合にアラートが送信されるのは 1 つのアラートだけです。
- JBoss ON は、条件が連続して、または Y 回のポーリング数の X 回数で発生した場合にのみアラートを送信できます。この場合、繰り返しまたは持続された問題のみがアラートをトリガーします。通知を出力するには不十分です。状態は、問題になるために短期間に複数回発生する必要がある場合がありますが、一度は問題ではありません。たとえば、サーバーが数分で 7 つの CPU から 80% までの CPU をバウンスする可能性があり、数秒で 1 分の 1 に達する可能性があります。あるいは、8 分の 1 に達する可能性があり、そこに留まる可能性があります。この条件は、CPU のヒット率 20% が残り、他の読み取りは無視されます。
- 設定した期間内に問題が発生した場合にのみ通知が送信されます。これは、繰り返し発生する問題の頻度を追跡したり、状態が持続する期間を追跡するのに便利です。
25.2.5. 詳細なディスカッション: アラートの自動無効化およびリカバリー
- アラートのペアは、相互トグルスイッチとして機能します。あるアラートがアクティブな場合、もう 1 つは無効になります。Alert A が起動すると、指定した Alert B をリカバリーするように設定できます。したがって、Alert B は基本的にその代わりに使用されます。
- アラートは CAScade の種類として機能します。Alert A が起動すると、Alert B が有効になり、Alert C が有効になります。場合によっては、特定の状態が問題にならない可能性がありますが、短期間に連続して発生すると問題になります。
図25.4 アラートの無効化およびリカバリー
Setup: Toggle Recover Alerts for Availability
Tim(IT 管理者)には、電子メールのルーティングやその他のオペレーションに使用する複数のサーバーがあり、バックアップとして予約している複数のマシンがあります。
The Plan
Tim は、メールサーバー間の移行を処理するため、アラート定義のセットを作成します。
- mail-server-a プラットフォームの可用性の状態が ダウンすると、最初のアラート定義が 実行されます。この通知は、以下の点をいくつか行います。
- 最新のメールサーバー設定でバンドルを別のプラットフォームにデプロイする mail-server-b。
- コマンドラインスクリプトを実行し、メールサービス mail-server-b を起動します。
- Email Tim the IT Guy to know that mail-server-a is unavailable.
リカバリーでは、アラートは以下の 2 つの処理を行います。- 現在のアラートを無効にします。バックアップサーバーをオンラインにするには、一度だけ起動する必要があります。
- JBoss ON がバックアップを待機するよう mail-server-a に、アラート B を回復(または有効化)します。
- 2 つ目のアラート定義 Alert B は、mail-server-a がオフライン時 にのみ有効です。このアラートは、可用性の状態 が mail-server-b 変更されるとすぐに実行されます。
- このアラート定義は、基本的にダウンして mail-server-a いる限り待機します。オンラインに mail-server-a 戻ると、Alert B の通知は、メールサービスを停止する mail-server-b ためのコマンドラインスクリプトの実行です。
- アラート B は、Tim the IT Guy に通知メールを送信し、再び mail-server-a 利用できることを通知します。
リカバリーでは、アラートは以下の 2 つの処理を行います。- 現在のアラートを無効にします。Alert A と同様に、Alert B は、プライマリーサーバーが復元するとすぐにバックアップを停止する必要があります。
- アラート A をリカバリー(または有効化)するので、JBoss ON は再びダウン mail-server-a するまで待機します。
25.3. アラートへの対応
25.3.1. 管理者への通知およびアラートへの応答
- 1 つ以上のアドレスへの電子メール
- SNMP トラップ
- JBoss ON ユーザーへのメッセージ
- リソース操作(アラートリソースまたはインベントリー内の他のリソース上)の実行
- リソーススクリプトの実行(特定タイプのリソース操作)
- JBoss ON CLI スクリプト
25.3.2. 詳細なディスカッション: 操作の開始
- アラート操作は、すべてのアラートまたはイベントに対応するために応答的に実行されます。
- アラート操作は、JBoss ON インベントリーの 任意 のリソースで開始できます。アラート操作は、アラートを送信したリソースのみに限定されます。つまり、同じホストサーバーで、または全く異なるサーバーでも、異なるアプリケーションに対して操作を実行できます。
25.3.2.1. アラート操作でのトークンの使用
<%space.param_name%>
表25.2 利用可能なアラート操作トークン
... に関する情報 | token | description |
---|---|---|
Started Alert | alert.willBeDisabled | アラート定義は、起動後に無効にするか。 |
Started Alert | alert.id | この特定アラートの ID |
Started Alert | alert.url | アラートの詳細ページの URL |
Started Alert | alert.name | 定義するアラート定義の名前 |
Started Alert | alert.priority | このアラートの優先度 |
Started Alert | alert.description | このアラートの説明 |
Started Alert | alert.firedAt | アラートの発生時間 |
Started Alert | alert.conditions | このアラートの原因となった条件のテキスト表現 |
アラートリソース | resource.id | リソースの ID |
アラートリソース | resource.platformType | リソースが有効なプラットフォームのタイプ |
アラートリソース | resource.platformName | リソースが置かれているプラットフォームの名前 |
アラートリソース | resource.typeName | リソースタイプ名 |
アラートリソース | resource.name | リソースの名前 |
アラートリソース | resource.platformId | リソースが有効なプラットフォームの ID |
アラートリソース | resource.parentName | 親リソースの名前 |
アラートリソース | resource.parentId | 親リソースの ID |
アラートリソース | resource.typeId | リソースタイプ id |
ターゲットリソース | targetResource.parentId | ターゲットの親リソースの ID |
ターゲットリソース | targetResource.platformName | ターゲットリソースがオンになっているプラットフォームの名前 |
ターゲットリソース | targetResource.platformId | ターゲットリソースがオンになっているプラットフォームの ID |
ターゲットリソース | targetResource.parentName | ターゲットの親リソースの名前 |
ターゲットリソース | targetResource.typeId | ターゲットリソース ID のリソースタイプ |
ターゲットリソース | targetResource.platformType | ターゲットリソースがオンになっているプラットフォームのタイプ |
ターゲットリソース | targetResource.name | ターゲットリソースの名前 |
ターゲットリソース | targetResource.id | ターゲットリソースの ID |
ターゲットリソース | targetResource.typeName | ターゲットリソースのリソースタイプ名 |
operation | operation.id | 実行された操作の ID |
operation | operation.name | 操作が実行された名前 |
25.3.2.2. アラート操作の設定
図25.5 送信元
図25.6 リソースの選択
図25.7 操作の設定
25.3.3. 詳細なディスカッション: リソーススクリプトの開始
図25.8 リソーススクリプト設定
25.3.4. 詳細ディスカッション: アラートからの JBoss ON CLI スクリプトの起動
25.3.4.1. CLI スクリプト通知の使用に関する注意事項
CLI スクリプトがコンテンツである
リソーススクリプトとは異なり、CLI スクリプトはインベントリーのリソースとして扱われません。これらのツールは、JBoss ON サーバー自体が利用でき、(指定リソースには限定されず、関連付けるものではありません)。
CLI スクリプトおよびリモート API
CLI スクリプトは、サーバーで操作を実行するには適切な API を使用する必要があります。JBoss ON には、実行するタスクに応じて複数の異なる API セットがあります。サーバーに接続し、スクリプトを実行するには、サーバーでコマンドをリモートで実行できる リモーティング API が必要です。
CLI スクリプトでのアラートオブジェクトの参照
CLI スクリプトは、事前定義された アラート 変数を使用してスクリプトをトリガーするアラートオブジェクトのアラートオブジェクトを参照できます。
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)
CLI スクリプトの制限
リソース自体には、CLI スクリプトを実行できる場所や実行できる操作に制限が生じる場合があります。たとえば、セキュリティー上の理由から、CLI スクリプトはローカルリソース(CLI スクリプトを実行しているサーバーでルックアップを実行する)で JNDI ルックアップを実行できませんが、リモート JNDI ルックアップを実行できます。もう 1 つの一般的な問題は、JBoss ON サーバーがそれ自体で再起動操作を実行できないことです。
25.3.4.2. アラート関連の CLI スクリプトの作成
var myResource = ProxyFactory.getResource(alert.alertDefinition.resource.id) var definitionCriteria = new MeasurementDefinitionCriteria() definitionCriteria.addFilterDisplayName('Sessions created per Minute') definitionCriteria.addFilterResourceTypeId(myResource.resourceType.id) var definitions = MeasumentDefinitionManager.findMeasurementDefinitionsByCriteria(definitionCriteria) if (definitions.empty) { throw new java.lang.Exception("Could not get 'Sessions created per Minute' metric on resource " + myResource.id) } var definition = definitions.get(0) var startDate = new Date() - 8 * 3600 * 1000 //8 hrs in milliseconds var endDate = new Date() var data = MeasurementDataManager.findDataForResource(myResource.id, [ definition.id ], startDate, endDate, 60) exporter.setTarget('csv', '/the/output/folder/for/my/metrics/' + endDate + '.csv') exporter.write(data.get(0)) var dataSource = ProxyFactory.getResource(10411) connectionTest = dataSource.testConnection() if (connectionTest == null || connectionTest.get('result').booleanValue == false) { //ok, this means we had problems connecting to the database //let's suppose there's an executable bash script somewhere on the server that //the admins use to restart the database java.lang.Runtime.getRuntime().exec('/somewhere/on/the/server/restart-database.sh') }
/alert-scripts/
。
25.3.4.3. CLI スクリプト通知の設定
- スクリプトをコンテンツリポジトリーにアップロードします。注記アラート CLI スクリプト用に個別のリポジトリーを作成します。
- リソースを検索し、にあるように基本アラート定義を設定し 「リソースに対するアラート設定の基本的な手順」 ます。
- アラート定義の Notifications タブで、通知メソッドに名前を付け、Alert Senders ドロップダウンメニューから CLI Script メソッドを選択します。
- まず、スクリプトを実行するときに JBoss ON ユーザーを選択します。デフォルトは、通知を作成するユーザーです。
- CLI スクリプトが含まれるリポジトリーを選択します。新しいスクリプトをアップロードする場合は、スクリプトを追加するリポジトリーです。
- ドロップダウンメニューから使用する CLI スクリプトを選択します。指定したリポジトリーのすべてのスクリプトが一覧表示されます。Upload ボタンをクリックして、ローカルマシンのスクリプトを参照します。
- OK をクリックし、通知を保存します。Notifications タブ内の行には、スクリプト、リポジトリー、および実行されるユーザーが表示されます。
25.3.5. 通知用の SNMP の設定
- サーバーの SNMP アラートプラグインの設定。
- SNMP 通知を使用して実際のアラートを設定する。
25.3.5.1. JBoss ON SNMP 情報
/etc/RHQ-mib.txt
。MIB のデフォルト設定がに表示され 例25.1「JBoss ON MIB のデフォルトのアラートオブジェクト」 ます。JBoss ON アラートのベース OID は 1.3.6.1.4.1.18016.2.1 (org.dod.internet.private.enterprise.jboss.rhq.alert)です。
例25.1 JBoss ON MIB のデフォルトのアラートオブジェクト
--internet(1.3.6.1) +--private(4) | +--enterprises(1) | +--jboss(18016) | +--rhq(2) | +--alert(1) | | +-- r-n DisplayString alertName(1) | | +-- r-n DisplayString alertResourceName(2) | | +-- r-n DisplayString alertPlatformName(3) | | +-- r-n DisplayString alertCondition(4) | | +-- r-n DisplayString alertSeverity(5) | | +-- r-n DisplayString alertUrl(6) | | +-- r-n DisplayString alertHierarchy(7) | +--alertNotifications(2) | | +--alertNotifPrefix(0) | | +--alertNotification(1) [alertName,alertResourceName,alertPlatformName,alertCondition,alertSeverity,alertUrl,alertHierarchy] | +--rhqServer(3) +--snmpV2(6) +--snmpModules(3) +--rhqMIB(1) +--rhqTraps(3) +--rhqTrapPrefix(0)
[root@server ~]# snmptrapd -m RHQ-MIB -M/opt/local/share/mibs/ietf
-M
では、SNMP サーバーの MIB ディレクトリーへのパスを指定します。
Jul 8 15:13:31 snert snmptrapd[42372]: 127.0.0.1: Enterprise Specific Trap (.0) Uptime: 0:00:00.00, RHQ-MIB::alertName = STRING: test, RHQ-MIB::alertResourceName = STRING: snert, RHQ-MIB::alertPlatformName = STRING: snert, RHQ-MIB::alertCondition = STRING: - Condition 1: Free Memory < 1.024,0MB - Date/Time: 2013/07/08 15:13:05 MESZ - Details: 12,9MB , RHQ-MIB::alertSeverity = STRING: medium, RHQ-MIB::alertUrl = STRING: http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/12204, RHQ-MIB::alertHierarchy = STRING: snert
22:06:19.043208 IP localhost.56445 > localhost.snmptrap: Trap(352) E:18016.2.3 0.0.0.0 enterpriseSpecific s=0 0 E:18016.2.1.1="test" E:18016.2.1.2="snert" E:18016.2.1.3="snert" E:18016.2.1.4="^J- Condition 1: Free Memory < 4,0GB^J- Date/Time: 2013/07/10 22:06:01 MESZ^J - Details: 179,2MB^J" E:18016.2.1.5="medium" E:18016.2.1.6="http://localhost:7080/coregui/CoreGUI.html#Resource/10001/Alerts/History/10038" E:18016.2.1.7="snert"
25.3.5.2. SNMP アラートプラグインの設定
- トップメニューで、Administration タブを選択します。
- System Configuration メニューで ServerPlugins 項目を選択します。
- リスト内の SNMP プラグインの名前をクリックします。
- プラグインの詳細ページで Plugin Configuration セクションを展開します。
- 必要な SNMP 設定を入力します。
- 適切な SNMP バージョンを選択します。
- SNMP トラップサーバーのホスト名、ポート番号、およびトランスポートプロトコルを指定します。デフォルトの設定は、JBoss ON サーバーおよびポート 162 の localhost を参照します。
- トラップ OID を設定します。これはデフォルトでは RHQ OID です。
- SNMP 1 および 2 の場合コミュニティーに名前を付けます。
注記これにより、SNMP アラート通知のグローバルデフォルトが設定されます。アラート定義の作成時に、個別のアラート通知に異なる設定を指定することができます。 - SNMP バージョン 1 およびバージョン 3 には、表25.3「SNMP v1 構成設定」 およびに記載されている追加設定が必要です 表25.4「SNMP v3 構成設定」。バージョン固有の設定セクションを展開し、SNMP エージェントに関する情報を入力します。フィールドを編集するには、チェックボックスの選択を Unset 解除する必要がある場合があります。
表25.3 SNMP v1 構成設定
フィールド | description |
---|---|
汎用 ID | トラップの ID。SNMP 標準は 0-6 の数字を定義します。6 は企業固有を意味します。これはデフォルトです。 |
Enterprise OID | JBoss ON サーバー自体の OID。デフォルト値は RHQ MIB から SMIv2.enterprise.jboss.rhq.rhqServer として取得されます。 |
特定の OID | トラップ通知で使用するカスタム OID。これは空にすることができます。 |
エージェントアドレス | アラート送信者の IP アドレス(JBoss ON サーバーの IP アドレス)。 |
表25.4 SNMP v3 構成設定
フィールド | description |
---|---|
Auth プロトコル | 認証要求の暗号化アルゴリズム。これを設定するには、対応する認証パスフレーズを設定する必要があります。パスフレーズがない場合、この値はである必要があり noneます。 |
プライバシープロトコル | トラップメッセージで使用する暗号化方法を設定します。これは認証プロocol に使用されます。 |
エンジン ID | |
ターゲットコンテキスト名 | |
認証パスフレーズ | 認証に使用されるパスワードを設定します。最小長は 8 文字です。これは、Auth Protocol 値が設定されている場合に必要になります。 |
プライバシーパスフレーズ | 暗号化通信の管理に使用するパスワードを設定します。これは、認証が使用される場合に必要になります。 |
セキュリティー名 | トラップレシーバーへの認証に使用するユーザー名を指定します。 |
25.3.5.3. SNMP アラート通知の設定
図25.9 JBoss ON SNMP トレース情報
- SNMP マネージャーのホスト名。これが設定されていない場合、グローバル設定のデフォルトが使用されます。
- SNMP マネージャーのポート番号。これが設定されていない場合、グローバル設定のデフォルトが使用されます。
- 変数バインディングのプレフィックス。オプション。これにより、指定の文字列がトラップによって送信される個々の変数の先頭に追加されます。これは、トラップを送信する JBoss ON サーバー、リソース、またはアラートを識別する方法になります。デフォルトは RHQ MIB で設定され SMIv2.enterprise.jboss.rhq.alertます。
- トラップ OID。これは、トラップ定義で使用する特定の OID です。これが設定されていない場合、グローバル設定のデフォルトが使用されます。デフォルトでは、これは RHQ-MIB です 1.3.6.1.4.1.18016.2.1。
25.4. アラートデータの表示
25.4.1. アラート定義レポートの表示
- トップナビゲーションバーの Reports タブを選択します。
- 左側の Subsystems メニューボックスで、を選択し Alert Definitionsます。
- 定義レポートには、インベントリー内のすべてのリソースに設定されたすべての定義の一覧が表示されます。結果表は、定義に最も基本的な情報を提供します。
- リソース(Name)。
- 親または ancestry。リソースが階層的に編成されるため、親はサーバーのようなハイレベルリソースに関連するすべてのサービスとアプリケーションのアラート定義をすべて検索する際に非常に便利です。
- アラートの説明。
- アクティブ(有効)であるかどうか。
alertDefinitions.csv
ます。
25.4.2. アラートの表示
25.4.2.1. 特定リソースのアラート詳細の表示
- トップメニューの Inventory タブをクリックします。
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リスト内のリソースをクリックします。
- タブをクリックし、History サブ Alerts タブが選択されていることを確認します。
- 一覧で、発生するアラートのタイムスタンプまたはアラート定義名をクリックします。
- アラートページには、アラートの詳細に関するタブがあります。これには、トリガーされたアラート定義、トリガーされた状態、結果として起動された操作が含まれます。
25.4.2.2. Fired Alerts レポートの表示
- トップナビゲーションバーの Reports タブを選択します。
- 左側の Subsystems メニューボックスで、を選択し Recent Alertsます。
- リソース(Name)
- 親(ancestor)
- アラートをトリガーした定義の名前
- アラートを発生させた条件
- アラートの送信時のリソースの値
- 日付: アラート通知を外部イベントと関連付ける際に役立ちます。
recentAlerts.csv
ます。
25.4.2.3. Dashboard でのアラートの表示
図25.10 最近のアラートポートレット
- アラートが発生した時点の時間範囲
- アラートの Name 内のサブ文字列
- アラートの優先度(アラート定義で最初に設定される)
- トップメニューでをクリックし Dashboardます。
- Recent Alerts ポートレットで歯車アイコンをクリックして、ポートレット設定ページを開きます。
- 必要に応じて表示基準を変更します。
25.4.3. アラートの承認
- Recent Alerts レポート経由
- グループ経由
- リソースエントリー経由
- トップナビゲーションバーの Reports タブを選択します。
- 左側の Subsystems メニューボックスで、を選択し Recent Alertsます。
- 確認応答するアラートを選択します。
- Acknowledge ボタンをクリックし、プロンプトが表示されたらアクションを確認します。
図25.11 アラートの承認
パート IV. アプリケーションとコンテンツのデプロイ
第26章 サマリー: JBoss ON を使用したアプリケーションのデプロイおよびコンテンツの更新
- タブを介したリソースレベルの Content コンテンツ
- バンドルを使用したアプリケーションのプロビジョニング
- リソースにパッケージ、更新、およびパッチを提供できます。
- リソースにコンテンツをデプロイしたり、新しい子リソースを作成したりすることもできます。これは、異なるコンテキストを子として持つことができる Web やアプリケーションサーバーで特に役に立ちます。
- リソースにインストールされた現在のパッケージを検出し、管理者がそのアセットの管理に使用できるパッケージダイジェストを作成できます。
- Ant 呼び出しを使用してバンドルのデプロイ前後の操作を実行します。
- ユーザー定義の値を許可するか、バンドルがプロビジョニングされるときに設定に編集できるようにします。
- 複数のバージョンのコンテンツバンドルがデプロイされ、deployable がリソースに同時にデプロイされている。
- 以前のバンドルバージョンに戻す
第27章 バンドルへのコンテンツおよびアプリケーションのデプロイ
27.1. コンテンツバンドルのプロビジョニングの概要
27.1.1. バンドル: コンテンツおよびレシピ
deploy.xml
。これは常にバンドルアーカイブの最上位に置く必要があります。
図27.1 バンドルレイアウト
27.1.2. 宛先(およびバンドルデプロイメント)
- 互換性のあるリソースグループ(プラットフォームまたは JBoss サーバーのいずれか)
- ベースの場所。バンドルのデプロイに使用するルートディレクトリー。リソースプラグインは、<bundle-target> 要素内の特定のリソースタイプのベースの場所を定義します。これは、ルートディレクトリーや、プロファイルディレクトリーなどの共通のディレクトリーである JBoss サーバーになります。利用可能なベースの場所が複数ある可能性があります。
- deployment ディレクトリー。バンドルのコンテンツが実際に送信されるベースディレクトリー下のサブディレクトリーです。
deploy/myApp/
ディレクトリー内の JBoss EAP 5 サーバーに web アプリケーションをデプロイします。JBoss AS5 プラグインは、インストールディレクトリー用と profile ディレクトリー用のベースの場所を 2 つ定義します。アプリケーションは展開形式の JAR ファイルであるため、管理者はプロファイルディレクトリーを選択します。次にエージェントは、これらの 3 つの要素からアプリケーションの実際の絶対パスを取得します。
JBoss AS group + {$PROFILE_DIR} + deploy/myApp/
/opt/jbossas/default/server/
、宛先は以下のようになります。
/opt/jbossas/default/server/deploy/myApp/
C:\jbossas\server\
、プラットフォームに適したパスが若干異なります。
C:\jbossas\default\server\deploy\myApp
図27.2 バンドル、バージョン、および宛先
27.1.3. プロビジョニング中のファイル処理
デプロイメントにおける動作
バンドルファイルには、リソースにプッシュする必要があるファイルおよびディレクトリーのセットが含まれます。ただし、プロビジョニングプロセスでは、単にファイルをデプロイメントディレクトリーにコピーする訳ではありません。プロビジョニングはバンドルを、基本的にターゲット(root)ディレクトリーのコンテンツ構造全体を定義するテンプレートとして扱います。
app.conf lib/myapp.jar
deploy/myApp/
、最終的な設定は以下のようになります。
deploy/myApp/app.conf deploy/myApp/lib/myapp.jar
deploy/myApp/
、バンドルがコピーされる前に削除されます。これにより、デプロイメントディレクトリーはバンドルの設定方法が完全に表示されます。
deploy/myApp/
、この動作は完全に許可されます。ただし、バンドルにはさまざまなコンテンツを含めることができ、ほぼプラットフォームや JBoss サーバー内にデプロイできます。実際のインフラストラクチャーの多くは、バンドルがデプロイされるディレクトリーには既存のデータを保持する必要がある場合があります。
/etc
をデプロイする場合 deploy/
conf/
、そのディレクトリーにある既存ファイルおよびサブディレクトリーがすべて削除されます。これにより、パフォーマンスの問題やデータ損失が発生する可能性があります。
バンドルおよびサブディレクトリー
compliance オプションが filesAndDirectories に設定されていても 、 バンドルに含まれるサブディレクトリーやファイルは、バンドルのデプロイ前に存在していた場合でも常にバンドルによって管理されます。
deploy/
ディレクトリーには、バンドルがデプロイされる前にこのレイアウトがあります。
deploy/ deploy/notes.txt deploy/myApp1/ deploy/myApp2/ deploy/myApp2/first.txt
myApp2/ myApp2/foo.txt myApp2/bar.txt
myApp2/
サブディレクトリーに ある 既存ファイルは deploy/
変更されません。つまり、ディレクトリーの最終的なレイアウトは以下のようになります。
deploy/ (ignored) deploy/notes.txt (ignored) deploy/myApp1/ (ignored) deploy/myApp2/ (managed) myApp2/foo.txt (managed) myApp2/bar.txt (managed)
/home/.rhqdeployments/
です/backup
。
バンドルのデプロイ後に追加されたファイル
初回のデプロイメント後に、ログファイルや追加のデータなど、デプロイメントディレクトリーにファイルが追加されるインスタンスが存在する可能性があります。
27.1.4. 要件およびリソースタイプ
- プラットフォーム、全タイプ
- JBoss EAP 6(AS 7)スタンドアロンサーバー [5]
- JBoss AS 5 プラグインを使用する JBoss EAP 5 およびすべてのサーバー
- JBoss EAP 4(非推奨)
27.1.5. Provisioning and Agent User System Permission
27.1.6. プロビジョニングおよびロール
27.1.7. バンドルの領域に関する考慮事項
27.1.8. バンドルおよび JBoss ON Server およびエージェントプラグイン
27.1.8.1. リソースサポートおよびエージェントリソースプラグイン
<server name="JBossAS:JBossAS Server" ...> <bundle-target> <destination-base-dir name="Library Directory" description="Where the jar libraries are"> <value-context>pluginConfiguration</value-context> <value-name>lib.dir</value-name> </destination-base-dir> <destination-base-dir name="Deploy Directory" description="Where the deployments are"> <value-context>pluginConfiguration</value-context> <value-name>deploy.dir</value-name> </destination-base-dir> </bundle-target> </server>
deploy/
とディレクトリーの 2 つがサポート対象のベース lib/
ディレクトリーとして提供されます。バンドル定義が作成されると、ウィザードは使用するディレクトリーを選択できます。
27.1.8.2. レシピタイプのサーバー側のプラグインおよびエージェントプラグイン
27.1.9. JBoss ON CLI を使用したバンドルの管理およびデプロイ
- 既存の JBoss サーバーのパフォーマンスが大きい場合やパフォーマンスが低下すると、新しい JBoss アプリケーションサーバーをデプロイすることができます。
- 選択したスナップショットイメージの設定ファイルは、ドリフトアラートに対応して、プラットフォームまたは JBoss サーバーに即座にデプロイして、設定のドリフトを再処理できます。
- 新しい Web コンテキストは、mod_cluster ドメイン内で別の Web が無効になっている場合にデプロイできます。
27.2. 拡張例: Common Provisioning Use Cases(およびどのように処理ファイルがあるか)
- 完全なアプリケーションサーバーのデプロイメント
- アプリケーションサーバーへの Web アプリケーションのデプロイメント
- 設定ファイルのデプロイ
27.2.1. フルアプリケーションサーバーのデプロイメント
バンドルの詳細
これは、プロビジョニングシステムにおける、アプリケーションサーバー全体のデプロイのコアとなる方法です。このバンドルには、JBoss EAP のようなサーバー(Tomcat または Apache)などのサーバーの完全な設定スタックが含まれます。バンドルには、アプリケーションが使用するすべてのファイル(EAP サーバーの JAR と設定ファイルおよびスクリプト)、およびその EPA インスタンスにデプロイするすべての EAR または WAR Web アプリケーションが含まれます。すべてのアプリケーションサーバーと Web アプリケーションファイルおよびディレクトリーはアーカイブに圧縮され、Ant レシピを deploy.xml
定義します。
ファイル処理の詳細
これは完全なアプリケーションサーバーであるため、などの新しい(または空の)ディレクトリー内にデプロイされ /opt/my-application
ます。そのディレクトリーはアプリケーションサーバー専用となるため、バンドルによって完全に 管理 されます。
- バンドルディストリビューションファイルのファイルおよびサブディレクトリーのみがルートディレクトリーに置かれます。
- 既存のファイルまたはサブディレクトリーは削除されます。
- ファイルまたはサブディレクトリーがルートディレクトリーに追加されると、そのファイル(レシピでの設定)が明示的に無視されない限り、バンドルの更新時または再デプロイ時にファイルが削除されます。
27.2.2. Web アプリケーションのデプロイ
/opt/my-application/deploy
deploy/
ディレクトリー myApp1.war にデプロイすることです。
/opt/my-application/deploy/myapp1.war/
バンドルの詳細
この場合、バンドルファイルには WAR ファイルと deploy.xml
レシピのみが含まれます。
ファイル処理の詳細
アプリケーションサーバーとは異なり、Web アプリケーションをデプロイする際には、他の Web アプリケーションも deploy/
ディレクトリーにあります。バンドルシステムは、ルートディレクトリーを管理しないでください。つまり、バンドルに含まれていない場合でも、既存のファイルまたは新しいファイルは root ディレクトリー内で許可する必要があります。
deploy/myApp/
、バンドルのデプロイ時に、などのファイル deploy/myApp/
やサブディレクトリーのファイルはすべて deploy/myApp/WEB-INF/
上書きまたは削除されます。バンドルディストリビューション で定義されるサブディレクトリーは、バンドルシステムによって完全 に管理されます。
- 同じバンドルディストリビューションに含まれるすべての Web アプリケーションを含めます。たとえば、myApp2.war
deploy/
ディレクトリーにデプロイ myApp1.war およびデプロイするには、同じバンドルに WAR ファイルを追加し、deploy/myApp1.war/
deploy/myApp2.war/
同時にデプロイすることができます。 - すべての web アプリケーションを同じバンドルにロールできない場合があります。root ディレクトリー
deploy/
として使用する代わりに、サブディレクトリーをルートディレクトリーとして使用するバンドルディストリビューションが 2 つあります。たとえば、最初の Web アプリを使用して、最終的deploy/myApp1/
なデプロイメントができdeploy/myApp1/myApp1.war/
、2 つ目のアプリケーションが使用するとdeploy/myApp2/
、結果になりdeploy/myApp2/myApp2.war/
ます。これにより、2 つの Web アプリケーションをデプロイ、更新、および元に戻すことができます。
27.2.3. 設定ファイルのデプロイ
- の新しいログイン設定
server/default/conf/login-config/xml
- 新しい JMX コンソールユーザー
server/default/conf/props/jmx-console.properties
conf/
ディレクトリーです。
バンドルの詳細
バンドルには、管理者が使用する 2 つの新規ファイルだけでなく、conf/props/
サブディレクトリー conf/login-config/
とサブディレクトリーにあることが予想される すべて のファイルが含まれている必要があります。さらに、レシピの compliance パラメーターを filesAndDirectories に設定して、ルートディレクトリー内の既存の設定ファイルがすべて保持される よう にする必要が conf/
あります。
ファイル処理の詳細
Web アプリケーションをデプロイする場合と同様 に、既存のコンテンツを置き換えるのではなく、新しいコンテンツを追加することが意図されています。設定すると、バンドルデプロイメント以外のファイル compliance=filesAndDirectories のみが保存されます。ただし、バンドルには 2 つのサブディレクトリーが定義されているため、JBoss ON はこれらのサブディレクトリーのコンテンツをすべて管理します。これは、以下のようになります。
- レシピは、
conf/
ルートディレクトリー内の他のファイルを保持するためにバンドルを compliance=filesAndDirectories 設定する必要があります。 - バンドルのサブディレクトリー内のファイルは
conf/log-config/
、バンドルのデプロイ時conf/props/
に上書きされます。プロビジョニングプロセスは root ディレクトリー内のファイルを無視しますが、バンドルで特定されたサブディレクトリーのファイル(例: 更新、追加、または削除)ファイルを常に管理し、バンドルの内容に一致させます。 conf/log-config/
およびconf/props/
サブディレクトリーの既存のファイルはバンドルディストリビューションに含める必要があります。
/opt/bundle/
ます。次に、Ant インストール後のタスクは、root ディレクトリーからアプリケーションサーバーのディレクトリーに設定ファイルをコピーするレシピで定義でき conf/
ます。
27.3. 拡張例: アプリケーションを JBoss EAP サーバーへのプロビジョニング(計画)
設定
Tim the IT Guy at Example Co. は、Example のオンライン帯域管理アプリケーションである──App の完全なアプリケーションライフサイクルを管理する必要があります。QA には 2 つの環境があり、もう 1 つはライブサイト用です。どちらの環境にも、Windows サーバーと Linux サーバーが混在しています。
操作方法
Tim にとって最適な計画は、自分の理想的な QA と実稼働環境の設定を希望する方法から、後方作業を行うことです。
- QA 環境が必要...
- 新規ビルドは、週ごとに GIT リポジトリーから直接作成します。
- すべてのデプロイメントから開始する完全にクリーンなディレクトリー。
- サンプル Co. の web アプリケーションにはそれぞれ個別の QA 環境があるため、特定のサーバーで実行している唯一のアプリケーションになります。
- 実稼働環境では必要なもの
- JBoss ON で安全に保存できる安定したビルド。
- 履歴データを保存するには、以下を実行します。実稼働環境には、ログディレクトリーとユーザー提供のデータディレクトリーの両方があり、アプリケーションのアップグレード後も維持する必要があります。
- 同じ実稼働サーバーで複数の異なる Web アプリケーションが実行されます。
deploy/
ディレクトリーにデプロイする必要がありますが、実行するアプリケーションではないので、独自の webapp コンテキストサブディレクトリーを持ちます。これは、devel 環境では必須ではありませんが(⋮App が唯一のアプリケーションである場合)、最終的なデプロイメント先との一貫性を維持します。- どちらのレシピも
MusicApp.jar
、アプリケーション JAR ファイルのデプロイ時に展開されるように設定します。 - クライアントアーカイブファイルは展開さ
MyMusic.jar
れません(<rhq:file ... exploded="false">)。 - トークンは、raw 設定ファイルとポート番号、IP アドレス、およびアプリケーション名のレシピで定義されます。
- QA 環境には、常にプルーニングのデプロイメントが必要です。これには 3 つの設定が必要です。
- この compliance 値は常に 満杯 になるため、初回のデプロイメント時に既存のファイルは保持されません。
- <rhq:ignore> 要素は設定されないため、アップグレード中に生成されたファイルは保持されません。
- cleanDeployment オプションは、デプロイメントを自動化する JBoss ON CLI スクリプトで常に設定されます。これにより、新規バンドルをデプロイする前に、ディレクトリー内のバンドルに関連付けられたファイルがすべて削除されます。
- 実稼働環境では、アップグレード間で既存のデータを保持する必要があります。これには 2 つの設定が必要です。
- この compliance 値は常に filesAndDirectories で 、 初回のデプロイメント時に既存のファイルを保存します。
- 2 つの <rhq:ignore> 要素は、ログディレクトリー用と、サイトメンバーのアップロードを含むデータディレクトリー用に設定されます。
deploy.xml
とともにパッケージ化し、バンドル全体を JBoss ON ON に直接アップロードするため、JBoss ON データベースに保存されます。
deploy.xml
個別にアップロードしますが、関連するすべてのパッケージの GIT URL にプロビジョニングウィザードをポイントします。バンドルがデプロイされると、JBoss ON はリポジトリーからパッケージを取得します。
結果
Tim はバンドルのバンドル 1 を本番環境にデプロイし、バージョン 2 を QA 環境にデプロイしました。
27.4. バンドルの作成およびデプロイに関するワークフロー
- アプリケーションサーバー、個別の Web アプリケーション、ドリフト管理用の設定ファイルなど、アーカイブに含まれるファイルを特定します。
- バンドルをデプロイする場所の処理方法を決定します。既存のファイルおよびディレクトリーは、レシピの定義に応じて上書きまたは保持できます。これは 「プロビジョニング中のファイル処理」 およびで説明されてい 「警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル」 ます。
- デプロイされたコンテンツがポート番号、ホスト名、またはその他の設定を必要とするかどうかなど、デプロイメント固有の情報を特定します。これらの値の一部は設定ファイルでトークンを使用でき、プロビジョニングプロセスではデプロイメント時に特定の値を対話的に要求できます。トークンはで説明されてい 「Templatized 設定ファイルの使用」 ます。
- デプロイされるコンテンツを作成します。
- という名前の Ant レシピを作成し
deploy.xml
ます。レシピは、バンドルに含まれるコンテンツと設定ファイルと、コンテンツをバンドル宛先にデプロイする方法を定義します。インストール前およびインストール後のターゲットがサポートされます。したがって、ローカルシステムに追加の処理を行い、必要に応じてサービスを設定または開始できます。ANT レシピとタスクについては、「Ant Recipe の内訳」 およびで説明されてい 「Ant Task の使用」 ます。 - バンドルコンテンツ、設定ファイル、およびレシピを作成したら、それらのファイルをすべてバンドルアーカイブに圧縮します。これには、ディレクトリーの最上位に
deploy.xml
レシピファイルが必要で、そのファイルに対して相対的なディストリビューション内の他のdeploy.xml
ファイルが必要です。これは、を参照してください 「バンドル: コンテンツおよびレシピ」。注記JBoss ON では、バンドルアーカイブの JAR および ZIP 形式が許可されます。 - 必要に応じて、バンドルのデプロイヤーツールを実行して、バンドルが正しくフォーマットされていることを確認します。これは、で説明してい 「バンドルパッケージのテスト」 ます。
- バンドルをデプロイするリソースのグループを作成します。
- の説明に従って、バンドルを JBoss ON サーバーにアップロードし 「バンドルの JBoss ON へのアップロード」 ます。
- の説明に従って、バンドルをターゲットグループにデプロイし 「リソースへのバンドルのデプロイ」 ます。
27.5. Ant Bundles の作成
- Ant レシピファイルの名前
deploy.xml
- 関連するアプリケーションファイル。これらのアプリケーションファイルは、あらゆるものになりますが、一般的には 2 つのカテゴリーに分類されます。
- アーカイブファイル(JAR または ZIP ファイル)
- バンドルのデプロイ時にユーザーが値を定義するトークンが含まれる raw テキスト設定ファイル
27.5.1. サポート対象の Ant バージョン
表27.1 Ant および Ant Task Versions
ソフトウェア | version |
---|---|
ant | 1.8.0 |
Ant-Contrib | 1.0b3 |
27.5.2. 追加の Ant References
ant 情報リソース
- Apache Ant Documentation のメインページ
- Ant ビルドファイルのドキュメンテーション
- Liquibase データベーススキーマタスク
- ant-Contrib ドキュメント
27.5.3. Ant Recipe の内訳
deploy.xml
ます。
例27.1 Simple Ant Recipe
deploy.xml
ファイルをスクリプトとして識別し、provisioning Ant 要素を参照します。
<project name="test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">
<rhq:bundle name="Example App" version="2.4" description="an example bundle">
port
トークンでは 「Templatized 設定ファイルの使用」、<rhq:input-property> 要素はレシピで識別します。name
引数は token の input_field 値で、description
引数は UI で使用されるフィールドの説明と、値が必要であるかどうか、許可される構文、および指定するデフォルト値を設定します。(これはトークン自体を使用するファイルを一覧表示せず、トークン自体のみを使用します。)
<rhq:input-property name="listener.port" description="This is where the product will listen for incoming messages" required="true" defaultValue="8080" type="integer"/>
<rhq:deployment-unit name="appserver" preinstallTarget="preinstall" postinstallTarget="postinstall" compliance="filesAndDirectories">
/home/.rhqdeployments/
です/backup
。
name
は バンドル内の設定ファイルの 名前で、destinationFile はデプロイ後のファイルの相対パスおよびファイル名になります。
<rhq:file name="test-v2.properties" destinationFile="conf/test.properties" replace="true"/>
- 名前でアーカイブファイルを特定します。
- アーカイブの処理方法を定義します。簡単に説明すると、アーカイブをコピー先にコピーしてそのままにするか、アーカイブをアーカイブとしてそのままにするか、またはデプロイ後にアーカイブを抽出するかどうかを設定します。これはアーカイブの展開 と 呼ばれます。アーカイブが展開される場合は、必要に応じて、postinstall タスクを呼び出してファイルを移動するか、または編集できます。
- 永続する必要のあるトークンが含まれるアーカイブ内のファイルを特定します。これは子要素です <rhq:fileset>。これにより、ワイルドカードを使用してサブディレクトリーにファイルの種類やファイルを追加したり、処理するファイルを明示的に記述したりできます。
<rhq:archive name="MyApp.zip" exploded="true"> <rhq:replace> <rhq:fileset> <include name="**/*.properties"/> </rhq:fileset> </rhq:replace> </rhq:archive>
logs/
ディレクトリー内の *.log
ファイルはすべて保存されます。
<rhq:ignore> <rhq:fileset> <include name="logs/*.log"/> </rhq:fileset> </rhq:ignore> </rhq:deployment-unit> </rhq:bundle>
<target name="main" /> <target name="preinstall"> <echo>Deploying Test Bundle v2.4 to ${rhq.deploy.dir}...</echo> <property name="preinstallTargetExecuted" value="true"/> <rhq:audit status="SUCCESS" action="Preinstall Notice" info="Preinstalling to ${rhq.deploy.dir}" message="Another optional message"> Some additional, optional details regarding the deployment of ${rhq.deploy.dir} </rhq:audit> </target> <target name="postinstall"> <echo>Done deploying Test Bundle v2.4 to ${rhq.deploy.dir}.</echo> <property name="postinstallTargetExecuted" value="true"/> </target> </project>
27.5.4. Ant Task の使用
deploy.xml
ファイルです。Ant バンドルディストリビューションファイルは、Ant タスクやターゲットを含むより複雑な Ant 設定をサポートします。
27.5.4.1. サポート対象の Ant Task
deploy.xml
ファイル内のターゲットを <antcall> 呼び出し、再度呼び出しを行う <antcall> タスクを再度呼び出す deploy.xml
ファイルに対してループします。これにより無限ループが作成されます。
- 包括的な Ant-Contrib リソースへ 「追加の Ant References」 のリンクは、を参照してください。
27.5.4.2. デフォルト、インストール前、およびインストール後のターゲットの使用
<target name="main" />
27.5.4.3. Ant ターゲットの呼び出し
- Ant レシピ
deploy.xml
では、Ant ターゲットを識別する <rhq:deployment-unit> 要素を追加します。<rhq:deployment-unit name="jar" postinstallTarget="myExampleCall">
- 次に、ターゲットを定義します。
<target name="myExampleCall"> <ant antfile="another.xml" target="doSomething"> <property name="param1" value="111"></property> </ant> </target>
another.xml
ファイルと同じディレクトリーに別のdeploy.xml
ファイルを作成します。このファイルには Ant タスクが含まれます。<project name="another" default="main"> <target name="doSomething"> <echo>inside doSomething. param1=${param1}</echo> </target> </project>
27.5.5. Templatized 設定ファイルの使用
input_field=@@property@@
port=@@listener.port@@
<rhq:input-property name="listener.port" ... />
図27.3 プロビジョニング中のポートトークン
表27.2 JBoss ON によって定義される変数
token | description |
---|---|
rhq.deploy.dir | バンドルがインストールされるディレクトリーの場所。 |
rhq.deploy.id | 特定のバンドルデプロイメントに割り当てられる一意の ID。 |
rhq.deploy.name | バンドルデプロイメントの名前。 |
@@rhq.system.hostname@@
表27.3 システム定義トークン
トークン名 | 取得元... | Java API |
---|---|---|
rhq.system.hostname | Java API | SystemInfo.getHostname() |
rhq.system.os.name | Java API | SystemInfo.getOperatingSystemName() |
rhq.system.os.version | Java API | SystemInfo.getOperatingSystemVersion() |
rhq.system.os.type | Java API | SystemInfo.getOperatingSystemType().toString() |
rhq.system.architecture | Java API | SystemInfo.getSystemArchitecture() |
rhq.system.cpu.count | Java API | SystemInfo.getNumberOfCpus() |
rhq.system.interfaces.java.address | Java API | InetAddress.getByName(SystemInfo.getHostname()).getHostAddress() |
rhq.system.interfaces.network_adapter_name.mac | Java API | NetworkAdapterInfo.getMacAddress() |
rhq.system.interfaces.network_adapter_name.type | Java API | NetworkAdapterInfo.getType() |
rhq.system.interfaces.network_adapter_name.flags | Java API | NetworkAdapterInfo.getAllFlags() |
rhq.system.interfaces.network_adapter_name.address | Java API | NetworkAdapterInfo.getUnicastAddresses().get(0).getHostAddress() |
rhq.system.interfaces.network_adapter_name.multicast.address | Java API | NetworkAdapterInfo.getMulticastAddresses().get(0).getHostAddress() |
rhq.system.sysprop.java.io.tmpdir | Java システムプロパティー | |
rhq.system.sysprop.file.separator | Java システムプロパティー | |
rhq.system.sysprop.line.separator | Java システムプロパティー | |
rhq.system.sysprop.path.separator | Java システムプロパティー | |
rhq.system.sysprop.java.home | Java システムプロパティー | |
rhq.system.sysprop.java.version | Java システムプロパティー | |
rhq.system.sysprop.user.timezone | Java システムプロパティー | |
rhq.system.sysprop.user.region | Java システムプロパティー | |
rhq.system.sysprop.user.country | Java システムプロパティー | |
rhq.system.sysprop.user.language | Java システムプロパティー |
27.5.6. JBoss ON プロパティーおよび Ant プロパティーの処理
27.5.7. Ant Recipes の制限および考慮事項
27.5.7.1. サポートされない Ant Task
- <antcall> (代わりに、<ant> を使用して、Ant ターゲットを含むバンドルの個別の XML ファイルを参照するのに使用します)。
- <macrodef> マクロ定義
27.5.7.2. シンボリックリンク
<untar src="abc.tar.gz" compression="gzip" dest="somedirectory"/>
27.5.7.3. 警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル
- 現行ディレクトリーのファイルもバンドルに含まれます。この場合、バンドルファイルは常に現在のファイルを上書きします。(これに 1 つの例外があります。バンドルのファイルが更新されず、ローカルファイルと同じバージョンであるものの、ローカルファイルが変更されている場合。この場合、ローカルファイルは保持されます。)
- 現在のディレクトリーのファイルはバンドルに存在しません。この場合、バンドルは現在のディレクトリーのファイルを削除します。
コンプライアンス
デプロイするアプリケーションに関する情報はすべて、バンドルレシピの <rhq:deployment-unit> 要素で定義されます。<rhq:deployment-unit> 要素の compliance 属性は、プロビジョニングプロセスが deployment ディレクトリー内の既存のファイルを処理する方法を設定します。
/home/.rhqdeployments/
です/backup
。
<rhq:ignore>
バンドルのデプロイメント後も保持する必要のあるバンドルとは別に、アプリケーションによって使用または作成されるファイルが存在する可能性があります。これには、ログファイル、インスタンス固有の設定ファイル、イメージなどのユーザー提供のコンテンツなどが含まれます。これらのファイルはプロビジョニングプロセス中に無視でき、ファイルを削除するのではなく保存されます。
<rhq:ignore> <rhq:fileset> <include name="logs/*.log"/> </rhq:fileset> </rhq:ignore>
デプロイメントのクリーニング
compliance および <rhq:ignore> はいずれもレシピで設定されます。バンドルが実際にプロビジョニングされる時点で、クリーンなデプロイメント を実行するオプションがあります。clean デプロイメントオプションは、デプロイメントディレクトリーのすべてのものを削除し、レシピの compliance および <rhq:ignore> 設定にかかわらず、バンドルをクリーンディレクトリーにプロビジョニングします。
27.5.8. JBoss ON Ant Recipe 要素のリファレンス
27.5.8.1. rhq:bundle
表27.4 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name | バンドルに指定された名前。 | 必須 |
version | この特定のバンドルのバージョン文字列。バンドルには同じ名前を付けることはできますが、その名前の各バンドルには固有のバージョン文字列を指定する必要があります。これらのバージョン文字列は通常、1.0 またはなどのバージョン管理の OSGi スタイルに従い 1.2.FINALます。 | 必須 |
description | この特定のバンドルバージョンの分かりやすい説明。 | 任意 |
例27.2 rhq:bundle
<rhq:bundle name="example" version="1.0" description="an example bundle">
27.5.8.2. rhq:input-property
表27.5 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name | ユーザー定義プロパティーの名前。レシピ内では、このプロパティーを ${property_name の形式でこの名前で参照でき}ます。 | 必須 |
description | プロパティーの読み取り可能な説明。これは、バンドルのデプロイ時に JBoss ON バンドル UI に表示されるテキスト文字列です。 | 必須 |
type |
ユーザー定義の値で使用できる構文を設定します。以下のオプションは複数あります。
| 必須 |
必須 | 設定にプロパティーが必要であるか、または任意かを設定します。デフォルト値はで false、プロパティーは任意です。この引数を指定しない場合は、プロパティーが任意であることを前提とします。 | 任意 |
defaultValue | バンドルのデプロイ時にユーザーが値を定義しない場合に、使用するプロパティーの値を指定します。 | 任意 |
例27.3 rhq:input-property
<rhq:input-property name="listener.port" description="This is where the product will listen for incoming messages" required="true" defaultValue="8080" type="integer"/>
27.5.8.3. rhq:deployment-unit
表27.6 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name | アプリケーションの名前。 | 必須 |
コンプライアンス |
JBoss ON がバンドルがデプロイされているトップルートディレクトリー(デプロイメントディレクトリー)のすべてのファイルを管理すべきかどうかを設定します。filesAndDirectories の場合、トップデプロイメントディレクトリー(バンドルに含まれ ない ファイル)にある関連ファイルはすべて無視され、今後のバンドル更新のデプロイ時に上書きまたは削除されません。デフォルトは full です。これは、プロビジョニングプロセスがすべてのファイルおよびディレクトリーを管理し、バンドルにないものを削除または上書きすることを意味します。
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。バックアップディレクトリーは resourceID
/home/.rhqdeployments/ です/backup 。
| 任意 |
preinstallTarget | デプロイメントユニットのインストール前に呼び出される Ant ターゲット。 | 任意 |
postinstallTarget | デプロイメントユニットのインストール後に呼び出される Ant ターゲット。 | 任意 |
例27.4 rhq:deployment-unit
<rhq:deployment-unit name="appserver" preinstallTarget="preinstall" postinstallTarget="postinstall">
27.5.8.4. rhq:archive
表27.7 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name |
バンドルに追加するアーカイブファイルのファイル名。
重要
アーカイブファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのアーカイブファイルの場所への 相対パス を含める name 必要があります。
| 必須 |
Exploqued | アーカイブのコンテンツがバンドル宛先ディレクトリー(true)に抽出および保存されるかどうか、または name 属性(false)に指定されるファイルと同じ相対ディレクトリーに保存するかどうかを設定します。ファイルが展開される場合、デプロイメントディレクトリーから展開されます。インストール後のターゲットは、展開後にファイルを移動するために使用できます。 | 任意 |
destinationDir | このアーカイブまたは展開形式の結果がコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。この属性は、コピー先のファイルのディレクトリーを設定します。実際のファイル名は name 属性に設定されます。 | 任意 |
例27.5 rhq:archive
<rhq:archive name="file.zip"> <rhq:replace> <rhq:fileset> <include name="**/*.properties"/> </rhq:fileset> </rhq:replace> </rhq:archive>
27.5.8.5. rhq:url-archive
rhq:archive
点が異なります。
表27.8 要素の属性
attribute | description | Optional または Required |
---|---|---|
url |
アーカイブファイルの場所に URL を指定します。アーカイブがデプロイメントディレクトリーにダウンロードされ、インストールされます。
注記
バンドルが正常にデプロイされるようにするには、このバンドルがデプロイされるすべてのエージェントマシンから URL にアクセスできる必要があります。エージェントが URL にアクセスできない場合、アーカイブをプルダウンできず、これをマシンにデプロイすることができません。
| 必須 |
Exploqued | true の場合、アーカイブのコンテンツは展開され、バンドル宛先ディレクトリーに保存されます。false の場合、zip ファイルは圧縮され、最上位の宛先ディレクトリーに保存されます。
注記
ファイルが展開される場合、デプロイメントディレクトリーから展開されます。インストール後のターゲットは、展開後にファイルを移動するために使用できます。
| 任意 |
destinationDir | このアーカイブまたは展開形式の結果がコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。この属性は、コピー先のファイルのディレクトリーを設定します。実際のファイル名は name 属性に設定されます。 | 任意 |
例27.6 rhq:url-archive
<rhq:url-archive url="http://server.example.com/apps/files/archive.zip"> <rhq:replace> <rhq:fileset> <include name="**/*.properties"/> </rhq:fileset> </rhq:replace> </rhq:url-archive>
27.5.8.6. rhq:file
表27.9 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name |
未編集設定ファイルの名前。
重要
設定ファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイル内のファイルの場所への 相対パス を含める name 必要があります。
| 必須 |
destinationFile |
宛先リソースのファイルの完全なパスおよびファイル名。相対パスは、最終的なデプロイメントディレクトリー(バンドルのデプロイ時に
rhq.deploy.dir パラメーターで定義)への相対パスである必要があります。ディレクトリーとファイル名の両方が指定されていれば、絶対パスを使用することもできます。
注記 destinationDir 属性が使用されると、destinationFile 属性は使用 できません。
| 必須(destinationDir を使用しない場合) |
destinationDir |
このファイルがコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。
この属性は、コピー先のファイルの ディレクトリー を設定します。実際のファイル名は
name 属性に設定されます。
destinationFile 属性が使用されると、destinationDir 属性は使用 できません。
| 必須(destinationFile を使用しない場合) |
replace | ファイルがテンプレート化され、トークンの値を取得するために追加の処理が必要であるかどうかを示します。 | 必須 |
例27.7 rhq:file
<rhq:file name="test-v2.properties" destinationFile="subdir/test.properties" replace="true"/>
destinationDir
destinationFile
属性も使用しない場合、raw ファイルはバンドルディストリビューションの場所として deployment ディレクトリー配下の同じ場所に置かれます。
27.5.8.7. rhq:url-file
rhq:file
、にあるように、トークンの値を持つアプリケーションの設定ファイルを特定して処理するための情報が含まれます。このオプションは、バンドルアーカイブに含めるのではなく、指定の URL からダウンロードされるリモートファイルを指定します。
表27.10 要素の属性
attribute | description | Optional または Required |
---|---|---|
url |
テンプレートファイルに URL を指定します。このファイルは、デプロイメントディレクトリーにダウンロードされ、インストールされます。
注記
バンドルが正常にデプロイされるようにするには、このバンドルがデプロイされるすべてのエージェントマシンから URL にアクセスできる必要があります。エージェントが URL にアクセスできない場合、アーカイブをプルダウンできず、これをマシンにデプロイすることができません。
| 必須 |
destinationFile |
宛先リソースのファイルの完全なパスおよびファイル名。相対パスは、最終的なデプロイメントディレクトリー(バンドルのデプロイ時に
rhq.deploy.dir パラメーターで定義)への相対パスである必要があります。ディレクトリーとファイル名の両方が指定されていれば、絶対パスを使用することもできます。
注記 destinationDir 属性が使用されると、destinationFile 属性は使用 できません。
この属性には、パス名とファイル名の両方を指定する必要があります。
| 必須(destinationDir を使用しない場合) |
destinationDir |
このファイルがコピーされるディレクトリー。これが相対パスである場合、バンドルのデプロイ時にユーザーが指定するデプロイメントディレクトリーと相対的です。これが絶対パスである場合、ファイルがコピーされるファイルシステムの場所になります。
この属性は、コピー先のファイルの ディレクトリー を設定します。実際のファイル名は
name 属性に設定されます。
destinationFile 属性が使用されると、destinationDir 属性は使用 できません。
| 必須(destinationFile を使用しない場合) |
replace | ファイルがテンプレート化され、トークンの値を取得するために追加の処理が必要であるかどうかを示します。 | 必須 |
例27.8 rhq:url-file
<rhq:url-file url="http://server.example.com/apps/files/test.conf" destinationFile="subdir/test.properties" replace="true"/>
destinationDir
destinationFile
属性も使用しない場合、raw ファイルはバンドルディストリビューションの場所として deployment ディレクトリー配下の同じ場所に置かれます。
27.5.8.8. rhq:property
表27.11 要素の属性
attribute | description | Optional または Required |
---|---|---|
relativeToDeployDir
|
file 属性も使用され、相対パスである場合にのみ該当します。
デフォルトは false です。
true の場合、ファイルはバンドルのデプロイメントが実行される作業ディレクトリーの代わりにバンドルのデプロイディレクトリーに対して解決されます。
|
任意
|
27.5.8.9. rhq:audit
rhq:audit
設定は追加の処理手順とその結果に関する情報をサーバーに送信します。
表27.12 要素の属性
attribute | description | Optional または Required |
---|---|---|
status | 処理のステータス。使用できる値は SUCCESS、WARN、および FAILURE です。デフォルトは SUCCESS です。 | 任意 |
action | 処理ステップの名前。 | 必須 |
info | アクションのターゲット名や影響を受けるファイル名など、アクションの実行内容の短い概要。 | 任意 |
message | アクションに関する追加情報を提供する簡単なテキスト文字列。 | 任意 |
例27.9 rhq:audit
<rhq:audit status="SUCCESS" action="Preinstall Notice" info="Preinstalling to ${rhq.deploy.dir}" message="Another optional message"> Some additional, optional details regarding the deployment of ${rhq.deploy.dir} </rhq:audit>
27.5.8.10. rhq:replace
例27.10 例
<rhq:archive name="file.zip"> <rhq:replace> <rhq:fileset> <include name="**/*.properties"/> </rhq:fileset> </rhq:replace> </rhq:archive>
27.5.8.11. rhq:ignore
/opt/myapp
、バンドル B にデプロイされます /opt/myapp/webapp1
)。
例27.11 rhq:ignore
<rhq:ignore> <rhq:fileset> <include name="logs/*.log"/> </rhq:fileset> </rhq:ignore>
27.5.8.12. rhq:fileset
表27.13 要素の属性
子要素 | description |
---|---|
<include name=filename /> | ファイルのファイル名。この場合 <rhq:replace>、これはアーカイブ(JAR または ZIP)ファイル内のファイルで、テンプレート化され、トークンの値が含まれる必要があります。これは <rhq:ignore>、アプリケーションのデプロイメントディレクトリーにあるファイルで、バンドルのアップグレード時に無視され、保持されるはずです。 |
例27.12 rhq:fileset
<rhq:replace> <rhq:fileset> <include name="**/*.properties"/> </rhq:fileset> </rhq:replace>
27.5.8.13. rhq:system-service
表27.14 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name | スクリプトの名前。 | 必須 |
scriptFile | スクリプトのファイル名スクリプトファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのファイルの場所への 相対パス を含める scriptFile 必要があります。 | 必須 |
configFile | スクリプトによって使用される設定またはプロパティーファイルの名前。設定ファイルがバンドルディストリビューションの ZIP ファイル内の Ant レシピファイルでパッケージ化されている場合は、ZIP ファイルのファイルの場所への 相対パス を含める configFile 必要があります。 | 任意 |
overwriteScript | 既存の init ファイルを上書きしてアプリケーションをシステムサービスとして設定するかどうかを設定します。 | 任意 |
startLevels | アプリケーションサービスの実行レベルを設定します。 | 任意 |
startPriority | アプリケーションサービスの起動順序または優先度を設定します。 | 任意 |
stopPriority | アプリケーションサービスの停止順序または優先度を設定します。 | 任意 |
例27.13 rhq:system-service
<rhq:system-service name="example-bundle-init" scriptFile="example-init-script" configFile="example-init-config" overwriteScript="true" startLevels="3,4,5" startPriority="80" stopPriority="20"/>
27.5.8.14. rhq:handover
表27.15 要素の属性
attribute | description | Optional または Required |
---|---|---|
action | ターゲットリソースコンポーネントが実行するアクションの名前。 | 必須 |
FailOnError | ターゲットリソースコンポーネントが失敗を報告すると ANT レシピビルドが失敗するかどうか。true または false。デフォルトは true です。 | 任意 |
- <rhq:file>
- <rhq:url-file>
- <rhq:archive>
- <rhq:url-archive>
例27.14 rhq:handover
<rhq:file name="prepareDatasource.cli" replace="true"> <rhq:handover action="execute-script" failonerror="false"/> </rhq:file> <rhq:archive name="website.war"> <rhq:handover action="deployment"> <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/> <rhq:handover-param name="serverGroup" value="${server.group}"/> </rhq:handover> </rhq:archive>
prepareDatasource.cli
ファイルの内容は、website.war
アーカイブコンテンツの前に常にターゲットリソースコンポーネントに渡されます。
27.5.8.15. rhq:handover-param
表27.16 要素の属性
attribute | description | Optional または Required |
---|---|---|
Name | パラメーターの名前 | 必須 |
値 | 値の名前。 | 必須 |
rhq:handover-param
子タグを持つことができます。
例27.15 rhq:handover-param
<rhq:file name="prepareDatasource.cli" replace="true"> <rhq:handover action="execute-script" failonerror="false"/> </rhq:file> <rhq:archive name="website.war"> <rhq:handover action="deployment"> <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/> <rhq:handover-param name="serverGroup" value="${server.group}"/> </rhq:handover> </rhq:archive>
27.6. バンドルパッケージのテスト
27.6.1. Bundle Deployer Tool のインストール
- トップメニューの Administration タブをクリックします。
- 左側のメニューテーブル Downloads でを選択します。
- Bundle Deployer Download セクションまでスクロールし、パッケージのダウンロードリンクをクリックします。
- などのバンドルツールをインストールするディレクトリーに
.zip
ファイルを保存し/opt/
ます。 - パッケージを展開します。
cd /opt/ unzip rhq-bundle-deployer-version.zip
27.6.2. Bundle Deployer ツールの使用
- バンドルディストリビューションパッケージを展開して確認します(または、アプリケーションファイルが含まれる未展開ディレクトリーをコピーします)。例:
mkdir /tmp/test-bundle cd /tmp/test-bundle unzip MyBundle.zip
deploy.xml
Ant レシピファイルがあるバンドルディストリビューションの最上位ディレクトリーを開きます。- PATH にバンドルデプロイヤーツールの場所を設定します。
PATH="/opt/rhq-bundle-deployer-3.0.0/bin:$PATH"
- bundle deploy ツールを実行し、
-D
input_properties 形式を使用して値を定義済みファイルのユーザー定義トークンに渡します。例:rhq-ant -Drhq.deploy.dir=/opt/exampleApp -Dlistener.port=7081
これにより、アプリケーションにインストールされ/opt/exampleApp
、ポート値の 7081 が設定されます。注記必要に応じて、rhq.deploy.id
属性を使用してデプロイメントの識別子を設定します。デフォルトは 0 で、新規デプロイメントを意味します。バンドルが UI にデプロイされると、サーバーは固有の ID をデプロイメントに割り当てます。新しいデプロイメントでrhq.deploy.id
属性を使用すると、サーバーの ID 割り当てがシミュレートされます。以前のデプロイメントがある場合には、rhq.deploy.id
属性を使用してバンドルのアップグレードパフォーマンスをテストすることができます。アップグレードを実行するには、新しい一意の ID 番号が必要です。
27.7. Provisioning Bundles
27.7.1. バンドルグループの管理
27.7.1.1. バンドルグループの作成
- トップメニューの Bundles タブをクリックします。
- 下部の Bundle Groups エリアで、New ボタンをクリックします。
- グループの名前と説明を入力します。
- グループメンバーを選択します。バンドルがアップロードされている場合は、作成時にそのバンドルをグループに追加できます。バンドルは、作成、更新、またはグループの編集時にバンドルグループに追加できます。
- Save ボタンをクリックします。
27.7.1.2. バンドルグループへのバンドルの割り当て
図27.4 バンドル階層のバンドルグループおよび未割り当てバンドル
- トップメニューの Bundles タブをクリックします。
- 下部の Bundle Groups エリアで、編集するバンドルグループの名前をクリックします。
- グループメンバーを選択して、グループから追加または削除します。ボックスでバンドルを選択すると、対応する矢印がアクティブになり、他のボックスに移動します。
- Save ボタンをクリックします。
27.7.2. バンドルの JBoss ON へのアップロード
- トップメニューで、Bundles タブをクリックします。
- Bundles セクション下部で、New ボタンをクリックします。
- ディストリビューションパッケージまたはレシピファイルをアップロードします。JBoss ON サーバーでバンドルディストリビューションを利用する方法は 3 つあります。
- URL FTP サイトや SVN または GIT リポジトリーなどの URL を参照し、利用可能な完全なバンドルディストリビューションファイルがあります。リポジトリーに認証が必要な場合は、サーバーがサイトに対して認証できるように、ユーザーアカウントのユーザー名とパスワードを指定できます。注記SVN または GIT リポジトリーを使用すると、ビルドシステムからパッケージを直接プルできます。
- Upload ローカルシステムから JBoss ON サーバーに単一のバンドルディストリビューションファイルをアップロードします(すべての関連ファイルを含む)。
- Recipe レシピファイルのみをアップロードしてから、バンドルに必要な追加のファイルは別々にアップロードされます。このオプションには、サーバーに送信される前にアップロードしたレシピを編集できる編集フィールドが含まれます。
- バンドルを割り当てる左側のボックスでグループを選択し、矢印をクリックして Assigned ボックスに移動します。バンドルグループはアクセス制御に必要です。グループ割り当てがないと、バンドルの表示や(グローバルビューバンドルパーミッションがない場合は)バンドルの表示やバンドルのデプロイができなくなります。
- 以前アップロードされなかった関連ファイルをアップロードします。URL およびについては、通常 Upload、すべてのファイルが 1 つのファイルにアップロードされるため、この画面では何もする必要はありません。Recipe オプションでは、レシピに記載されているすべてのファイルを、このステップで手動でアップロードする必要があります。
- 最後の画面には、新しいバンドルのすべての情報が表示されます。Finish をクリックし、新しいバンドルを保存します。
27.7.3. リソースへのバンドルのデプロイ
- トップメニューで、Bundles タブをクリックします。
- ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。インポートし、一覧にあるバンドルの名前をクリックし、バンドルページの上部にあるデプロイボタンをクリックします。
- 左側の一覧からデプロイするバンドルを選択し、矢印を使用して右側のボックスに移動します。
- バンドルを選択したら、宛先情報を定義します。宛先は、バンドルがデプロイされているリソースと、デプロイされるディレクトリーの組み合わせです。各宛先は各バンドルに対して一意に定義されます。宛先を定義するには、まず Resource ドロップダウンメニューからリソースグループを選択します。リソースグループはバンドルがデプロイされるリソースのタイプを識別し、リソースタイプは他のデプロイメントパラメーターを定義します。グループを選択すると、ベースの場所が 定義されます。プラットフォームの場合は、root ディレクトリーです。JBoss AS インスタンスでは、インストールディレクトリーになります。カスタムリソースの場合、ベースの場所はプラグイン記述子に定義されます。注記互換性のあるグループを作成していない場合や、このバンドルデプロイメント専用の新規グループを作成する場合は、+ アイコンをクリックしてグループを作成します。次に、プロビジョニングプロセスで続行します。バンドルをデプロイする実際のデプロイメントディレクトリーを設定します。このディレクトリーは、プラグイン定義のベースロケーションへの相対パスです。
- デプロイするバンドルのバージョンを選択します。利用可能なバンドルのバージョンが複数ある場合は、これらのバージョンのいずれかを選択できます。また、最新バージョンまたは現在デプロイされたバージョンをデプロイする簡単なオプションもあります。
- ユーザー定義のプロパティーがある場合は、次のページのフィールドに入力されます。ユーザー定義のプロパティーは、トークンを使用してバンドルレシピで設定されます。
- 特定のデプロイメントインスタンスに関する情報を入力します。このチェックボックスは、既存のデプロイメントディレクトリーのコンテンツを上書きするかどうか、または既存のファイルを保持するかどうかについてのオプションを設定します。
- 最後の画面には、パッケージのデプロイの進捗が表示されます。デプロイメント Finish を完了するには、をクリックします。
27.7.4. バンドルデプロイメント履歴の表示
図27.5 バンドル、バージョン、および宛先
図27.6 バージョンのデプロイメント情報
図27.7 宛先のデプロイメント履歴
27.7.5. デプロイ済みバンドルの元に戻す
- トップメニューで、Bundles タブをクリックします。
- 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
- 左側のナビゲーションから宛先を選択します。
- 宛先のメインウィンドウで、Revert ボタンをクリックします。
- 次のページには、現在のデプロイメントの概要と、以前のデプロイメントの概要が表示され、元に戻されます。
- revert アクションに注記を追加します。必要に応じて、チェックボックスを選択してデプロイメントディレクトリーを消去し、以前のバージョンを新規にインストールします。
- 最終画面 Finish をクリックしてロールバックを完了します。
27.7.6. バンドルのクリーニング宛先へのデプロイ
- レシピの設定(「警告: 管理対象(ターゲット)のディレクトリーおよび上書き/保存ファイル」)に従って、適切なアップグレードで既存のファイルおよびディレクトリーを保存します。
- 既存のファイルを完全に上書きし、空のディレクトリーにバンドルをデプロイします。
27.7.7. リソースからのバンドルの削除
deploy/
のアプリケーションやファイルも削除されます。パージ後には、ライブデプロイメントはなく、元に戻すものはありません。
- トップメニューで、Bundles タブをクリックします。
- 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
- 左側のナビゲーションから宛先を選択します。
- 宛先のメインウィンドウで、Purge ボタンをクリックします。
- プロンプトが表示されたら、バンドルされたアプリケーションおよび設定をターゲットリソースから削除する必要があることを確認します。
27.7.8. Ant Bundle のアップグレード
- 新しいファイルのハッシュコードが元のファイルとは異なり、ローカルの変更がない場合は、JBoss ON は既存ファイルに新しいファイルをインストールします。
- 新規ファイルのハッシュコードが元のファイルとは異なり、ローカルの変更がある場合 は、JBoss ON は元のファイルをバックアップし、新しいファイルをインストールします。
- 新規ファイルのハッシュコードと元のファイルが同じで、元のファイルに ローカル な変更がある場合は、プロビジョニングプロセスにより元のファイルが保存されます。
- 以前のバンドルにファイルがない場合、新しいバンドルにファイルがある場合には、新しいファイルが使用され、手動で追加したファイルはバックアップされます。
backup/
ディレクトリー内のディレクトリーに保存されます。元のファイルがアプリケーションのディレクトリーの外部にある場合(例: 相対的な場所ではなく絶対的な場所に基づいて保存されている場合)、これはデプロイメントの宛先 ext-backup/
ディレクトリー内のディレクトリーに保存されます。
27.7.9. JBoss ON Server からのバンドルの削除
- トップメニューで、Bundles タブをクリックします。
- 左側のナビゲーションウィンドウでバンドルノードを展開し、その下の Destinations フォルダーを開きます。
- 左側のナビゲーションから宛先を選択します。
- 宛先のメインウィンドウで、Delete ボタンをクリックします。
- プロンプトが表示されたら、バンドルを削除することを確認します。
27.8. 拡張例: プロビジョニングプロセスでのバンドルグループおよびアクセス制御の使用
27.8.1. global v.作成およびデプロイを行うためのグループパーミッション
例27.16 User Deploys Bundles anywhere
Role R1 <--- User U | v View Bundles Create Bundles Deploy Bundles
例27.17 Deploy Bundles to a Specific Resource Group: Single Role
Resource Group X ---> Role R <--- User U ^ | View Bundles Deploy Bundles To Group
例27.18 Deploy Bundles to a specific Resource Group: Two Roles
Resource Group X ---> Role R1 <--- User U --> Role R2 ^ ^ | | Deploy Bundles To Group View Bundles
27.8.2. Permissions and the Application Development Workflow
例27.19 特定のバンドルグループでのバンドルの作成
Bundle Group A ---> Role R1 <--- User U ---> Role R2 ^ ^ | | Create Bundles In Group View Bundles
例27.20 複数ユーザーが各他のユーザーのバンドルを更新する
Bundle Group A | v Role R1 <--- User U1, User U2, User U3 ^ | Create Bundles In Group Delete Bundles From Group
例27.21 Team Lead Creates Bundles - Team Members Deploy Bundles
Bundle Group A Bundle Group A | | v v Role R1 <--- User TeamLeader Resource Group X ---> Role R2 <--- Users TeamMember1, TeamMember2 ^ ^ | | Create Bundles In Group Deploy Bundles To Group
第28章 リソースレベルのコンテンツ更新の管理
28.1. コンテンツ
28.1.1. コンテンツの概要: パッケージ
28.1.2. Content comes From: Providers and Repositories
28.1.3. パッケージバージョンと履歴
META-INF/MANIFEST.MF
ファイル内の仕様バージョンおよび実装バージョン(EAR および WAR 用)を基に番号を取得します。
SPEC(IMPLEMENTATION)[sha256=abcd1234]
図28.1 パッケージバージョン番号
META-INF/MANIFEST.MF
ファイルの場合:
Manifest-Version: 1.0 Created-By: Apache Maven Specification-Title: My Example App Specification-Version: 1.0.0-GA Specification-Vendor: Example, Corp. Implementation-Title: My Example App Implementation-Version: 1.x Implementation-Vendor-Id: org.example Implementation-Vendor: Example, Corp. ...
1.0.0-GA(1.x)[sha256=abcd1234]
META-INF/MANIFEST.MF
ファイルに仕様バージョンまたは実装バージョンのいずれかが含まれていない場合には、その 1 つのバージョンのみが使用されます。たとえば、実装バージョンのみが指定される場合:
(1.x)[sha256=abcd1234]
[sha256=abcd1234]
MANIFEST.MF
ファイルに追加されます。これにより、エージェントは検出スキャン中にファイルを確認して、パッケージのバージョンを迅速に検証できます。
Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...
META-INF/MANIFEST.MF
ファイルを編集するため、デプロイされたコンテンツはアップロードされたコンテンツパッケージと全く同じではありません。
28.1.4. リポジトリーおよびパッケージの認可
- 所有者 は、リポジトリーへの書き込みアクセスを設定します。特定のユーザーに属するリポジトリーを割り当てます。ユーザーの指定がない場合は、manage リポジトリーパーミッションを持つユーザーのみが、これらのリポジトリーにアクセスする権限を持ちます。
- リポジトリーへの読み取り (download)アクセス。これは、リポジトリーの管理権限を持つ所有者とユーザーのみが、リポジトリーを表示できるかどうかを設定します。所有者に関係なく、パブリックリポジトリーはすべてのユーザーが参照できます。
図28.2 リポジトリーの所有者とアクセス設定
28.1.5. コンテンツの領域に関する考慮事項
28.2. コンテンツソースの作成
表28.1 コンテンツソースのタイプ
ソースタイプ | description | 認証情報が必要ですか? |
---|---|---|
リモート URL | リモート URL からダウンロードします。これは、FTP などの複数の異なるプロトコルを使用できます。 | いいえ |
HTTP |
Remote URL コンテンツソースと同様に、ネットワーク接続をソースに接続します。これは特に HTTP プロトコルを使用します。
HTTP コンテンツソースは HTTP プロキシーに接続することもできます。
HTTPS はサポートされません。
|
オプションで、認証情報が指定の HTTP サイトまたはプロキシーサーバーにログインできるようになります。 [a]
|
JBoss Customer Portal Feed(RSS) | リモート URL コンテンツソースと同様に、JBoss の累積パッチのカスタマーポータルの RSS フィードで特別に機能します。 |
◯ [a]
|
ローカルディスク | (ローカルシステムまたは NFS マウント上にある)単一のローカルディレクトリーに接続し、ダウンロードする指定されたタイプおよびアーキテクチャーのパッケージを探します。 | いいえ |
[a]
コンテンツソース設定のパスワードは、JBoss ON データベースで難読化されます。
|
28.2.1. コンテンツソースの作成(一般)
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Content Sources 項目を選択します。
- 現在のコンテンツソースの一覧の下にある CREATE NEW ボタンをクリックします。
- ソースからコンテンツの配信方法を定義するコンテンツソースタイプを選択します。では、異なるコンテンツソースを 「コンテンツソースの作成」 記述します。
- コンテンツソースタイプを選択すると、フォームが自動的に開き、リソースの基本的な詳細および設定が入力されます。これらの基本詳細は JBoss ON サーバーのコンテンツソースを特定し、各コンテンツソースタイプについて同じですが、コンテンツソースタイプに固有の設定です。
- コンテンツソースプロバイダーの名前とオプションの説明を指定します。
- スケジュールは、JBoss ON データベースのコンテンツがコンテンツソースによって更新される頻度を設定します。これは標準の Quartz Cron Syntax を使用します。
- lazy ロード設定は、インストール時(Yes)またはすべてのパッケージをすぐにダウンロードする必要がある場合にのみパッケージをダウンロードするかどうかを設定します。
- ダウンロードモードは、コンテンツの JBoss ON の保存方法を設定します。デフォルトはで DATABASE、すべてのパッケージを JBoss ON データベースインスタンスに保存します。その他のオプションは、パッケージをネットワークファイルシステムに保存するか、パッケージを全く保存しないことです。
- コンテンツソースの他の設定情報を入力します。必要な情報は、コンテンツソースのタイプによって異なります。これには、URL、ディレクトリーパスなどの何らかの接続情報や、ユーザー名とパスワードなどの認証情報が必要になります。注記コンテンツソースに保存されたパスワードは JBoss ON データベースで難読化されます。
28.2.2. コンテンツソースの作成(ローカルディスク)
図28.3 ローカルディスク構造
/export/myContentSource/test
とというディレクトリーは使用しないでください /export/myContentSource/subdir/test
。
- のように、コンテンツソースを設定し 「コンテンツソースの作成(一般)」 ます。注記同期するサブディレクトリーがすでに存在する場合、コンテンツソースの設定では、サブディレクトリー名に基づいてローカルディスクプロバイダーに関連付けるリポジトリーが要求されます。
- ルートディレクトリーパスを入力します。
- JBoss ON サーバーがコンテンツストレージにプルするパッケージを特定するために使用するコンテンツパッケージ情報を入力します。
- にあるようにリポジトリーを作成し 「リポジトリーの作成」、使用するサブディレクトリーの名前を記入します。重要各サブディレクトリー名は、ルートディレクトリーツリーの階層により一意である必要があります。たとえば、
/export/myContentSource/test
とというディレクトリーは使用しないでください/export/myContentSource/subdir/test
。同じ名前のディレクトリーが 2 つあると、パッケージの同期動作が予測できない場合があります。 - ローカルシステムにサブディレクトリーを作成し、JBoss ON コンテンツシステムに追加する必要のあるパッケージでコピーします。
28.3. リポジトリーの管理
28.3.1. リポジトリーの作成
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Repositories 項目を選択します。
- 現在のリポジトリーの一覧の下にある CREATE NEW ボタンをクリックします。
- 名前と説明を入力します。また、リポジトリーの所有者およびパブリックまたはプライベートのどちらの所有者を設定して、リポジトリーの認可制限を設定します。所有者を設定できるのは、リポジトリー権限を持つユーザーのみです。リポジトリーのパーミッションのないユーザーが作成するすべてのリポジトリーは、そのユーザーに自動的に適用されます。
- をクリックし Saveます。
- Repositories ページの新しいリポジトリーの名前をクリックします。
- オプション。デフォルトの同期スケジュールを変更するには、Edit ボタンをクリックし、その Sync Schedule フィールドに cron 形式の新しいスケジュールを入力します。
- にあるように、コンテンツソースをリポジトリーに提供するコンテンツを追加し 「コンテンツソースのリポジトリーへの関連付け」 ます。複数のコンテンツソースは、リポジトリーにコンテンツを提供できます。
- にあるように、リソースをリポジトリーに関連付け 「リソースのリポジトリーへの関連付け」 ます。リソースは、リポジトリーと関連付けられている場合に限り、リポジトリーからパッケージを受信できます。注記特定のリソースまたはタイプのリソースを検索し、複数のリソースを一度にサブスクライブできます。
28.3.2. コンテンツソースのリポジトリーへのリンク
28.3.2.1. コンテンツソースのリポジトリーへの関連付け
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Repositories 項目を選択します。
- Repositories ページで、リストにあるリポジトリーの名前をクリックします。
- リポジトリーの詳細ページの Content Sources セクションで、Associate ボタンをクリックして既存のコンテンツソースをリポジトリーに追加します。
- リポジトリーに関連付けるコンテンツソースの横にあるチェックボックスを選択します。
- ASSOCIATE SELECTED ボタンをクリックします。
28.3.2.2. コンテンツソースのリポジトリーへのインポート
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Repositories 項目を選択します。
- Repositories ページで、IMPORT ボタンをクリックします。
- インポートするコンテンツソースの名前でラジオボタンを選択します。
- コンテンツソースを選択すると、そのコンテンツソースで利用可能なリポジトリーの一覧が自動的に開きます。この Available repositories.... エリアで、コンテンツソースに関連付ける各リポジトリーの名前でチェックボックスを選択します。
- IMPORT SELECTED ボタンをクリックします。
28.3.3. リソースのリポジトリーへの関連付け
28.3.3.1. リポジトリーへのリソースの追加
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Repositories 項目を選択します。
- Repositories ページで、編集するリポジトリーの名前をクリックします。
- Resources セクションで、SUBSCRIBE ボタンをクリックしてリソースをリポジトリーに追加します。
- リポジトリーに関連付けるリソースの横にあるチェックボックスを選択します。名前またはタイプ別にリソースの一覧を絞り込むことができます。
- SUBSCRIBE SELECTED ボタンをクリックします。
28.3.3.2. リソースのリポジトリーの管理
- 左側の Resources メニューテーブルでリソースタイプを選択し、そのリソースの閲覧または検索を行います。
- リソースの Content タブをクリックします。
- Subscriptions サブタブを開きます。
- この Available Repositories セクションには、リソースがサブスクライブしていないリポジトリーの一覧があります。すべてのリポジトリーのチェックボックスをクリックして、リソースをサブスクライブします。
- をクリックし ADD SUBSCRIPTIONSます。
28.4. パッケージのアップロード
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Repositories 項目を選択します。
- Repositories ページで、リストにあるリポジトリーの名前をクリックします。
- ページの下部までスクロールし、Upload Packages セクションまでスクロールします。
- Upload File ボタンをクリックして、パッケージをアップロードします。
- ポップアップウィンドウで、Add ボタンをクリックしてパッケージを参照し、Upload ボタンをクリックします。
- パッケージに関する情報には、名前やデフォルトの UI バージョン番号など、自動的に入力されます。パッケージタイプ、アーキテクチャー、およびその他の必要な情報を設定します。バージョン番号が設定されている場合、この値は UI に表示されます。そうでない場合は、の
MANIFEST.MF
(EAR および WAR の場合)の仕様バージョンおよび実装バージョン、またはパッケージ自体について計算された SHA-256 値を基にして、バージョン番号が算出されます。内部では、パッケージは SHA 値で識別されます。SPEC(IMPLEMENTATION)[sha256=abcd1234]
注記EAR および WAR の展開形式のコンテンツについては、計算された SHA-256 バージョン番号がMANIFEST.MF
ファイルに書き込まれます。 - CREATE PACKAGE ボタンをクリックして、パッケージをリポジトリーに追加します。
28.5. コンテンツソースまたはリポジトリーの同期
28.5.1. スケジューリングの同期
* * * * * [sync-command] - - - - - | | | | | | | | | +----- Day of Week (0=Sunday ... 6=Saturday) | | | +------- Month (1 - 12) | | +--------- Date (1 - 31) | +----------- Hour (0 - 23) +------------- Minute (0 - 59)
0 3 * * 2,5
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Content Sources またはRepositories 項目を選択します。
- 編集する項目の名前をクリックします。
- Sync Schedule フィールドの cron スケジュールをリセットします。
- をクリックし Saveます。
28.5.2. コンテンツソースまたはリソースの手動同期
- トップメニューで、Administration タブをクリックします。
- 左側の Content メニューテーブルで、Content Sources または Repositories 項目を選択します。
- 編集する項目の名前をクリックします。
- Synchronize ボタンをクリックします。同期試行はすべて、操作の結果とともに画面下部に表示されます。
28.6. リソースのコンテンツバージョンの追跡
図28.4 リソースのパッケージ履歴
パート V. JBoss リソースの管理
第29章 JBoss ON による JBoss リソースの管理方法
29.1. JBoss ON の JBoss ソフトウェアの使用方法
- ソフトウェア更新およびパッチの管理(「パッチ RSS フィードバックからの JBoss パッチの適用」)
- デプロイされた Web アプリケーション(「アプリケーションのデプロイ」)
29.2. 本ガイドの「対象」
- EAR および WAR およびその他の Web アプリケーションのコンテンツ管理
- JBoss サーバークラスターの管理
- JBoss サーバードメインの管理
- JBoss インスタンスの監視
29.3. JBoss プラグインパックのインストール
第30章 一般的なタスク
30.1. 検出用のカスタム JVM の設定
30.1.1. Discovery に必要な JVM 設定
- Sun JMX リモーティングが有効になり、コマンドラインでポートシステムプロパティーが指定されます。
-Dcom.sun.management.jmxremote.port=12345 com.xyz.MyAppMain
- Sun/Oracle 互換の Java プロセスには、
com.sun.tools.attach
API およびリソースキーはコマンドラインでシステムプロパティーとして指定されます。-Dorg.rhq.resourceKey=KEY com.xyz.MyAppMain
30.1.2. 検出からの Java プロセスの除外
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.jmxplugin.process-filters=org.rhq.enterprise.agent.AgentMain,org.jboss.Main,catalina.startup.Bootstrap"
- エージェントの設定ファイルを開きます。
[jbosson-agent@server ~]$ vim agentRoot/rhq-agent/conf/agent-configuration.xml
- RHQ_AGENT_ADDITIONAL_JAVA_OPTS リンクで、除外する文字列を rhq.jmxplugin.process-filters オプションに追加します。これは、指定のプロセスのコマンドラインにあるクラス名またはその他の識別文字列になります。例:
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.jmxplugin.process-filters=org.rhq.enterprise.agent.AgentMain,org.jboss.Main,catalina.startup.Bootstrap
,com.abc.OtherAppMain
"rhq.jmxplugin.process-filters 値は文字列のコンマ区切りリストです。 - --config オプションを指定してエージェントを再起動して、新しい設定を読み込む。
[jbosson-agent@server ~]$ agentRoot/rhq-agent/bin/rhq-agent.sh --config
30.1.3. JVM リソースの手動インポート
- トップメニューの Inventory タブをクリックします。
- platform リソースを選択します。
- プラットフォームの Inventory タブをクリックします。
- Inventory タブ下部の Import ボタンをクリックして JMX サーバーリソースタイプを選択します。
- JVM のタイプを選択し、選択した JVM のタイプに応じて、すべての接続プロパティーを正しく設定します。
- JVM の接続情報を入力します。これは JVM タイプによって異なりますが、URL やポートなどのオプション、クライアントライブラリーのディレクトリーパス、クラス用のディレクトリーパス、ログイン認証情報が含まれます。
- をクリック Finish し、インスタンスのインポートを行います。
30.2. セキュアな JMX サーバーに接続するためのエージェントの有効化
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=5222 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jmxremote.access
jmx-console-users.properties ファイルを編集します。
通常、エージェントは JbossASInstallDir/server/default/conf/props/
ディレクトリーの jmx-console-*.properties
ファイルから接続認証情報を 読み取ります。
jmx-console-users.properties
ファイルにエントリーがないため、エージェントが認証情報を取得する方法がありません。
- 編集する
jmx-console-*.properties
ファイルを開きます。例:[root@server ~]# vim JbossASInstallDir/server/default/conf/props/jmx-console-users.properties
- admin ユーザーの行をアンコメントまたは追加します。
admin=admin
リモートアクセスファイルを使用するように接続設定の編集
デフォルトでは、エージェントはアクセス jmx-console-*.properties
ファイルではなくユーザー名にファイルを使用します。JMX サーバーのコマンドラインで指定したリモートエンドポイントを経由して、エージェントがアクセスファイルを使用するようにリソースの接続設定を変更することができます。
- トップメニューの Inventory タブをクリックします。
- 、Servers Inventory、または JBoss EAP インスタンスを開き、その子に移動し、JMX サーバーインスタンスを見つけます。
- JMX サーバーのエントリーページでタブを開き、Connection Settings サブ Inventory タブを選択します。
- JMX リモートアクセスファイルに設定するユーザー名とパスワードを入力します。
- Save ボタンをクリックします。
親リソースから接続するための接続設定の編集
JBoss ON は親リソースに接続し、それを使用してリモーティングエンドポイント経由で接続するのではなく、JMX サーバーに接続できます。親は内部認証を使用して子リソースに接続できるため、ユーザークレデンシャルを使用する必要はありません。
- トップメニューの Inventory タブをクリックします。
- 、Servers Inventory、または JBoss EAP インスタンスを開き、その子に移動し、JMX サーバーインスタンスを見つけます。
- JMX サーバーのエントリーページでタブを開き、Connection Settings サブ Inventory タブを選択します。
- プロパティー 以外 のすべての接続プロパティーの設定を解除し Type ます。
- Type プロパティーで、Parent 値を選択します。
- Save ボタンをクリックします。
第31章 JBoss EAP 5 の管理
31.1. JBoss EAP/AS 5 サーバーの検出
31.1.1. JBoss AS/EAP 5 JVM の検出および管理
run.conf
ファイルを開きます。たとえば、Red Hat Enterprise Linux の場合は以下のようになります。[root@server ~]# vim jbossInstallDir/bin/run.conf
- プラットフォーム MBean サーバーを使用するための
JAVA_OPTS
設定を追加します。Red Hat Enterprise Linux の場合:JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
Windows の場合:set JAVA_OPTS=%JAVA_OPTS% -Djboss.platform.mbeanserver
- JBoss Enterprise Application Platform を再起動します。
31.1.2. JMX およびプロファイルサービスへのリモートアクセスの有効化
- JBoss Naming Protocol サーバー(JNP)がデプロイされていることを確認します。(デフォルトではデプロイされます。)
jboss-service.xml
ファイルを開きます。[root@server ~]# vim jbossInstallDir/server/config/conf/jboss-service.xml
次に、JNP コネクターを有効にする行があることを確認します。<mbean code="org.jboss.naming.NamingService"> ... </mbean>
- 必須ではありませんが、JNP サービスの認証を有効にすることが推奨されます。(これはデフォルトで有効になっています。)
jmx-invoker-service.xml
ファイルを開きます。[root@server ~]# vim jbossInstallDir/server/config/deploy/jmx-invoker-service.xml
- JMX コネクター認証の行を追加します。
<interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
- 管理ユーザーが JMX ユーザーのプロパティーファイルに一覧表示されていることを確認します。新しい JBoss EAP リソースが検出されると、エージェントはこのファイルから JMX ユーザー名とパスワードを読み取り、検出された JBoss EAP リソースの接続設定に保存します。これらの設定は、EAP サーバーの JNP サービスに接続するために使用されます。
[root@server ~]# vim jbossInstallDir/server/config/conf/props/jmx-console-users.properties
- ユーザー情報をアンコメントまたは追加します。これは、単純なキー/値のペア username=password です。例:
admin=admin
- JBoss Enterprise Application Platform を再起動します。
31.1.3. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定
31.1.3.1. スクリプト検出と設定の開始
- 検出プロセスでは、EAP サーバーの起動に使用された開始スクリプト(カスタム起動スクリプトか、またはカスタム起動スクリプト)が特定
run.sh|bat
または試行されます。 - Discovery は、開始スクリプトが機能するために必要な
run.conf
ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。注記検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値になりません。開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のためにrun.conf
ファイルに移されます。 - 検出は、開始スクリプト自体に渡される引数を検出しようとします。
-XX:PermSize=256M
)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
31.1.3.2. スクリプト引数およびドリフト監視の開始
例31.1 ドリフト定義を自動化せずにシステムプロパティー
31.1.3.3. 起動スクリプト設定の変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 5 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- Operations セクションを展開します。
- 開始スクリプトの設定を変更または追加します。これらは、EAP 5 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
- カスタムの開始スクリプトを使用するには、パスとスクリプト名を入力します。
- 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。
- 各行に 1 つずつ環境変数を設定します。
- スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常
-X
-D
、またはです-P
。便利な-XX
引数の一部は、Sun の JVM オプションのドキュメントに記載されています。EAP 5 のデフォルト起動スクリプトは - 形式のrun.sh
スクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
- ページ上部の Save ボタンをクリックします。
31.2. JBoss EAP 5 つのリソースの作成
31.2.1. データソースの作成
- データソースをデプロイする JBoss サーバーインスタンスを検索します。
- 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
- Create New ドロップダウンメニューで、の項目を選択し - Data Sourcesます。
- データソースのテンプレートを選択します。データソースに共通の情報を入力するためのデータソーステンプレートは 3 つあります。
- デフォルトのテンプレートは、PostgreSQL や MySQL などの SQL データベースで使用されます。
- Oracle Local TX は、ローカルトランザクションを含む Oracle データベースに使用されます。
- Oracle XA テンプレートは、XA トランザクションを使用する Oracle データベースに使用されます。
- リソース名などの分かりやすい設定と共に、デプロイする特定の子リソースの情報を入力します。
- 作成するデータソースのタイプ(No TX データソース、ローカル送信データソースまたは XA データソース)
- バインドに使用する DataSource ラッパーの一意の JNDI 名。
- たとえば、JDBC ドライバーまたは DataSource クラスの完全修飾名。
org.postgresql.Driver
- などの JDBC ドライバー接続 URL 文字列。 jdbc:postgresql://127.0.0.1:5432/foo
- データソースへの接続に使用するユーザー名およびパスワード
- このデータソースの接続プールの最大サイズおよび最大プールサイズ
Advanced Settings このエリアでは、その他の設定が可能です。
31.2.2. 接続ファクトリーの作成
- 接続ファクトリーをデプロイする JBoss サーバーインスタンスを検索します。
- 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
- Create New ドロップダウンメニューで、の項目を選択し - Connection Factoryます。
- リソース名などの分かりやすい設定と共に、デプロイする特定の子リソースの情報を入力します。
- tx-connection-factory(トランザクション)または no-tx-connection-factory(トランザクションなし)のいずれかで作成する接続ファクトリーのタイプ。
- バインドに使用する DataSource ラッパーの一意の JNDI 名。
- データソースへの接続に使用するユーザー名およびパスワード
- このデータソースの接続プールの最大サイズおよび最大プールサイズ
Advanced Settings このエリアでは、その他の設定が可能です。
31.2.3. JMS キューおよびトピックの作成
- JMS キューまたはトピックをデプロイする JBoss メッセージングサービスを検索します。
- 選択した JBoss メッセージングサービスの詳細ページで、Inventory タブを開きます。
- Create New ドロップダウンメニューで、- JMQ JMS Topic またはを選択し - JMQ JMS Queue ます。
- リソース名などの明確な設定以外に、JMS Queue または JMS Topic エントリーには 2 つの追加パラメーターが必要です。
- JMX オブジェクト名として使用するキューまたはトピックの名前。
- バインドに使用する DataSource ラッパーの一意の JNDI 名。
Advanced Settings このエリアでは、その他の設定が可能です。
31.3. アプリケーションのデプロイ
31.3.1. アプリケーションをデプロイするための領域に関する考慮事項
31.3.2. EAR ファイルおよび WAR ファイルのデプロイ
- EAR または WAR をデプロイする JBoss サーバーインスタンスを検索します。
- 選択した JBoss サーバーインスタンスの詳細ページで、Inventory タブを開きます。
- 下部の Create New メニューで、- Web Application (WAR) またはの項目を - Enterprise Application (EAR)適宜選択します。
- バージョン番号を入力します。これはリソースには使用されません。実際のバージョン番号は、に含まれる spec バージョンおよび実装バージョン(指定されている場合)
MANIFEST.MF
、またはパッケージ自体に対して計算される SHA-256 値に基づいて算出されます。SPEC(IMPLEMENTATION)[sha256=abcd1234]
のバージョン番号が定義されていない場合はMANIFEST.MF
、SHA 値が使用されます。SHA 値は常にパッケージバージョンを内部的に識別するために使用されます。注記EAR または WAR ファイルがデプロイ後に展開されると、MANIFEST.MF
ファイルが更新され、計算された SHA バージョン番号が組み込まれます。例:Manifest-Version: 1.0 Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...パッケージのバージョン管理の詳細は、を参照してください 「パッケージバージョンと履歴」。 - EAR/WAR ファイルをアップロードします。
- デプロイするアプリケーションに関する情報を入力します。
- ファイルがデプロイ時に展開(未展開)されるかどうか。
- EAR パッケージまたは WAR パッケージをデプロイするディレクトリーへのパス。宛先ディレクトリーは JBoss サーバーインスタンスのインストールディレクトリーに相対的です。このディレクトリーには絶対パスが含まれたり、親ディレクトリーに移動したりすることはできません。
- ターゲットディレクトリーの同じ名前の既存ファイルをバックアップするかどうか。
図31.1 WARE リソース
31.3.3. アプリケーションの更新
- JBoss ON UI で EAR または WAR リソースを参照します。
- EAR または WAR リソースの詳細ページで Content タブを開き、New サブタブをクリックします。
- UPLOAD NEW PACKAGE ボタンをクリックします。
- UPLOAD FILE ボタンをクリックします。
- ポップアップウィンドウで Add ボタンをクリックし、アップロードする更新された WAR または EAR ファイルにローカルファイルシステムを参照します。
- UPLOAD ボタンをクリックしてファイルを読み込み、ウィンドウを終了します。
- メイン形式で、WAR または EAR ファイルパッケージを保存するリポジトリーを選択します。存在する場合は、そのリソースに既存のリポジトリーまたはサブスクライブされたリポジトリーを選択します。それ以外の場合は、新規リポジトリーを作成します。
- 必要に応じて、EAR/WAR パッケージのバージョン番号を設定します。これが設定されている場合、この値は UI に表示されます。そうでない場合は、に含まれる spec バージョンおよび実装バージョン(指定されている場合)
MANIFEST.MF
、またはパッケージ自体に対して計算される SHA-256 値に基づいて、バージョン番号が算出されます。内部では、パッケージは SHA 値で識別されます。SPEC(IMPLEMENTATION)[sha256=abcd1234]
パッケージのバージョン管理の詳細は、を参照してください 「パッケージバージョンと履歴」。 - 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
図31.2 リソースのデプロイメント履歴
31.3.4. アプリケーションの削除
- JBoss ON UI で EAR または WAR リソースを参照します。
- EAR または WAR リソースの詳細ページで Content タブを開き、Deployed サブタブをクリックします。
- EAR/WAR パッケージでチェックボックスを選択し、DELETE SELECTED ボタンをクリックします。
31.4. パッチ RSS フィードバックからの JBoss パッチの適用
31.4.1. JBoss リソースのパッチ適用方法の計画
- コンテンツソースの特定および設定
- 手動手順の実行方法の計画
31.4.1.1. コンテンツソースの特定
31.4.1.2. 手動ステップのプランニング
- パッチが適用されるファイルは設定に表示されません。
- 手動で削除する必要があるファイルがあります。
- XML や Java プロパティーファイルなどの設定ファイルには、手動で適用する必要のあるパッチが必要です。
- Seam が使用されており、手動でパッチを当てる必要があります。
31.4.2. デフォルトの JBoss パッチコンテンツソースの有効化
- トップメニューの Administration タブでメニューを開き、Content Sources 項目を選択 Content します。
- JBoss Customer Portal Patch Feed ソースをクリックします。
- Customer Portal Feed Settings エリアの下部にある Edit ボタンをクリックして、コンテンツソースを変更します。
- 必要な接続情報を入力します。
- カスタマーポータルのユーザー名およびパスワード。注記カスタマーポータルのパスワードは、JBoss ON データベースに格納されると難読化されます。
- コンテンツソースの URL(https://access.redhat.com/jbossnetwork/restricted/feed/software.html?product=all&downloadType=all&flavor=rss&version=&jonVersion=2.0)。
- アクティベーションの状態。これは、自動パッチ Yes を有効にする必要があります。
スケジュールなどのほとんどのデフォルト設定は保持できます。重要Lazy Load チェックボックスをアクティベートするか、または RSS feed で定義されたすべてのパッチ(データの 1 GB)は JBoss ON サーバーによって事前にダウンロードされます。 - をクリックし Saveます。
- 必要に応じて、Synchronize ボタンを使用してコンテンツソースを強制的に実行し、最新の RSS フィードをプルし、ローカルデータと同期します。同期試行の履歴がに記載されてい Synchronization Results sectionます。
- パッチの適用を終了するには、手動の手順(「手動ステップのプランニング」)を実行します。
31.4.3. 特定のリソースのデフォルトの JBoss パッチリポジトリーへのサブスクライブ
- トップメニューの Resources 項目で、Servers 項目に移動します。
- リポジトリーにサブスクライブする JBoss インスタンスを検索します。
- JBoss サーバーリソースのエントリーページでタブを開き、Subscriptions サブ Content タブを選択します。JBoss パッチリポジトリーはサブスクリプションで利用できます。
- JBoss パッチリポジトリーの横にあるチェックボックスを選択し、SUBSCRIBE ボタンをクリックします。割り当てが完了すると、リポジトリーはではなく Current Resource Subscriptions エリアに一覧表示され Available Repositoriesます。
31.4.4. 複数の JBoss リソースのデフォルトの JBoss パッチリポジトリーへのサブスクライブ
- トップメニューの Administration タブでメニューを開き、Repositories 項目を選択 Content します。
- をクリックし JBoss Patch Channelます。JBoss パッチリポジトリーは、デフォルトで JBoss パッチコンテンツソースに関連付けられます。リポジトリーを別のコンテンツソースに関連付けるには、ASSOCIATE... ボタンをクリックしてコンテンツソースを割り当てます。
- リポジトリーのメインページで、SUBSCRIBE... ボタンをクリックして JBoss リソースをパッチリポジトリーにサブスクライブします。
- 検索エリアで、ドロップダウンメニュー Server でを選択します。
- このリポジトリーにサブスクライブするすべての JBoss サーバーインスタンスリソースを選択します。
31.4.5. パッチの適用
- JBoss インスタンスを停止します。
- トップメニューの Resources 項目で、Servers 項目に移動します。
- パッチを適用する JBoss インスタンスを検索します。
- JBoss サーバーリソースのエントリーページでタブを開き、New サブ Content タブを選択します。これにより、特定のリソースタイプで利用可能なパッケージおよびパッチがすべて一覧表示されます。
- インストールするパッチが適用された名前の横にあるチェックボックスを選択し、DEPLOY SELECTED ボタンをクリックします。
- このページの情報を確認し、すべてが正しいことを確認します。Instructions 列の VIEW リンクをクリックし、パッケージのインストールプロセス中に実行する手順を確認します。
- 必要に応じて、注記を入力し、パッチのデプロイメントまたは環境を記述します。
- CONTINUE ボタンをクリックして更新をインストールします。パッチプロセスはバックグラウンドで実行されます。進捗は、タブの History サブ Content タブで表示できます。
- インストールプロセスが完了すると、Completed Requests このエリアにパッチジョブが表示されます。VIEW ボタンをクリックすると、プロセスで実行されたステップと、完了、失敗、またはスキップされたステップが表示されます。
- パッチプロセスが完了したら、JBoss インスタンスを起動します。
第32章 JBoss EAP 6 の管理(AS 7)
32.1. JBoss EAP 6 の構造
32.1.1. 「classic」構造: スタンドアロンサーバー
standalone.xml
ファイルに定義されます。そのファイルのほとんどすべてのエントリーは、サーバーの子として識別されます。たとえば、以下のサブシステムエントリーは ee、サーバーの jmx 子リソースを作成します。
<subsystem xmlns="urn:jboss:domain:ee:1.1"/> <subsystem xmlns="urn:jboss:domain:jmx:1.1"> <show-model value="true"/> <remoting-connector/> </subsystem>
standalone.xml
ます。
図32.1 スタンドアロンサーバー設定
32.1.2. 設定とリアルタイム操作の分離: ドメイン
図32.2 簡易ドメイン構造
domain.xml
ファイルに定義されます。これにより、設定されたプロファイルおよびサブシステム、サーバーグループ、ソケットバインディング設定、システムプロパティー、デプロイメント、およびその他の設定がすべて一覧表示されます。スタンドアロンサーバーと同様に、ほぼすべてのエントリーが検出され、リソースとしてインベントリーに追加されます。たとえば、これにより、子デプロイメントリソースとサーバーグループの子 JVM リソースを持つサーバーグループリソースが作成されます。
例32.1 Server Group domain.xml エントリー
<server-group name="main-server-group" profile="full"> <jvm name="default"> <heap size="1303m" max-size="1303m"/> <permgen max-size="256m"/> </jvm> <socket-binding-group ref="full-sockets"/> <deployments> <deployment name="sample2.war" runtime-name="sample2.war"/> </deployments> </server-group>
host.xml
ファイルで識別されます。これらの管理サーバーは実質的には独自の設定を持ちません。ドメインで使用する元のサーバーグループ設定に戻るだけです。
<servers> <server name="server-one" group="main-server-group"/> <server name="server-two" group="other-server-group"> <!-- server-two avoids port conflicts by incrementing the ports in the default socket-group declared in the server-group --> <socket-bindings port-offset="150"/> </server> </servers>
図32.3 EAP 6 コンソール
図32.4 ドメインリソース
図32.5 JBoss ON インベントリーのドメインコンポーネント
32.1.3. JBoss ON の EAP 6 リソース
standalone.xml
は domain.xml
host.xml
、リソースタイプとして解釈されます。EAP 6 では設定コンポーネントと運用コンポーネントの違いがあるため、JBoss ON の EAP 6 リソースタイプは異なることを行います。また、リソースによっては設定を定義し、監視、アラート、および操作に使用されます。
32.1.4. JBoss ON を使用した EAP 6 リソースの管理の目的
- 保存した履歴データ、リソース固有の運用ベースライン、および代替の表示タイプを含む、リソースの追加の監視メトリック
- 履歴の設定および接続設定
- JBoss ON で子を追加または削除した場合のインベントリー変更履歴
- 制御されたパッケージ更新用のパッケージバージョン管理およびリポジトリー
- プラットフォーム、Apache サーバー、Tomcat Web サーバーなどの基礎となるリソースおよび関連するリソースの設定、監視、アラート、およびアラート mod_cluster
32.2. JBoss EAP 6 リソースプラグインのアップグレード
手順32.1 EAP 6 プラグインを読み込む方法
- 元のテクノロジープレビュープラグインを削除し、JBoss ON データベースからパージします。プラグインをパージすると、サーバーはその場所に新しいプラグインをデプロイできます。
- トップメニューで、Administration タブをクリックします。
- 左側のナビゲーションバーの Configuration ボックスで、Agent Plugins リンクをクリックします。
- EAP 6 のテクノロジープレビュープラグインを選択します。
- Delete ボタンをクリックします。
- サーバーがアップグレードされていない場合は、『インストールガイド』の「サーバーのアップグレード」セクションで説明されているように、JBoss ON サーバーをアップグレード します。
- EAP 6 サーバーとその子をインポートし、通常通りにリソースを管理します。
32.3. JBoss EAP 6 インスタンスの設定
32.3.1. EAP 6 インスタンスを検出するエージェントの設定
- エージェントには、ファイルの読み取り権限が必要です。さらに、
run.jar
ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になりrun.jar
ます。 - RPM から JBoss EAP 6 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。
32.3.2. サーバーおよびプロファイルの設定
32.3.2.1. スタンドアロンサーバーおよびドメインの相違点
図32.6 EAP 6 コンソールのプロファイルエリア
- サブシステム設定はドメインコントローラーの autogroup 内の Profiles プロファイルリソースにあります。
- JVM 定義は、ドメインコントローラー(ドメイン全体のデフォルト)、サーバーグループ(グループ全体の設定)、または管理対象サーバー(ローカル設定)で設定されます。
- ネットワークインターフェースはドメインコントローラーで設定されます。
- ソケットバインディング自体は、ドメインコントローラーの autogroup の下にあるエントリーでドメインコントローラー設定の一部として SocketBindings 設定されます。各サーバーグループと管理対象サーバーにはオフセットがあり、ソケットバインディング値に追加されます。これは、管理対象ドメインで一意のポート番号を提供するために使用される番号です。これらのオフセットはサーバーグループと管理対象サーバーの接続設定で設定されます。
- システムプロパティーは、ほぼすべてのサーバーリソース(ドメインコントローラー、ホストコントローラー、サーバーグループ、管理対象サーバー)で設定できます。
32.3.2.2. EAP 6 で必要な管理インターフェース
/host=instanceName/core-service=management/management-interface=http-interface:add(interface=http,port="\${jboss.management.http.port:9990}",security-realm=ManagementRealm
32.3.2.3. JBoss ON の設定機能
- バージョン間の diffs を含む変更履歴の表示
- ボタンをクリックして、以前のバージョンへの変更をロールバックします。
- 監査証跡の一部として変更を行ったユーザーを追跡
- アラートを使用して、設定変更の管理者に通知します。
- ドリフト監視を定義して、定義したベースラインに対して設定の変更を追跡し、予期しない設定変更を制御する
32.3.3. Setup CLI 操作を使用した JBoss ON と EAP 6 間の SSL 認証
jboss-cli.sh
または jboss-cli.bat
)への JBoss ON GUI アクセスが可能になります。この操作は JBoss ON と EAP 間 Execute CLI script で <EAP_install_directory>/bin/jboss-cli.xml
公開鍵を更新し、JBoss ON GUI からの Execute CLI commands /からの操作を可能にします。
- この操作は 任意です。jboss-cli は EAP 6 のドキュメントを使用して手動で設定できます。詳細は、「 Setting up 2-Way SSL/TLS for the Management Interfaces 」を参照してください。Setup CLI 操作を使用するには、JBoss ON エージェントには EAP ファイルおよびディレクトリーへの読み取りおよび書き込み権限が必要です。これ Setup CLI は、JBoss ON 3.3 向けに Enterprise Application Platform(EAP)Management Plug-in Pack Update-03 によって導入されました。
表32.1 Setup CLI 操作から利用できるプロパティー
property | description |
---|---|
デフォルトコントローラー | JBoss ON コントローラーホストおよびポートを EAP 6 の JBoss CLI のデフォルトとして設定します。 |
security | EAP 6 にセキュアな管理インターフェースがある場合、このオプションは Store Password Method を基にして JBoss ON と EAP 間の認証を設定します。これにより、JBoss ON は EAP 6 JBoss CLI を実行できるようになります。 |
ストアパスワードメソッド | セキュリティーを設定する際に、パスワードを jboss-cli.xml に保存するメソッドを設定します。
|
手順32.2 Setup CLI 操作の使用
- JBoss ON CLI で Inventory タブをクリックします。
- Resources メニューからをクリックし Servers、設定する EAP サーバーを選択します。
- EAP サーバーリソースページから、Operations タブをクリックします。
- New をクリックし、新しい操作をスケジュールします。
- Operation ドロップダウンリストから、以下に示すように Setup CLIを選択します。
図32.7 Setup CLI 操作の例
- 必要なプロパティーを変更するには、Unset? チェックボックスをクリアし、該当するをクリックし Valueます。
- Schedule をクリックし、操作を保存します。このページは Operations History タブにリダイレクトします。
- Setup CLI 操作が実行され、ステータスが success を示す場合、以下のように Setup CLI 操作の Date Submitted エントリーをクリックして、操作の結果を表示し、変更が正常に行われたことを確認し ます。
図32.8 Setup CLI 操作の結果の例
32.3.4. 管理ユーザーの作成
- LDAP ディレクトリーまたは外部データストアの使用これは EAP 6 の最もセキュアな実装であり、推奨されます。
- JBoss ON を使用して管理ユーザーを作成します。
- EAP add-user スクリプトでローカル EAP アカウントを作成する。
32.3.4.1. 管理ユーザーの認証情報の設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開きます。
- Connection Settings サブタブを選択します。
- EAP 6 で作成した管理ユーザーのユーザー名とパスワードを入力します。
- ページ上部の Save ボタンをクリックします。
32.3.4.2. JBoss ON での管理ユーザーの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Install RHQ User オプションを選択します。
- Schedule ボタンをクリックします。
32.3.4.3. EAP 6 での管理ユーザーの作成
- add-user ユーティリティーを実行してユーザーを作成します。
[root@server ~]# cd /opt/jboss-eap-6.0 [root@server bin]# ./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Enter the details of the new user to add. Realm (ManagementRealm) : Username : jonadmin Password : Re-enter Password : About to add user 'jonadmin' for realm 'ManagementRealm' Is this correct yes/no? yes
- JBoss ON の EAP 6 サーバーリソースの接続設定でそのユーザーを設定します。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開きます。
- Connection Settings サブタブを選択します。
- EAP 6 で作成した管理ユーザーのユーザー名とパスワードを入力します。
- ページ上部の Save ボタンをクリックします。
32.3.5. EAP 6 リソースの動的グループの作成
- トップメニューの Inventory タブをクリックします。
- 左側の Groups エリアで、Dynagroup Definitions リンクをクリックします。
- EAP 6 のサーバータイプごとに互換性のあるグループを作成する式を入力します。
resource.type.plugin = JBossAS7 resource.type.category = SERVER resource.parent.type.category = PLATFORM groupby resource.pluginConfiguration[productType] groupby resource.type.name
- ページの中央にある Save ボタンをクリックします。
32.3.6. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定
32.3.6.1. スクリプト検出と設定の開始
- 検出プロセスは、カスタム開始スクリプトを含む、使用される開始スクリプトを特定または試行します。
- Discovery は、開始スクリプトが機能するために必要な
run.conf
ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。注記検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値を検出しません。開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のためにrun.conf
ファイルに移されます。 - 検出は、開始スクリプト自体で渡された引数の検出を試みます。
- Discovery は、スクリプトが実行しているユーザーを検出し、start スクリプトで使用する 接頭辞 コマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
-XX:PermSize=256M
)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
32.3.6.2. スクリプト引数およびドリフト監視の開始
例32.2 ドリフト定義を自動化せずにシステムプロパティー
32.3.6.3. 起動スクリプト設定の変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- Operations エリアを展開します。
- 開始スクリプトの設定を変更または追加します。これらは、EAP 6 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
domain.sh
または以外のカスタムの開始スクリプトを使用するにはstandalone.sh
、パスとスクリプト名を入力します。- 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。起動スクリプトが検出されると、エージェントはスクリプトが実行されているユーザーを判断しようとし、start スクリプトで使用するプレフィックスコマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。さらに、JBoss ON は nohup コマンドをプレフィックスとして割り当て、JBoss Enterprise Application Platform がエージェントによって開始され、エージェントプロセスが終了すると、JBoss Enterprise Application Platform プロセスが実行を継続します。
- 各行に 1 つずつ環境変数を設定します。
- スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常
-X
-D
、またはです-P
。便利な-XX
引数の一部は、Sun の JVM オプションのドキュメントに記載されています。EAP 6 の便利なシステムプロパティーの一部は、JBoss AS7 プロジェクトのドキュメント に記載されています。EAP 6 のデフォルトの起動スクリプトは - 形式のrun.sh
スクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
- ページ上部の Save ボタンをクリックします。
32.3.6.4. スタンドアロンモードでの JVM ヒープ引数の変更
standalone.conf
か standalone.bat
(OS によって異なります)。
- トップメニューのインベントリータブをクリックします。
- 左側の Resources メニューテーブルで「Servers - Top Level Imports」を選択し、右側の表で該当する JBoss Enterprise Application Platform 6 スタンドアロンサーバーをクリックします。
- JBoss Enterprise Application Platform Server の詳細で「 Inventory」タブをクリックします。
- 「Connection Settings」サブタブをクリックします。
- テーブルの「Operations」セクションの「Additional JAVA_OPTS」行までスクロールします。
- 外観を追加するには、「Unset?」チェックボックスの選択を解除し、そのテキストをテキストボックスに追加します。注記"Unset" チェックボックスは、設定が JBoss ON Server から使用されているかどうかのみ決定します。「未設定」チェックが解除されると、テキストボックスの値が使用されます。"Unset" がチェックされると、テキストボックスの値は使用されません。「 Unset?」チェックを実行しても、設定ファイルが JAVA_OPTS を設定しないことを意味します。これは単に値が JBoss ON を介して設定されていないことを意味します。
- 「 Save」をクリックします。
- この更新を反映するには、JBoss Enterprise Application Platform 6 サーバーを再起動する必要があります。
32.3.7. ポート番号の変更
32.3.7.1. ソケットバインディングポートの変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで SocketBindingsGroup 互換性のあるグループを選択し、編集するソケットバインディングを選択します。
- Configuration タブを開きます。
- 鉛筆アイコンをクリックして既存のソケット定義を編集するか、プラス記号(+)をクリックして新しいソケット定義を作成します。
- 1025 から 65535 までの利用可能なポートに Port 番号を変更します。Linux では、利用可能なポート番号はを使用して決定でき iptablesます。オプションで、ソケットのマルチキャスト設定を行います。同じシステムまたは同じクラスターに複数の JBoss サーバーインスタンスがある場合、マルチキャストはクラスター通信用に設定されます。
- ページ上部の Save ボタンをクリックします。
32.3.7.2. ドメインのサーバーグループのポートオフセットの変更
host.xml
ファイルのエントリーで定義されます。これは、JBoss ON で管理サーバーの作成時に設定できますが、後で編集することはできません。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで Server Groups ノードを展開し、サーバーグループを選択します。
- サーバーグループの Configuration タブを開きます。
- Port Offset フィールドにオフセットの新しい値を入力します。
- ページ Save 上部をクリックします。
32.3.8. ネットワークインターフェースの編集
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで Server Configuration で Network Interfaces グループを選択し、インターフェース(management、public、または unsecure)を選択します。
- Configuration タブを開きます。
- 使用するインターフェースの特定の IP アドレスを設定するか、使用する IP アドレスの タイプ (IPv4、IPv6、またはどちらか)を設定します。IP アドレスまたは IP アドレスタイプを設定する必要があります。特定の IP アドレスまたは IP アドレスタイプのいずれかを設定できます。また、使用するプロパティーは任意であるため、UI では選択が強制されることはありません。ただし、ネットワークインターフェースが適切に機能するには、一部の IP アドレス設定を設定する必要があります。
- ページ上部の Save ボタンをクリックします。
32.3.9. システムプロパティーの設定
domain.xml
ファイルのコンポーネントのエントリーに追加されます。ホストコントローラーまたは管理対象サーバーを編集すると、プロパティーが host.xml
ファイルのサーバーのエントリーに追加されます。
-D
または -P
引数で start スクリプトで上書きできます。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開きます。
- Properties セクションを展開します。
- Paths リストの下部にあるプラス(+)アイコンをクリックします。
- 新しいプロパティー情報を入力します。
- システムプロパティー名。
- プロパティーの値。
- プロパティーを稼働中の JVM に即座にロードする必要がある場合や、JVM の起動時にロードする必要がある場合。デフォルトでは、即座に読み込むことができます。
- をクリックし OKます。
32.3.10. システムパスの追加
jboss.*
user.*
、およびで始まり java.*
ます。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開きます。
- Paths セクションを展開します。
- Paths リストの下部にあるプラス(+)アイコンをクリックします。
- パス情報を入力します。
- 作成するパスの名前。
- 作成するパス(絶対または相対パス)。
- 相対パスが Path 値として指定された場合は、Relative フィールドの Unset? チェックボックスの選択を解除し、相対パスの 名前 を入力します。たとえば、新しいパスがで
devel/
、これが EAP ホームディレクトリーとの相対パスである場合、Relative 値は java.home.dir になります。これにより、の最終パスが作成され/opt/jboss-eap-6.0/devel/
ます。 - プロパティーが読み取り専用である場合。読み取り専用プロパティーの作成後は編集 できません。読み取り専用パス(デフォルトのパスから)を削除し、変更する必要がある場合には再作成する必要があります。
- をクリックし OKます。
32.3.11. 接続設定の編集
32.3.11.1. EAP 6 サーバーの一般プロパティーの変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- サーバー接続プロパティーは General Properties セクションにあります。プロパティーの一部のみを編集できます。ホームディレクトリー、ベースディレクトリー、サーバータイプ(EAP または AS)などの JBoss EAP 6 インストール自体から派生した情報が表示されますが、非アクティブになります。
- Hostname サーバーへの接続に使用する IP アドレスを指定します。通常 127.0.0.1 ですが、管理インターフェース設定が変更された場合、IP アドレスは localhost ではなくパブリック IP になります。
- Port は管理インターフェースのポートです。
- Secure SSL を使用して JBoss Enterprise Application Platform 6 管理インターフェースと通信するかどうかを示します。JBoss ON エージェントが JBoss Enterprise Application Platform 6 スタンドアロンサーバーまたはホストコントローラーの HTTP 管理インターフェースが SSL を使用することを検出すると、検出中に true に設定されます。
- Username および Password は、エージェントがログインに使用する JBoss EAP 6 ユーザーのクレデンシャルです。このユーザーが、インストール RHQ ユーザー操作 を使用して作成されている場合、ユーザーはになり rhqadminます。
- ドメインコントローラーのみ。スタンドアロンサーバーでは、設定とサーバーインスタンスの定義はすべて同じファイル
standalone.xml
か、起動スクリプトに渡されるその他の設定ファイルにあります。ドメインの場合、サーバー設定は 1 つのファイル(ドメインコントローラー用)で定義されますが、サーバーインスタンスは別のファイル(ホストコントローラー用)で定義されます。Domain Configuration および Host Configuration フィールドには、プロファイル設定、および管理対象サーバーインスタンスを参照するdomain/configuration/
ディレクトリー内のファイルの名前がそれぞれ示されます。
- ページ上部の Save ボタンをクリックします。
32.3.11.2. JBoss Enterprise Application Platform 6 サーバーのセキュア接続設定の変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- セキュアな接続設定は Secure Connections Settings セクションにあります。
- セキュアな接続設定を適切な情報で構成し、をクリックし Saveます。
- JBoss ON は、次の可用性スキャンの後にこれらの設定の使用を開始します。
32.3.11.3. EAP 6 トピックリソースのインストールパスの表示
domain.xml
ファイルに含まれます。
<server-groups> <server-group name="main-server-group" profile="full"> ...
図32.9 子リソース接続設定
32.3.12. インストール済み拡張の表示
domain.xml
または standalone.xml
)で定義されるモジュールのクラスです。
<extensions> <extension module="org.jboss.as.clustering.infinispan"/> <extension module="org.jboss.as.clustering.jgroups"/> <extension module="org.jboss.as.cmp"/> <extension module="org.jboss.as.configadmin"/> <extension module="org.jboss.as.connector"/> <extension module="org.jboss.as.ee"/> <extension module="org.jboss.as.ejb3"/> ...
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開きます。
- Installed extensions セクションを展開します。
32.3.13. サーバー設定の再読み込み
図32.10 設定メッセージのリロード
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Reload)オプションを選択します。
- Schedule ボタンをクリックします。
32.3.14. 設定項目の制御
- やなどの重要な設定ディレクトリーを追跡するドリフト定義を設定
domain/configuration/
しますがstandalone/configuration/
、ロギング、ライブラリー、データディレクトリーなど、常にデータが変更されるディレクトリーは除外されるようにします。設定ディレクトリー内でも、、、host_xml_history/
domain_xml_history/
、およびディレクトリーの除外ルールを作成します。これらは適切な設定ファイルではなくstandalone_xml_history/
、追跡すべきではありません。 - 必要な設定が配置されたら、その 設定 をドリフト定義に固定します。これにより、希望の設定がベースラインとして設定されます。すべての変更は、そのベースラインと比較されます。
- 設定ファイル設定のアーカイブを作成します。
- EAP 6 の設定をリセットし、ドリフトを修正するために自動的にデプロイできるバンドル定義を作成します。移行先の作成時には、EAP 6 リソースのプラットフォームである必要があります。宛先はスタンドアロンサーバーまたはドメインコントローラーのいずれかですが、プラットフォームを使用すると、バンドルを期限切れのディレクトリーにデプロイしてから
/tmp/mybundles/holding
、インストール後のタスクを実行して設定ファイルを configuration ディレクトリーにコピーします。通常、バンドルをデプロイすると、ターゲットディレクトリーにある既存ファイルがすべて削除され、バンドルに置き換えられます。この動作を制御する方法はありますが、通常はバンドルの内容が最終デプロイメントの目的と完全に一致するのは安全です。バンドルに設定ディレクトリー全体を含めることができないため、ファイルシステム上の別の場所にデプロイすると設定ディレクトリーが保持され、重要な設定ファイルのみが Ant タスクによってコピーされます。バンドルの詳細やドリフトの調整は、「 JBoss ON Command-Line Scripts」の「 27章バンドルへのコンテンツおよびアプリケーションのデプロイ drift-bundle CLI サンプルスクリプト」を参照してください。 - 2 つのことを行う設定のドリフトに関するアラートを設定します。
- 管理者に通知メールを送信します。
- バンドルを自動的にデプロイするプラットフォームで CLI スクリプトを実行します。
25章アラートの定義 JBoss ON サーバーサイドスクリプトを起動するアラート通知を設定する方法や、別のリソースで操作を実行する方法についての情報があります。
domain.xml
および変更を行い standalone.xml
ます。これにより、アラートが設定されている場合にドリフトアラートがトリガーされます。
32.3.15. 設定変更の追跡および取り消し
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開き、History サブタブを選択します。注記変更履歴ページは、リソース設定( Configuration タブ)および接続設定( Inventory > Connection Settings タブ)に対して保持されます。
- ID 番号の変更をクリックすると、その バージョン に適用された構成設定が開きます。
- 変更内容は、一覧から選択して Compare ボタンをクリックして、標準の diff 形式の変更を比較できます。
- 現在、ライブバージョンの設定は、一覧で目的の 以前 のバージョンを選択して Rollback ボタンをクリックすることで、以前のバージョンに戻すことができます。
32.4. JBoss EAP 6 リソースの作成
32.4.1. 履歴の追跡
図32.11 子履歴
32.4.2. サーバーグループの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- ドメインコントローラーエントリーを右クリックします。
- Create Child メニューで、の項目を選択し Server Groupます。
- 新しいサーバーグループの名前を入力します。
- サーバーグループの設定: 使用するプロファイル、使用するソケットバインディンググループ、および設定するシステムプロパティーを入力します。
- をクリックし Finishます。
32.4.3. 管理対象サーバーの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- ドメインコントローラーエントリーを右クリックします。
- Create Child メニューで、の項目を選択し Managed Serverます。
- 新しいサーバーの名前を入力します。
- サーバーの設定を入力します。
- サーバーを作成する EAP 6 ドメインホスト。
- サーバーを追加するサーバーグループ。
- 使用するソケットバインディンググループ。これにより、使用するサーバーインスタンスのベースポート番号が指定されます。
- ポートオフセット。これは、ソケットバインディング設定に追加して、サーバーインスタンスの実際のポート番号を判断する番号です。ソケットバインディングポートが 1000 で、オフセットが 150 の場合は、管理対象サーバーのそのインターフェースに使用されるポート番号は 1150 になります。
- EAP 6 ホストの起動時にサーバーが自動的に起動するかどうか。
- サーバーのシステムプロパティー。
- をクリックし Finishます。
32.4.4. JVM 定義の変更
32.4.4.1. リソースとしての JVM 定義
図32.12 EAP 6 コンソールでの JVM 定義
32.4.4.2. JVM 定義の作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- JVM 定義を追加するエントリーを右クリックします。
- Create New メニューで、の項目を選択し JVM Definitionます。
- 定義の名前を入力します。注記JVM 定義の名前はホストコントローラーの任意の名前になります。管理対象サーバーまたはサーバーグループでは、JVM 定義の名前は、定義のベースであるホストコントローラーの JVM 定義と同じである必要があります。
- JVM の設定を入力します。空白のままにすると、親 JVM 定義で定義された値が使用されます。JVM の設定の大半は、メモリーとリソースの使用状況に関連するもので、環境変数やその他の設定を JVM に渡すオプションに関連します。この設定の値は、リソースのパフォーマンスとシステム全体のパフォーマンスの両方に悪影響を及ぼす可能性があります。設定がに記載されてい 表32.2「JVM 定義プロパティー」 ます。
- をクリックし Finishます。
表32.2 JVM 定義プロパティー
property | description |
---|---|
JVM オプション | 他の Java オプションを設定します。これらのほとんどは、Sun のドキュメントなど Java プロバイダーで文書化されてい http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html ます。 |
環境変数 | JVM で使用する環境変数を設定します。 |
ヒープサイズ | JVM の初期ヒープサイズを設定します。 |
最大ヒープサイズ | JVM の最大許容ヒープサイズを設定します。これを設定しすぎると、メモリー不足のエラーが発生する可能性があります。 |
Permgen Size | 永続生成の初期サイズを設定します。 |
最大 Permgen サイズ | 永続生成の最大サイズを設定します。 |
type | JVM のタイプ。これは、JBoss ON でサポートされる Java タイプである Sun または IBM です。 |
32.4.4.3. JVM 定義の編集
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- EAP サーバーを選択し、適切な JVM 定義エントリーに移動します。
- Configuration タブを開きます。
- JVM 設定のいずれかを変更します。これらはに記載されてい 「JVM 定義の作成」 ます。
- ページ上部の Save ボタンをクリックします。
32.4.5. Parent-Child リソースの短いリスト
表32.3 Parent-Child リソースの短いリスト
resource | 子リソースタイプ |
---|---|
スタンドアロンサーバー |
|
ドメインコントローラー |
|
host |
|
サーバーグループ |
|
データソース(プロファイル下) |
|
Infinispan > Hibernate |
|
logging |
|
Web |
|
32.5. Web アプリケーションのデプロイ
32.5.1. ランタイム情報およびデプロイメントリソース
32.5.1.1. デプロイメントの表示
図32.13 ランタイムページでのデプロイメント
- Web アプリケーションは、個別のエンティティーとして、内およびそれ自体として扱われます。インベントリーには独自の場所があり、ドメインおよびサーバーグループとの関連性は、それらのリソースの子であるため反映されます。JBoss ON は、ファイルサイズや特定 SHA256 ハッシュなどのパッケージの詳細も記録します。
- Web アプリケーションには履歴があります。パッケージの更新が changelog に記録されるため、アプリケーションの維持方法を追跡できます。
- Web アプリケーションは監視できます。応答時間メトリックは、特に基盤のサーバーのパフォーマンスやモニタリング以外に、Web アプリケーションのパフォーマンスを追跡します。
図32.14 JBoss ON の Deployment Resource Details
- パッチおよび更新を格納するコンテンツリポジトリーの作成
- 複数バージョンのコンテンツの追跡
- ソフトウェアパッケージを以前のバージョンに戻す(特にスタンドアロンサーバーの場合)
- 複数のドメインおよびスタンドアロンサーバーを含む、複数の EAP インスタンスに同じコンテンツリポジトリーを使用
- コンテンツの変更の追跡(および監査)
32.5.1.2. スタンドアロンサーバーおよびドメインのデプロイメントパス
- 子リソースとしてデプロイメントを作成します。
- バンドルを使用してデプロイメントディレクトリーにアプリケーションをプロビジョニングします。
32.5.2. ドメインへの Web アプリケーションのデプロイメント
32.5.2.1. ドメインへの Web アプリケーションを帰リソースとしてデプロイ
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
- ドメインコントローラーエントリーを右クリックします。
- Create New メニューで、の項目を選択し DomainDeploymentます。
- バージョン番号を入力します。
- EAR、WAR、または JAR ファイルをアップロードします。
- オプションで、デプロイメントのランタイム名を入力します。
- ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。注記タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
- をクリックし Finishます。
図32.15 ドメインデプロイメントディレクトリー
32.5.2.2. バンドルを介したドメインへの Web アプリケーションのデプロイ
<project name="handover-test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle"> <rhq:bundle name="example.com (EAP 6)" version="1.0" description="example.com corporate website hosted on EAP 6"> <rhq:input-property name="myapp.runtime.name" defaultValue="website.war" required="true"/> <rhq:input-property name="myapp.serverGroup.name" defaultValue="main-server-group-01" required="true"/> <rhq:deployment-unit name="example.com deployment unit" compliance="filesAndDirectories"> <rhq:file name="prepareDatasource.cli" replace="true"> <rhq:handover action="execute-script"/> </rhq:file> <rhq:archive name="website.war"> <rhq:handover action="deployment"> <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/> <rhq:handover-param name="serverGroup" value="${myapp.serverGroup.name}"/> </rhq:handover> </rhq:archive> </rhq:deployment-unit> </rhq:bundle> <target name="main"/> </project>
- トップメニューで、Bundles タブをクリックします。
- Bundle セクションの New ボタンをクリックします。
- を選択 Upload し Choose てクリックし、目的のディストリビューションファイルに移動して選択します。
- をクリックし Nextます。
- 必要なバンドルグループを選択し、をクリックし Nextます。
- をクリックし Finishた後 Next、をクリックします。
- 新たにアップロードしたバンドルの Bundle セクションをクリックします。
- バンドルの詳細の Deploy ボタンをクリックします。
- 宛先情報を入力し、ウィザードに進みます。
32.5.3. サーバーグループへの Web アプリケーションの割り当て
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
- DomainDeployments フォルダーを展開します。デプロイメントフォルダーにすべての Web アプリケーションをデプロイするには、デプロイメントフォルダー自体を選択して操作を実行します。単一の Web アプリケーションをデプロイするには、特定の Web アプリケーションを選択します。
- サーバーの Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Assign to Server-Group オプションを選択します。
- アプリケーションをデプロイするグループ(またはすべてのグループ)を選択します。
- 操作の実行時やタイムアウト期間のスケジュールなど、操作の標準情報を入力します。注記タイムアウト期間は、操作がタイムアウトして失敗したことを想定するまでのサーバーが待機する時間を設定します。これは、操作の実行に失敗したり、停止したりすることを意味するわけではありません。
- 複数の Web アプリケーションをデプロイしている場合は、パッケージがデプロイされる順序を設定する方法に Execute ラジオボタンを設定します。すべてのパッケージは一度にデプロイすることも、特定の順序でデプロイすることもできます。
- Schedule ボタンをクリックします。
- 必要に応じて、エージェントで検出スキャンを実行して、新しいコンテンツリソースを検出します。デフォルトでは、サービスの検出スキャンは 24 時間ごとに実行されるため、新規コンテンツの検出に時間がかかる可能性があります。
- UI でエージェントエントリーを開きます。
- Operations タブを開き、execute prompt command 操作を選択します。
- discovery コマンドを操作 rgument として入力します。これで検出スキャンが実行されます。
- Schedule ボタンをクリックします。
32.5.4. 拡張例: Web アプリケーションの割り当てと更新の管理
設定
Tim the IT Guy は、開発からステージングおよび実稼働環境まで、Web アプリケーションの進捗を明確にしたいと考えています。EAP 6 のネイティブ構造では、異なるサーバーグループを作成し、各ステージでテストを渡す際に、中央ドメインコントローラーから適切なサーバーグループにコンテンツをデプロイできます。
The Plan
- Tim は、まず維持する必要のあるサーバーグループの概要を示します。シンプルな環境では、3 つのグループ(testing、staging、および production)が必要です。
- 2 つのコンテンツリポジトリーを作成します。1 つはパッチ用で、もう 1 つは Web アプリケーションの新しいバージョン用です。
- ドメインデプロイメントを作成し、web アプリケーションを testing サーバーグループにプロモートします。
- Tim は、Web アプリケーションの応答時間監視を設定します。テストエリアで必要なパフォーマンスパラメーターを満たすと、Tim はデプロイメントをステージング環境にプロモートし、次に実稼働サーバーグループにプロモートします。
結果
各デプロイメントのパッケージ履歴により、Web アプリケーションがデプロイされた時点、バージョン、およびそのコンテンツを追跡できます。
32.5.5. ドメインサーバーグループでの Web アプリケーションの有効化および無効化
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 ドメインコントローラーを選択します。
- インベントリーツリーでフォルダーを展開し、web アプリケーションを選択 DomainDeployments して一覧から有効または無効にします。
- Web アプリケーションの Configuration タブを開きます。
- Assigned to セクションで、Web アプリを有効または無効にするサーバーグループに対応する Server Group 行の青の鉛筆をクリックします。
- Enabled 行で Yes または No を選択し、OK をクリックします。
- Save ボタンをクリックします。
32.5.6. デプロイメントコンテンツの更新
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 サーバーを選択します。
- DomainDeployments フォルダーを開きます(スタンドアロンサーバーでは Deployment フォルダーを使用)、更新する Web アプリケーションを選択します。
- Web アプリケーションの詳細ページで Content タブを開き、New サブタブをクリックします。
- UPLOAD NEW PACKAGE ボタンをクリックします。
- UPLOAD FILE ボタンをクリックします。
- ポップアップウィンドウで Add ボタンをクリックし、ローカルファイルシステムをアップロードする更新されたコンテンツファイルを参照します。
- UPLOAD ボタンをクリックします。
- Web アプリケーションパッケージを保存するリポジトリーを選択します。これは不要ですが、更新されたパッケージを JBoss ON に保存して、他の JBoss EAP 6 デプロイメントで使用できるようにすることが推奨されます。
- バージョン情報を入力します。
- 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
図32.16 リソースのデプロイメント履歴
32.5.7. Web アプリケーションのスタンドアロンサーバーへのデプロイ
32.5.7.1. Web アプリケーションの クライアントリソースとしてのデプロイ
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 スタンドアロンサーバーを選択します。
- ナビゲーションツリーのスタンドアロンサーバーエントリーを右クリックします。
- Create New メニューで、の項目を選択し Deploymentます。
- バージョン番号を入力します。
- EAR、WAR、または JAR ファイルをアップロードします。
- オプションで、デプロイメントのランタイム名を入力します。
- ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。注記タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
- をクリックし Finishます。
32.5.7.2. バンドルへの Web アプリケーションのデプロイ
- トップメニューで、Bundles タブをクリックします。
- ディストリビューションファイルをアップロードし、デプロイメントウィザードにアクセスしてバンドルバージョンを作成します。
- ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
- デプロイするバンドルを選択します。
- JBoss スタンドアロンサーバーの宛先情報を定義します。宛先は、互換性のあるグループ(JBoss リソースを含む)とバンドルをデプロイするディレクトリーの組み合わせです。
- デプロイメントウィザードを完了し、必要なプロパティーを設定します。
32.5.8. コンテンツ履歴の追跡および変更の取り消し
図32.17 リソースのデプロイメント履歴
- ドメインデプロイメントまたはサーバーグループのデプロイメントがコンテンツリポジトリーに関連付けられている場合は、更新されたパッケージをコンテンツリポジトリーにアップロードし、変更を関連するリソースに同期します。
- 更新されたパッケージをドメインデプロイメントにアップロードし、deploy を使用して操作をグループ 化して、更新されたパッケージをサーバーグループに送信します。
32.5.9. バージョン管理されたデプロイメントおよびサブデプロイメント
^(.*?)-([0-9]+\\.[0-9].*)(\\..*)$
32.5.9.1. 既存のリソース
32.5.10. デプロイメントのトラブルシューティング
- 問: デプロイメントでは失敗と示唆されますが、パッケージの再デプロイを試みると、リソースがすでに存在することを示すため、失敗します。
- 問: サーバーグループにパッケージをデプロイしようとしましたが、デプロイメントが一覧に表示されません。
- エージェント検出スキャンが実行されていません。検出の実行には数時間かかる可能性があるため、アプリケーションが検出キューに表示されるまで時間がかかる場合があります。これを回避するには、エージェントで検出スキャンを実行します。
- パッケージが ドメイン にすでにデプロイされている。サーバーグループでデプロイメント子を作成すると、実際に(コンテンツが保存される)ドメインにデプロイメントを作成し、そのデプロイメントをサーバーグループにデプロイします。パッケージがドメインにすでに存在する場合は、サーバーグループでデプロイメントを複製として再度作成しようとすると失敗します。この場合は、デプロイを使用してドメインコントローラーでサーバーグループ 操作を行い、アプリケーションをデプロイします。
32.6. JBoss EAP 6 リソースの監視
32.6.1. ランタイム情報および JBoss ON Monitoring
図32.18 EAP 6 Runtime Metrics
- 各メトリクスの時間ベースのモニタリンググラフ
- リソースの実際のパフォーマンス で計算された操作パラメーター、またはベースライン
- 稼働時間の割合、復旧時間、およびダウンタイムの平均
図32.19 単一のメトリックの JBoss オンベースライン
- リソースにはより多くのメトリクスを使用できます。少なくとも、すべてのリソースには可用性監視があります。データソースや管理サーバーなどの一部のリソースには、ルーチン監視で有効にできる多くのメトリクスがあります。
- 応答時間監視は、Web アプリケーションの特定の URL およびページに対して設定できます。これにより、管理者は、Web アプリケーションのユーザビリティーやカスタマーエクスペリエンスを、接続数などの内部メトリクスと共に追跡できます。
- イベントログ監視は、異なるエラーログからの重要なメッセージをフィルタリングできます。これにより、JBoss ON はパフォーマンスしきい値を超えていない問題に対して(アラート経由)応答し、ログイベントとパフォーマンスメトリックを関連付けることもできます。
32.6.2. EAP 6 リソースの監視の設定
図32.20 グラフの監視
32.6.2.1. 追加メトリクスの有効化
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。その後、JBoss EAP 6 サーバーを選択し、編集するリソースに移動します。
- リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- メトリックを有効にするには、以下を実行します。
- メトリクスの行を選択します。Ctrl キーを使用して複数のメトリクスを選択できます。
- ページ下部の Enable ボタンをクリックします。
- メトリックのコレクション間隔を変更するには、以下を実行します。
- メトリクスの行を選択します。複数のメトリクスは同じ頻度に変更されていれば、Ctrl キーを使用して複数のメトリクスを選択できます。
- 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
- をクリックし Setます。
注記無効なメトリックのコレクション間隔を変更すると、メトリクスが自動的に有効になります。
32.6.2.2. 可用性監視
図32.21 EAP 6 コンソールでの可用性
- 全体のアップタイム率
- さまざまな状態(up、down、または disabled)で費やされた合計時間
- 失敗の総回数(停止時)
- 障害間の時間(基本的にはリソースが稼働中および利用可能時間)
- リカバリーの平均時間。これは障害後にリソースをバックアップするのにかかる時間です。
図32.22 JBoss ON での可用性
32.6.3. イベント監視の設定
- ホストコントローラー、
domain/log/host-controller.log
- 管理対象サーバー(
domain/servers/server-three/log/server.log
- スタンドアロンサーバーの場合
standalone/log/server.log
- トップメニューの Inventory タブをクリックします。
- Servers - Top Level Imports 項目をクリックし、JBoss EAP 6 リソースを選択します。
- 適切な EAP 6 リソースに移動します。
- リソースエントリーの Inventory タブをクリックします。
- Connection Settings サブタブを選択します。
- Events Log セクションの下にあるプラスアイコンをクリックします。
- イベントエントリーを有効にします。必要に応じて、日付の形式、文字列フィルターを設定してメッセージ、またはメッセージの重大度を追加します。
図32.23 JBoss EAP 6 イベントロギング
32.6.4. JBoss EAP 6 リソースでのアラート
- 管理者へのメール送信
- アラートリソースでの再起動操作の実行
- アラートリソースの親に対する操作の実行
- シェルスクリプトの実行
- JBoss ON サーバーサイドスクリプトの実行サーバー側のスクリプトは非常に強力なものです。スクリプトは、リソース設定の変更、更新されたパッケージのデプロイ、新規リソースの作成、既存リソースの削除、オペレーションの実行、上記のすべてなど、JBoss ON でほぼすべての管理タスクを実行できます。サーバー側のスクリプトの作成に関する詳細は、『 JBoss ON Command-Line Scripts 』の「Writing JBoss ON Command-Line Scripts」 を参照してください。
32.6.5. JBoss EAP 6 リソースでのドリフト設定監視
- トップメニューで、をクリックし Inventoryます。
- 左側の Resources メニューテーブル Servers - Top Level Imports から選択します。
- インベントリーツリーでスタンドアロンまたはホストコントローラーを選択し、設定のドリフトを監視します。
- Drift タブをクリックします。
- 下部の New ボタンをクリックします。
- ドロップダウンメニュー Template-Configuration Files から選択し、をクリックし Nextます。
- 設定オプションを入力し、Finish をクリックします。
32.7. EAP 6 での mod_cluster サービスの使用
32.7.1. mod_cluster および JBoss ON について
図32.24 mod_cluster トポロジー
standalone-ha.xml
設定で起動する必要があります。
32.7.2. ロードバランシング用のマルチキャストの設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Configuration タブをクリックします。
- Advertise Options セクションに移動します。
- マルチキャストの設定を変更します。mod_cluster ノードの特定のロードバランサーを使用するには、Balancer フィールドをロードバランサー名に設定します。任意で、Domain フィールドはロードバランサー自体に設定されたグループのいずれかです。重要Balancer および Domain 値は、対応する Apache サーバーの設定と一致する必要があります。
- ページ上部の Save ボタンをクリックします。
32.7.3. Discovery からの Web コンテキストの除外
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Configuration タブをクリックします。
- Web Context Options セクションに移動します。
- Excluded Contexts フィールドの設定を解除し、除外するコンテキストの名前を追加します。注記JBoss EAP の内部コンテキストの一部はデフォルトで除外されます。これは除外リストに保持する必要があります。除外する新しいコンテキストは、既存のリストに追加する必要があります。
- ページ上部の Save ボタンをクリックします。
32.7.4. Web コンテキストメトリクスの設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 6 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Operations タブをクリックします。
- ドロップダウンメニューから Add (Custom) Metrics 操作を選択します。
- メトリック情報を入力します。デフォルトのメトリクスは mod_cluster ドキュメント に記載されています。
- ページ下部の Schedule ボタンをクリックします。
32.8. JBoss Enterprise Application Platform 6.2 および Above のパッチ適用
32.8.1. パッチ操作
$EAP/.installation
、$EAP/.installation/.rhq
(エージェントがメタデータを保存する場所)、および EAP ディレクトリーに対する読み取りおよび書き込み権限があることを確認します。これにより、JON エージェントは EAP サーバーにパッチを当てることができます。
32.8.1.1. バンドルおよび宛先
32.8.1.2. パッチデプロイの実行
32.8.1.2.1. パッチを使用したバンドルの作成
- Bundles タブをクリックします。
- Bundle セクションの New ボタン Bundle Creation Wizard をクリックして起動します。
- 必要なパッチをアップロードします。
- 設定を更新し、Next ボタンをクリックします。
- Next ボタンをクリックします。
- Finish ボタンをクリックします。
32.8.1.2.2. 新しい宛先へのパッチデプロイの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Deploy ボタンをクリックして、バンドルのデプロイウィザードを起動します。
- 宛先情報を入力し、をクリックし Nextます。
- Deployment Bundle Version を選択し、をクリックし Nextます。
- Deployment Configuration を選択し、をクリックし Nextます。注記
- この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
- リソースグループのサーバーにパッチデプロイメントのデフォルトの場所として提供された新しい宛先を設定するには、takeOver オプションをに設定し trueます。
- Deployment Information を指定して、をクリックし Nextます。
- Finish をクリックし、バンドルを宛先にデプロイします。
32.8.1.2.3. 既存の宛先へのパッチデプロイの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Destinations サブタブをクリックします。
- バンドルをデプロイする宛先をクリックします。
- Deploy ボタンをクリックします。
- デプロイするバンドルバージョンを選択し、をクリックし Nextます。
- Deployment Configuration を選択し、をクリックし Nextます。注記この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
- 必要なデプロイメント情報を指定して、をクリックし Nextます。
- Finish をクリックし、バンドルを宛先にデプロイします。
32.8.1.3. パッチ変換の実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Summary セクションの Destinations タブをクリックします。
- 元に戻す宛先を選択します。
- odo をクリックし Revert、をクリックし Yesます。
- Next 2 回クリックし、をクリックし Finishます。
32.8.1.4. パッチパージの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Summary セクションの Destinations タブをクリックします。
- パージする宛先を選択します。
- odo をクリックし Purge、をクリックし Yesます。
第33章 JBoss EAP 7 の管理
33.1. JBoss EAP 7 の構造
33.1.1. 「classic」構造: スタンドアロンサーバー
standalone.xml
ファイルに定義されます。そのファイルのほとんどすべてのエントリーは、サーバーの子として識別されます。たとえば、以下のサブシステムエントリーは ee、サーバーの jmx 子リソースを作成します。
<subsystem xmlns="urn:jboss:domain:ee:1.1"/> <subsystem xmlns="urn:jboss:domain:jmx:1.1"> <show-model value="true"/> <remoting-connector/> </subsystem>
standalone.xml
ます。
図33.1 スタンドアロンサーバー設定
33.1.2. 設定とリアルタイム操作の分離: ドメイン
図33.2 簡易ドメイン構造
domain.xml
ファイルに定義されます。これにより、設定されたプロファイルおよびサブシステム、サーバーグループ、ソケットバインディング設定、システムプロパティー、デプロイメント、およびその他の設定がすべて一覧表示されます。スタンドアロンサーバーと同様に、ほぼすべてのエントリーが検出され、リソースとしてインベントリーに追加されます。たとえば、これにより、子デプロイメントリソースとサーバーグループの子 JVM リソースを持つサーバーグループリソースが作成されます。
例33.1 Server Group domain.xml エントリー
<server-group name="main-server-group" profile="full"> <jvm name="default"> <heap size="1303m" max-size="1303m"/> <permgen max-size="256m"/> </jvm> <socket-binding-group ref="full-sockets"/> <deployments> <deployment name="sample2.war" runtime-name="sample2.war"/> </deployments> </server-group>
host.xml
ファイルで識別されます。これらの管理サーバーは実質的には独自の設定を持ちません。ドメインで使用する元のサーバーグループ設定に戻るだけです。
<servers> <server name="server-one" group="main-server-group"/> <server name="server-two" group="other-server-group"> <!-- server-two avoids port conflicts by incrementing the ports in the default socket-group declared in the server-group --> <socket-bindings port-offset="150"/> </server> </servers>
図33.3 EAP 7 コンソール
図33.4 ドメインリソース
図33.5 JBoss ON インベントリーのドメインコンポーネント
33.1.3. JBoss ON の EAP 7 リソース
domain.xml
、host.xml
またはの EAP 7 のすべての設定エリア standalone.xml
はリソースタイプとして解釈されます。EAP 7 では設定コンポーネントと運用コンポーネントの違いがあるため、JBoss ON の EAP 7 リソースタイプは異なることを行います。また、リソースによっては設定を定義し、監視、アラート、および操作に使用されます。
33.1.4. JBoss ON を使用した EAP 7 リソースの管理の目的
- 保存した履歴データ、リソース固有の運用ベースライン、および代替の表示タイプを含む、リソースの追加の監視メトリック。
- 履歴の設定および接続設定
- JBoss ON で子を追加または削除した場合のインベントリー変更履歴
- 制御されたパッケージ更新用のパッケージバージョン管理およびリポジトリー
- プラットフォーム、Apache、Undertow Web サーバーなどの基盤のリソースおよび関連するリソースの設定、監視、アラート、およびアラート mod_cluster
33.2. JBoss EAP 6 リソースプラグインの使用
33.3. JBoss EAP 7 インスタンスの設定
33.3.1. EAP 7 インスタンスを検出するエージェントの設定
- エージェントには、ファイルの読み取り権限が必要です。さらに、
run.jar
ファイルへのパス内のすべてのディレクトリーに対して実行および検索のパーミッションが必要になりrun.jar
ます。 - RPM から JBoss EAP 7 インスタンスがインストールされている場合、エージェントユーザーは EAP インスタンスを実行する同じシステムグループに属する必要があります。これは jboss、デフォルトではです。
33.3.2. サーバーおよびプロファイルの設定
33.3.2.1. スタンドアロンサーバーおよびドメインの相違点
- サブシステム設定はドメインコントローラーの autogroup 内の Profiles プロファイルリソースにあります。
- JVM 定義は、ドメインコントローラー(ドメイン全体のデフォルト)、サーバーグループ(グループ全体の設定)、または管理対象サーバー(ローカル設定)で設定されます。
- ネットワークインターフェースはドメインコントローラーで設定されます。
- ソケットバインディング自体は、ドメインコントローラーの autogroup の下にあるエントリーでドメインコントローラー設定の一部として SocketBindings 設定されます。各サーバーグループと管理対象サーバーにはオフセットがあり、ソケットバインディング値に追加されます。これは、管理対象ドメインで一意のポート番号を提供するために使用される番号です。これらのオフセットはサーバーグループと管理対象サーバーの接続設定で設定されます。
- システムプロパティーは、ほぼすべてのサーバーリソース(ドメインコントローラー、ホストコントローラー、サーバーグループ、管理対象サーバー)で設定できます。
33.3.2.2. EAP 7 で必要な管理インターフェース
/host=instanceName/core-service=management/management-interface=http-interface:add(interface=http,port="\${jboss.management.http.port:9990}",security-realm=ManagementRealm
33.3.2.3. JBoss ON の設定機能
- バージョン間の diffs を含む変更履歴の表示
- ボタンをクリックして、以前のバージョンへの変更をロールバックします。
- 監査証跡の一部として変更を行ったユーザーを追跡
- アラートを使用して、設定変更の管理者に通知します。
- ドリフト監視を定義して、定義したベースラインに対して設定の変更を追跡し、予期しない設定変更を制御する
33.3.3. Setup CLI 操作を使用した JBoss ON と EAP 7 間の SSL 認証
jboss-cli.sh
または jboss-cli.bat
)への JBoss ON GUI アクセスが可能になります。この操作は JBoss ON と EAP 間 Execute CLI script で <EAP_install_directory>/bin/jboss-cli.xml
公開鍵を更新し、JBoss ON GUI からの Execute CLI commands /からの操作を可能にします。
- この操作は 任意です。jboss-cli は、EAP 7 のドキュメントを使用して手動で設定できます。「レガシーコア管理 認証のある管理インターフェースに対して双方向 SSL/TLS を設定 」を参照してください。Setup CLI 操作を使用するには、JBoss ON エージェントには EAP ファイルおよびディレクトリーへの読み取りおよび書き込み権限が必要です。これ Setup CLI は、JBoss ON 3.3 向けに Enterprise Application Platform(EAP)Management Plug-in Pack Update-03 によって導入されました。
表33.1 Setup CLI 操作から利用できるプロパティー
property | description |
---|---|
デフォルトコントローラー | JBoss ON コントローラーホストおよびポートを EAP 7 の JBoss CLI のデフォルトとして設定します。 |
security | EAP 7 にセキュアな管理インターフェースがある場合、このオプションは Store Password Method を基にして JBoss ON と EAP との間で認証を設定します。これにより、JBoss ON は EAP 7 JBoss CLI を実行できるようになります。 |
ストアパスワードメソッド | セキュリティーを設定する際に、パスワードを jboss-cli.xml に保存するメソッドを設定します。
|
手順33.1 Setup CLI 操作の使用
- JBoss ON CLI で Inventory タブをクリックします。
- Resources メニューからをクリックし Servers、設定する EAP サーバーを選択します。
- EAP サーバーリソースページから、Operations タブをクリックします。
- New をクリックし、新しい操作をスケジュールします。
- Operation ドロップダウンリストから、以下に示すように Setup CLIを選択します。
図33.6 Setup CLI 操作の例
- 必要なプロパティーを変更するには、Unset? チェックボックスをクリアし、該当するをクリックし Valueます。
- Schedule をクリックし、操作を保存します。このページは Operations History タブにリダイレクトします。
- Setup CLI 操作が実行され、ステータスが success を示す場合、以下のように Setup CLI 操作の Date Submitted エントリーをクリックして、操作の結果を表示し、変更が正常に行われたことを確認し ます。
図33.7 Setup CLI 操作の結果の例
33.3.4. 管理ユーザーの作成
- LDAP ディレクトリーまたは外部データストアの使用これは EAP 7 の最もセキュアな実装であるため、推奨されます。
- JBoss ON を使用して管理ユーザーを作成します。
- EAP add-user スクリプトでローカル EAP アカウントを作成する。
33.3.4.1. 管理ユーザーの認証情報の設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Inventory タブを開きます。
- Connection Settings サブタブを選択します。
- EAP 7 で作成した管理ユーザーのユーザー名とパスワードを入力します。
- ページ上部の Save ボタンをクリックします。
33.3.4.2. JBoss ON での管理ユーザーの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Install RHQ User オプションを選択します。
- Schedule ボタンをクリックします。
33.3.4.3. EAP 7 での管理ユーザーの作成
- add-user ユーティリティーを実行してユーザーを作成します。
[root@server ~]# cd /opt/jboss-eap-7.0 [root@server bin]# ./add-user.sh What type of user do you wish to add? a) Management User (mgmt-users.properties) b) Application User (application-users.properties) (a): a Enter the details of the new user to add. Realm (ManagementRealm) : Username : jonadmin Password : Re-enter Password : About to add user 'jonadmin' for realm 'ManagementRealm' Is this correct yes/no? yes
- JBoss ON の EAP 7 サーバーリソースの接続設定でそのユーザーを設定します。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。スタンドアロンサーバーまたはドメインコントローラーのいずれかで JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Inventory タブを開きます。
- Connection Settings サブタブを選択します。
- EAP 7 で作成した管理ユーザーのユーザー名とパスワードを入力します。
- ページ上部の Save ボタンをクリックします。
33.3.5. EAP 7 リソースの動的グループの作成
- トップメニューの Inventory タブをクリックします。
- 左側の Groups エリアで、Dynagroup Definitions リンクをクリックします。
- EAP 7 のサーバータイプごとに互換性のあるグループを作成する式を入力します。
resource.type.plugin = EAP7 resource.type.category = SERVER resource.parent.type.category = PLATFORM groupby resource.pluginConfiguration[productType] groupby resource.type.name
- ページの中央にある Save ボタンをクリックします。
33.3.6. 起動スクリプト引数、環境変数、および JAVA_OPTS の設定
33.3.6.1. スクリプト検出と設定の開始
- 検出プロセスは、カスタム開始スクリプトを含む、使用される開始スクリプトを特定または試行します。
- Discovery は、開始スクリプトが機能するために必要な
run.conf
ファイルまたは親プロセスに設定された環境変数のサブセットを検出します。注記検出プロセスで一部の環境変数が検出されますが 、検出スキャンは JAVA_OPTS 値を検出しません。開始スクリプトの接続プロパティーは意図的に JAVA_OPTS 値のためにrun.conf
ファイルに移されます。 - 検出は、開始スクリプト自体で渡された引数の検出を試みます。
- Discovery は、スクリプトが実行しているユーザーを検出し、start スクリプトで使用する 接頭辞 コマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。
-XX:PermSize=256M
)で検出されると、サーバーが別の設定値で後で再起動すると、引数の値は更新されません。
33.3.6.2. スクリプト引数およびドリフト監視の開始
例33.2 ドリフト定義を自動化せずにシステムプロパティー
33.3.6.3. 起動スクリプト設定の変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- Operations エリアを展開します。
- 開始スクリプトの設定を変更または追加します。これらは、EAP 7 サーバーで起動または再起動の操作を実行する際に JBoss ON エージェントが使用するスクリプトおよび設定です。
domain.sh
または以外のカスタムの開始スクリプトを使用するにはstandalone.sh
、パスとスクリプト名を入力します。- 必要に応じて、開始スクリプトの実行時にスクリプトで使用する接頭辞を入力します。起動スクリプトが検出されると、エージェントはスクリプトが実行されているユーザーを判断しようとし、start スクリプトで使用するプレフィックスコマンドを割り当てます。たとえば、起動スクリプトが jboss ユーザーとして実行され、JBoss ON エージェントがそのまま実行している場合 jonagent、検出スクリプトは自動的に sudo コマンドを割り当て sudo -u jboss -g jboss、起動スクリプトで渡します。さらに、JBoss ON は nohup コマンドをプレフィックスとして割り当て、JBoss Enterprise Application Platform がエージェントによって開始され、エージェントプロセスが終了すると、JBoss Enterprise Application Platform プロセスが実行を継続します。
- 各行に 1 つずつ環境変数を設定します。
- スクリプト引数を設定します(行ごとに 1 つ)。通常の JAVA_OPTS の場合、これらの引数は通常
-X
-D
、またはです-P
。便利な-XX
引数の一部は、Sun の JVM オプションのドキュメントに記載されています。EAP 7 の便利なシステムプロパティーの一部は、WildFly 10 プロジェクトのドキュメント に記載されています。EAP 7 のデフォルト起動スクリプトは - 形式のrun.sh
スクリプトを使用するため、引数はその形式を使用します。カスタムスクリプトは、異なる引数またはオプションを使用できます。
- ページ上部の Save ボタンをクリックします。
33.3.6.4. スタンドアロンモードでの JVM ヒープ引数の変更
standalone.conf
か standalone.bat
(OS によって異なります)。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルを選択し、右側の表から該当する EAP 7 スタンドアロンサーバーをクリックします。
- JBoss Enterprise Application Platform Server の詳細で、Inventory タブをクリックします。
- Connection Settings サブタブをクリックします。
- テーブルの Operations セクションの Additional JAVA_OPTS 行までスクロールします。
- 引数を追加するには、「Unset?」チェックボックスの選択を解除し、テキストボックスに引数を追加します。注記"Unset" チェックボックスは、設定が JBoss ON Server から使用されているかどうかのみ決定します。「未設定」チェックが解除されると、テキストボックスの値が使用されます。"Unset" がチェックされると、テキストボックスの値は使用されません。「 Unset?」チェックを実行しても、設定ファイルが JAVA_OPTS を設定しないことを意味します。これは単に値が JBoss ON を介して設定されていないことを意味します。
- 「 Save」をクリックします。
- この更新を反映するには、JBoss Enterprise Application Platform 7 サーバーを再起動する必要があります。
33.3.7. ポート番号の変更
33.3.7.1. ソケットバインディングポートの変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで SocketBindingsGroup 互換性のあるグループを選択し、編集するソケットバインディングを選択します。
- Configuration タブを開きます。
- 鉛筆アイコンをクリックして既存のソケット定義を編集するか、プラス記号(+)をクリックして新しいソケット定義を作成します。
- 1025 から 65535 までの利用可能なポートに Port 番号を変更します。Linux では、利用可能なポート番号はを使用して決定でき iptablesます。オプションで、ソケットのマルチキャスト設定を行います。同じシステムまたは同じクラスターに複数の JBoss サーバーインスタンスがある場合、マルチキャストはクラスター通信用に設定されます。
- ページ上部の Save ボタンをクリックします。
33.3.7.2. ドメインのサーバーグループのポートオフセットの変更
host.xml
ファイルのエントリーで定義されます。これは、JBoss ON で管理サーバーの作成時に設定できますが、後で編集することはできません。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで Server Groups ノードを展開し、サーバーグループを選択します。
- サーバーグループの Configuration タブを開きます。
- Port Offset フィールドにオフセットの新しい値を入力します。
- ページ Save 上部をクリックします。
33.3.8. ネットワークインターフェースの編集
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで Server Configuration で Network Interfaces グループを選択し、インターフェース(management、public、または unsecure)を選択します。
- Configuration タブを開きます。
- インターフェースで使用する特定の IP アドレスを設定するか、アドレスの使用を 許可 します。UI では、使用するプロパティーが任意で、この画面で選択が行われていることを強制しません。ただし、ネットワークインターフェースが適切に機能するには、以下のいずれかのオプションを設定する必要があります。
- ページ上部の Save ボタンをクリックします。
33.3.9. システムプロパティーの設定
domain.xml
ファイルのコンポーネントのエントリーに追加されます。ホストコントローラーまたは管理対象サーバーを編集すると、プロパティーが host.xml
ファイルのサーバーのエントリーに追加されます。
-D
または -P
引数で start スクリプトで上書きできます。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開きます。
- Properties セクションを展開します。
- Paths リストの下部にあるプラス(+)アイコンをクリックします。
- 新しいプロパティー情報を入力します。
- システムプロパティー名。
- プロパティーの値。
- プロパティーを稼働中の JVM に即座にロードする必要がある場合や、JVM の起動時にロードする必要がある場合。デフォルトでは、即座に読み込むことができます。
- をクリックし OKます。
33.3.10. システムパスの追加
jboss.*
user.*
、およびで始まり java.*
ます。
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Configuration タブを開きます。
- Paths セクションを展開します。
- Paths リストの下部にあるプラス(+)アイコンをクリックします。
- パス情報を入力します。
- 作成するパスの名前。
- 作成するパス(絶対または相対パス)。
- 相対パスが Path 値として指定された場合は、Relative フィールドの Unset? チェックボックスの選択を解除し、相対パスの 名前 を入力します。
- プロパティーが読み取り専用である場合。読み取り専用プロパティーの作成後は編集 できません。読み取り専用パス(デフォルトのパスから)を削除し、変更する必要がある場合には再作成する必要があります。
- をクリックし OKます。
33.3.11. 接続設定の編集
33.3.11.1. EAP 7 サーバーの一般的なプロパティーの変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- サーバー接続プロパティーは General Properties セクションにあります。プロパティーの一部のみを編集できます。ホームディレクトリー、ベースディレクトリー、サーバータイプ(EAP または AS)などの JBoss EAP 7 インストール自体から派生した情報が表示されますが、非アクティブになります。
- Hostname サーバーへの接続に使用する IP アドレスを指定します。通常 127.0.0.1 ですが、管理インターフェース設定が変更された場合、IP アドレスは localhost ではなくパブリック IP になります。
- Port は管理インターフェースのポートです。
- Secure SSL を使用して JBoss Enterprise Application Platform 6 管理インターフェースと通信するかどうかを示します。JBoss ON エージェントが JBoss Enterprise Application Platform 7 スタンドアロンサーバーまたはホストコントローラーの HTTP 管理インターフェースが SSL を使用することを検出すると、検出中に true に設定されます。
- Username および Password は、エージェントがログインに使用する JBoss EAP 7 ユーザーのクレデンシャルです。このユーザーが、インストール RHQ ユーザー操作 を使用して作成されている場合、ユーザーはになり rhqadminます。
- ドメインコントローラーのみ。スタンドアロンサーバーでは、設定とサーバーインスタンスの定義はすべて同じファイル
standalone.xml
か、起動スクリプトに渡されるその他の設定ファイルにあります。ドメインの場合、サーバー設定は 1 つのファイル(ドメインコントローラー用)で定義されますが、サーバーインスタンスは別のファイル(ホストコントローラー用)で定義されます。Domain Configuration および Host Configuration フィールドには、プロファイル設定、および管理対象サーバーインスタンスを参照するdomain/configuration/
ディレクトリー内のファイルの名前がそれぞれ示されます。
- ページ上部の Save ボタンをクリックします。
33.3.11.2. JBoss Enterprise Application Platform 7 サーバーのセキュア接続設定の変更
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Inventory タブを開き、Connection Settings サブタブを選択します。
- セキュアな接続設定は Secure Connections Settings セクションにあります。
- セキュアな接続設定を適切な情報で構成し、をクリックし Saveます。
- JBoss ON は、次の可用性スキャンの後にこれらの設定の使用を開始します。
33.3.11.3. EAP 7 トピックリソースのインストールパスの表示
domain.xml
ファイルに含まれます。
<server-groups> <server-group name="main-server-group" profile="full"> ...
図33.8 子リソース接続設定
33.3.12. インストール済み拡張の表示
domain.xml
または standalone.xml
)で定義されるモジュールのクラスです。
<extensions> <extension module="org.jboss.as.clustering.infinispan"/> <extension module="org.jboss.as.clustering.jgroups"/> <extension module="org.jboss.as.cmp"/> <extension module="org.jboss.as.configadmin"/> <extension module="org.jboss.as.connector"/> <extension module="org.jboss.as.ee"/> <extension module="org.jboss.as.ejb3"/> ...
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Configuration タブを開きます。
- Installed extensions セクションを展開します。
33.3.13. サーバー設定の再読み込み
図33.9 設定メッセージのリロード
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- インベントリーツリーで、EAP 7 サーバーのリソースエントリーを選択します。
- Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Reload オプションを選択します。
- Schedule ボタンをクリックします。
33.3.14. 設定項目の制御
- やなどの重要な設定ディレクトリーを追跡するドリフト定義を設定
domain/configuration/
しますがstandalone/configuration/
、ロギング、ライブラリー、データディレクトリーなど、常にデータが変更されるディレクトリーは除外されるようにします。設定ディレクトリー内でも、、、host_xml_history/
domain_xml_history/
、およびディレクトリーの除外ルールを作成します。これらは適切な設定ファイルではなくstandalone_xml_history/
、追跡すべきではありません。 - 必要な設定が配置されたら、その 設定 をドリフト定義に固定します。これにより、希望の設定がベースラインとして設定されます。すべての変更は、そのベースラインと比較されます。
- 設定ファイル設定のアーカイブを作成します。
- EAP 7 設定をリセットし、ドリフトを修正するために自動的にデプロイできるバンドル定義を作成します。宛先の作成時には、EAP 7 リソースのプラットフォームである必要があります。宛先はスタンドアロンサーバーまたはドメインコントローラーのいずれかですが、プラットフォームを使用すると、バンドルを期限切れのディレクトリーにデプロイしてから
/tmp/mybundles/holding
、インストール後のタスクを実行して設定ファイルを configuration ディレクトリーにコピーします。通常、バンドルをデプロイすると、ターゲットディレクトリーにある既存ファイルがすべて削除され、バンドルに置き換えられます。この動作を制御する方法はありますが、通常はバンドルの内容が最終デプロイメントの目的と完全に一致するのは安全です。バンドルに設定ディレクトリー全体を含めることができないため、ファイルシステム上の別の場所にデプロイすると設定ディレクトリーが保持され、重要な設定ファイルのみが Ant タスクによってコピーされます。バンドルの詳細やドリフトの調整は、「 JBoss ON Command-Line Scripts」の「 27章バンドルへのコンテンツおよびアプリケーションのデプロイ drift-bundle CLI サンプルスクリプト」を参照してください。 - 2 つのことを行う設定のドリフトに関するアラートを設定します。
- 管理者に通知メールを送信します。
- バンドルを自動的にデプロイするプラットフォームで CLI スクリプトを実行します。
25章アラートの定義 JBoss ON サーバーサイドスクリプトを起動するアラート通知を設定する方法や、別のリソースで操作を実行する方法についての情報があります。
domain.xml
および変更を行い standalone.xml
ます。これにより、アラートが設定されている場合にドリフトアラートがトリガーされます。
33.3.15. 設定変更の追跡および取り消し
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 サーバーを選択します。
- インベントリーツリーで、サーバーの上位のリソースエントリーを選択します。
- Configuration タブを開き、History サブタブを選択します。注記変更履歴ページは、リソース設定( Configuration タブ)および接続設定( Inventory > Connection Settings タブ)に対して保持されます。
- ID 番号の変更をクリックすると、その バージョン に適用された構成設定が開きます。
- 変更内容は、一覧から選択して Compare ボタンをクリックして、標準の diff 形式の変更を比較できます。
- 現在、ライブバージョンの設定は、一覧で目的の 以前 のバージョンを選択して Rollback ボタンをクリックすることで、以前のバージョンに戻すことができます。
33.4. JBoss EAP 7 リソースの作成
33.4.1. 履歴の追跡
図33.10 子履歴
33.4.2. サーバーグループの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- EAP 7 サーバーのリソースエントリーを選択します。
- 左側のメニューの EAP7 Host Controllers セクションを展開します。
- ドメインコントローラーエントリーを右クリックします。
- Create Child メニューで、の項目を選択し Server Groupます。
- 新しいサーバーグループの名前を入力します。
- サーバーグループの設定: 使用するプロファイル、使用するソケットバインディンググループ、および設定するシステムプロパティーを入力します。
- をクリックし Finishます。
33.4.3. 管理対象サーバーの作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- EAP 7 サーバーのリソースエントリーを選択します。
- 左側のメニューの EAP7 Host Controllers セクションを展開します。
- ドメインコントローラーエントリーを右クリックします。
- Create Child メニューで、の項目を選択し Managed Serverます。
- 新しいサーバーの名前を入力します。
- サーバーの設定を入力します。
- サーバーを作成する EAP 6 ドメインホスト。
- サーバーを追加するサーバーグループ。
- 使用するソケットバインディンググループ。これにより、使用するサーバーインスタンスのベースポート番号が指定されます。
- ポートオフセット。これは、ソケットバインディング設定に追加して、サーバーインスタンスの実際のポート番号を判断する番号です。ソケットバインディングポートが 1000 で、オフセットが 150 の場合は、管理対象サーバーのそのインターフェースに使用されるポート番号は 1150 になります。
- EAP 6 ホストの起動時にサーバーが自動的に起動するかどうか。
- サーバーのシステムプロパティー。
- をクリックし Finishます。
33.4.4. JVM 定義の変更
33.4.4.1. リソースとしての JVM 定義
33.4.4.2. JVM 定義の作成
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- JVM 定義を追加するエントリーを右クリックします。
- Create New メニューで、の項目を選択し JVM Definitionます。
- 定義の名前を入力します。注記JVM 定義の名前はホストコントローラーの任意の名前になります。管理対象サーバーまたはサーバーグループでは、JVM 定義の名前は、定義のベースであるホストコントローラーの JVM 定義と同じである必要があります。
- JVM の設定を入力します。空白のままにすると、親 JVM 定義で定義された値が使用されます。JVM の設定の大半は、メモリーとリソースの使用状況に関連するもので、環境変数やその他の設定を JVM に渡すオプションに関連します。この設定の値は、リソースのパフォーマンスとシステム全体のパフォーマンスの両方に悪影響を及ぼす可能性があります。設定がに記載されてい 表33.2「JVM 定義プロパティー」 ます。
- をクリックし Finishます。
表33.2 JVM 定義プロパティー
property | description |
---|---|
JVM オプション | 他の Java オプションを設定します。これらのほとんどは、Sun のドキュメントなど Java プロバイダーで文書化されてい http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html ます。 |
環境変数 | JVM で使用する環境変数を設定します。 |
ヒープサイズ | JVM の初期ヒープサイズを設定します。 |
最大ヒープサイズ | JVM の最大許容ヒープサイズを設定します。これを設定しすぎると、メモリー不足のエラーが発生する可能性があります。 |
Permgen Size | 永続生成の初期サイズを設定します。 |
最大 Permgen サイズ | 永続生成の最大サイズを設定します。 |
type | JVM のタイプ。これは、JBoss ON でサポートされる Java タイプである Sun または IBM です。 |
33.4.4.3. JVM 定義の編集
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。
- EAP サーバーを選択し、適切な JVM 定義エントリーに移動します。
- Configuration タブを開きます。
- JVM 設定のいずれかを変更します。これらはに記載されてい 「JVM 定義の作成」 ます。
- ページ上部の Save ボタンをクリックします。
33.4.5. Parent-Child リソースの短いリスト
表33.3 Parent-Child リソースの短いリスト
resource | 子リソースタイプ |
---|---|
スタンドアロンサーバー |
|
ドメインコントローラー |
|
host |
|
サーバーグループ |
|
データソース(プロファイル下) |
|
Infinispan > Hibernate |
|
logging |
|
Undertow |
|
33.5. Web アプリケーションのデプロイ
33.5.1. ランタイム情報およびデプロイメントリソース
33.5.1.1. デプロイメントの表示
図33.11 ランタイムページでのデプロイメント
- Web アプリケーションは、個別のエンティティーとして、内およびそれ自体として扱われます。インベントリーには独自の場所があり、ドメインおよびサーバーグループとの関連性は、それらのリソースの子であるため反映されます。JBoss ON は、ファイルサイズや特定 SHA256 ハッシュなどのパッケージの詳細も記録します。
- Web アプリケーションには履歴があります。パッケージの更新が changelog に記録されるため、アプリケーションの維持方法を追跡できます。
- Web アプリケーションは監視できます。応答時間メトリックは、特に基盤のサーバーのパフォーマンスやモニタリング以外に、Web アプリケーションのパフォーマンスを追跡します。
図33.12 JBoss ON の Deployment Resource Details
- パッチおよび更新を格納するコンテンツリポジトリーの作成
- 複数バージョンのコンテンツの追跡
- ソフトウェアパッケージを以前のバージョンに戻す(特にスタンドアロンサーバーの場合)
- 複数のドメインおよびスタンドアロンサーバーを含む、複数の EAP インスタンスに同じコンテンツリポジトリーを使用
- コンテンツの変更の追跡(および監査)
33.5.1.2. スタンドアロンサーバーおよびドメインのデプロイメントパス
- 子リソースとしてデプロイメントを作成します。
- バンドルを使用してデプロイメントディレクトリーにアプリケーションをプロビジョニングします。
33.5.2. ドメインへの Web アプリケーションのデプロイメント
33.5.2.1. ドメインへの Web アプリケーションを帰リソースとしてデプロイ
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 ドメインコントローラーを選択します。
- ドメインコントローラーエントリーを右クリックします。
- Create New メニューで、の項目を選択し DomainDeploymentます。
- バージョン番号を入力します。
- EAR、WAR、または JAR ファイルをアップロードします。
- オプションで、デプロイメントのランタイム名を入力します。
- ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。注記タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
- をクリックし Finishます。
図33.13 ドメインデプロイメントディレクトリー
33.5.2.2. バンドルを介したドメインへの Web アプリケーションのデプロイ
<project name="handover-test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle"> <rhq:bundle name="example.com (EAP 7)" version="1.0" description="example.com corporate website hosted on EAP 7"> <rhq:input-property name="myapp.runtime.name" defaultValue="website.war" required="true"/> <rhq:input-property name="myapp.serverGroup.name" defaultValue="main-server-group-01" required="true"/> <rhq:deployment-unit name="example.com deployment unit" compliance="filesAndDirectories"> <rhq:file name="prepareDatasource.cli" replace="true"> <rhq:handover action="execute-script"/> </rhq:file> <rhq:archive name="website.war"> <rhq:handover action="deployment"> <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/> <rhq:handover-param name="serverGroup" value="${myapp.serverGroup.name}"/> </rhq:handover> </rhq:archive> </rhq:deployment-unit> </rhq:bundle> <target name="main"/> </project>
- トップメニューで、Bundles タブをクリックします。
- Bundle セクションの New ボタンをクリックします。
- を選択 Upload し Choose てクリックし、目的のディストリビューションファイルに移動して選択します。
- をクリックし Nextます。
- 必要なバンドルグループを選択し、をクリックし Nextます。
- をクリックし Finishた後 Next、をクリックします。
- 新たにアップロードしたバンドルの Bundle セクションをクリックします。
- バンドルの詳細の Deploy ボタンをクリックします。
- 宛先情報を入力し、ウィザードに進みます。
33.5.3. サーバーグループへの Web アプリケーションの割り当て
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 ドメインコントローラーを選択します。
- DomainDeployments フォルダーを展開します。デプロイメントフォルダーにすべての Web アプリケーションをデプロイするには、デプロイメントフォルダー自体を選択して操作を実行します。単一の Web アプリケーションをデプロイするには、特定の Web アプリケーションを選択します。
- サーバーの Operations タブを開きます。
- ページ下部の New ボタンをクリックします。
- ドロップダウンメニューから Assign to Server-Group オプションを選択します。
- アプリケーションをデプロイするグループ(またはすべてのグループ)を選択します。
- 操作の実行時やタイムアウト期間のスケジュールなど、操作の標準情報を入力します。注記タイムアウト期間は、操作がタイムアウトして失敗したことを想定するまでのサーバーが待機する時間を設定します。これは、操作の実行に失敗したり、停止したりすることを意味するわけではありません。
- 複数の Web アプリケーションをデプロイしている場合は、パッケージがデプロイされる順序を設定する方法に Execute ラジオボタンを設定します。すべてのパッケージは一度にデプロイすることも、特定の順序でデプロイすることもできます。
- Schedule ボタンをクリックします。
- 必要に応じて、エージェントで検出スキャンを実行して、新しいコンテンツリソースを検出します。デフォルトでは、サービスの検出スキャンは 24 時間ごとに実行されるため、新規コンテンツの検出に時間がかかる可能性があります。
- UI でエージェントエントリーを開きます。
- Operations タブを開き、execute prompt command 操作を選択します。
- discovery コマンドを操作引数として入力します。これで検出スキャンが実行されます。
- Schedule ボタンをクリックします。
33.5.4. 拡張例: Web アプリケーションの割り当てと更新の管理
設定
Tim the IT Guy は、開発からステージングおよび実稼働環境まで、Web アプリケーションの進捗を明確にしたいと考えています。EAP 7 のネイティブ構造では、異なるサーバーグループを作成し、各ステージでテストを渡すため、中央ドメインコントローラーから適切なサーバーグループにコンテンツをデプロイできます。
The Plan
- Tim は、まず維持する必要のあるサーバーグループの概要を示します。シンプルな環境では、3 つのグループ(testing、staging、および production)が必要です。
- 2 つのコンテンツリポジトリーを作成します。1 つはパッチ用で、もう 1 つは Web アプリケーションの新しいバージョン用です。
- ドメインデプロイメントを作成し、web アプリケーションを testing サーバーグループにプロモートします。
- Tim は、Web アプリケーションの応答時間監視を設定します。テストエリアで必要なパフォーマンスパラメーターを満たすと、Tim はデプロイメントをステージング環境にプロモートし、次に実稼働サーバーグループにプロモートします。
結果
各デプロイメントのパッケージ履歴により、Web アプリケーションがデプロイされた時点、バージョン、およびそのコンテンツを追跡できます。
33.5.5. ドメインサーバーグループでの Web アプリケーションの有効化および無効化
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 ドメインコントローラーを選択します。
- インベントリーツリーでフォルダーを展開し、web アプリケーションを選択 DomainDeployments して一覧から有効または無効にします。
- Web アプリケーションの Configuration タブを開きます。
- Assigned to セクションで、Web アプリを有効または無効にするサーバーグループに対応する Server Group 行の青の鉛筆をクリックします。
- Enabled 行で Yes または No を選択し、OK をクリックします。
- Save ボタンをクリックします。
33.5.6. デプロイメントコンテンツの更新
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 7 サーバーを選択します。
- DomainDeployments フォルダーを開きます(スタンドアロンサーバーでは Deployment フォルダーを使用)、更新する Web アプリケーションを選択します。
- Web アプリケーションの詳細ページで Content タブを開き、New サブタブをクリックします。
- UPLOAD NEW PACKAGE ボタンをクリックします。
- UPLOAD FILE ボタンをクリックします。
- ポップアップウィンドウで Add ボタンをクリックし、ローカルファイルシステムをアップロードする更新されたコンテンツファイルを参照します。
- UPLOAD ボタンをクリックします。
- Web アプリケーションパッケージを保存するリポジトリーを選択します。これは不要ですが、更新されたパッケージを JBoss ON に保存して、他の JBoss EAP 7 デプロイメントで使用できるようにすることが推奨されます。
- バージョン情報を入力します。
- 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
図33.14 リソースのデプロイメント履歴
33.5.7. Web アプリケーションのスタンドアロンサーバーへのデプロイ
33.5.7.1. Web アプリケーションの クライアントリソースとしてのデプロイ
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 7 スタンドアロンサーバーを選択します。
- ナビゲーションツリーのスタンドアロンサーバーエントリーを右クリックします。
- Create New メニューで、の項目を選択し Deploymentます。
- バージョン番号を入力します。
- EAR、WAR、または JAR ファイルをアップロードします。
- オプションで、デプロイメントのランタイム名を入力します。
- ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。注記タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
- をクリックし Finishます。
33.5.7.2. バンドルへの Web アプリケーションのデプロイ
- トップメニューで、Bundles タブをクリックします。
- ディストリビューションファイルをアップロードし、デプロイメントウィザードにアクセスしてバンドルバージョンを作成します。
- ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
- デプロイするバンドルを選択します。
- JBoss スタンドアロンサーバーの宛先情報を定義します。宛先は、互換性のあるグループ(JBoss リソースを含む)とバンドルをデプロイするディレクトリーの組み合わせです。
- デプロイメントウィザードを完了し、必要なプロパティーを設定します。
33.5.8. コンテンツ履歴の追跡および変更の取り消し
図33.15 リソースのデプロイメント履歴
- ドメインデプロイメントまたはサーバーグループのデプロイメントがコンテンツリポジトリーに関連付けられている場合は、更新されたパッケージをコンテンツリポジトリーにアップロードし、変更を関連するリソースに同期します。
- 更新されたパッケージをドメインデプロイメントにアップロードし、deploy を使用して操作をグループ 化して、更新されたパッケージをサーバーグループに送信します。
33.5.9. バージョン管理されたデプロイメントおよびサブデプロイメント
^(.*?)-([0-9]+\\.[0-9].*)(\\..*)$
33.5.9.1. 既存のリソース
33.5.10. デプロイメントのトラブルシューティング
- 問: デプロイメントでは失敗と示唆されますが、パッケージの再デプロイを試みると、リソースがすでに存在することを示すため、失敗します。
- 問: サーバーグループにパッケージをデプロイしようとしましたが、デプロイメントが一覧に表示されません。
- エージェント検出スキャンが実行されていません。検出の実行には数時間かかる可能性があるため、アプリケーションが検出キューに表示されるまで時間がかかる場合があります。これを回避するには、エージェントで検出スキャンを実行します。
- パッケージが ドメイン にすでにデプロイされている。サーバーグループでデプロイメント子を作成すると、実際に(コンテンツが保存される)ドメインにデプロイメントを作成し、そのデプロイメントをサーバーグループにデプロイします。パッケージがドメインにすでに存在する場合は、サーバーグループでデプロイメントを複製として再度作成しようとすると失敗します。この場合は、デプロイを使用してドメインコントローラーでサーバーグループ 操作を行い、アプリケーションをデプロイします。
33.6. JBoss EAP 7 リソースの監視
33.6.1. ランタイム情報および JBoss ON Monitoring
- 各メトリクスの時間ベースのモニタリンググラフ
- リソースの実際のパフォーマンス で計算された操作パラメーター、またはベースライン
- 稼働時間の割合、復旧時間、およびダウンタイムの平均
図33.16 単一のメトリックの JBoss オンベースライン
- リソースにはより多くのメトリクスを使用できます。少なくとも、すべてのリソースには可用性監視があります。データソースや管理サーバーなどの一部のリソースには、ルーチン監視で有効にできる多くのメトリクスがあります。
- 応答時間監視は、Web アプリケーションの特定の URL およびページに対して設定できます。これにより、管理者は、Web アプリケーションのユーザビリティーやカスタマーエクスペリエンスを、接続数などの内部メトリクスと共に追跡できます。
- イベントログ監視は、異なるエラーログからの重要なメッセージをフィルタリングできます。これにより、JBoss ON はパフォーマンスしきい値を超えていない問題に対して(アラート経由)応答し、ログイベントとパフォーマンスメトリックを関連付けることもできます。
33.6.2. EAP 7 リソースの監視の設定
図33.17 グラフの監視
33.6.2.1. 追加メトリクスの有効化
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。その後、JBoss EAP 7 サーバーを選択し、編集するリソースに移動します。
- リソースエントリーの Monitoring タブをクリックします。
- Schedules サブタブをクリックします。
- メトリックを有効にするには、以下を実行します。
- メトリクスの行を選択します。Ctrl キーを使用して複数のメトリクスを選択できます。
- ページ下部の Enable ボタンをクリックします。
- メトリックのコレクション間隔を変更するには、以下を実行します。
- メトリクスの行を選択します。複数のメトリクスは同じ頻度に変更されていれば、Ctrl キーを使用して複数のメトリクスを選択できます。
- 適切な時間単位(秒、分、時間)で、目的のコレクション期間を Collection Interval フィールドに入力します。
- をクリックし Setます。
注記無効なメトリックのコレクション間隔を変更すると、メトリクスが自動的に有効になります。
33.6.2.2. 可用性監視
- 全体のアップタイム率
- さまざまな状態(up、down、または disabled)で費やされた合計時間
- 失敗の総回数(停止時)
- 障害間の時間(基本的にはリソースが稼働中および利用可能時間)
- リカバリーの平均時間。これは障害後にリソースをバックアップするのにかかる時間です。
図33.18 JBoss ON での可用性
33.6.3. イベント監視の設定
- ホストコントローラー、
domain/log/host-controller.log
- 管理対象サーバー(
domain/servers/server-three/log/server.log
- スタンドアロンサーバーの場合
standalone/log/server.log
- トップメニューの Inventory タブをクリックします。
- Servers - Top Level Imports 項目をクリックし、JBoss EAP 7 リソースを選択します。
- 適切な EAP 7 リソースに移動します。
- リソースエントリーの Inventory タブをクリックします。
- Connection Settings サブタブを選択します。
- Events Log セクションの下にあるプラスアイコンをクリックします。
- イベントエントリーを有効にします。必要に応じて、日付の形式、文字列フィルターを設定してメッセージ、またはメッセージの重大度を追加します。
33.6.4. JBoss EAP 7 リソースでのアラート
- 管理者へのメール送信
- アラートリソースでの再起動操作の実行
- アラートリソースの親に対する操作の実行
- シェルスクリプトの実行
- JBoss ON サーバーサイドスクリプトの実行サーバー側のスクリプトは非常に強力なものです。スクリプトは、リソース設定の変更、更新されたパッケージのデプロイ、新規リソースの作成、既存リソースの削除、オペレーションの実行、上記のすべてなど、JBoss ON でほぼすべての管理タスクを実行できます。サーバー側のスクリプトの作成に関する詳細は、『 JBoss ON Command-Line Scripts 』の「Writing JBoss ON Command-Line Scripts」 を参照してください。
33.6.5. JBoss EAP 7 リソースでのドリフト設定の監視
- トップメニューで、をクリックし Inventoryます。
- 左側の Resources メニューテーブル Servers - Top Level Imports から選択します。
- インベントリーツリーでスタンドアロンまたはホストコントローラーを選択し、設定のドリフトを監視します。
- Drift タブをクリックします。
- 下部の New ボタンをクリックします。
- ドロップダウンメニュー Template-Configuration Files から選択し、をクリックし Nextます。
- 設定オプションを入力し、Finish をクリックします。
33.7. EAP 7 での mod_cluster サービスの使用
33.7.1. mod_cluster および JBoss ON について
図33.19 mod_cluster トポロジー
standalone-ha.xml
設定で起動する必要があります。
33.7.2. ロードバランシング用のマルチキャストの設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Configuration タブをクリックします。
- Advertise Options セクションに移動します。
- マルチキャストの設定を変更します。mod_cluster ノードの特定のロードバランサーを使用するには、Balancer フィールドをロードバランサー名に設定します。任意で、Domain フィールドはロードバランサー自体に設定されたグループのいずれかです。重要Balancer および Domain 値は、対応する Apache サーバーの設定と一致する必要があります。
- ページ上部の Save ボタンをクリックします。
33.7.3. Discovery からの Web コンテキストの除外
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Configuration タブをクリックします。
- Web Context Options セクションに移動します。
- Excluded Contexts フィールドの設定を解除し、除外するコンテキストの名前を追加します。注記JBoss EAP の内部コンテキストの一部はデフォルトで除外されます。これは除外リストに保持する必要があります。除外する新しいコンテキストは、既存のリストに追加する必要があります。
- ページ上部の Save ボタンをクリックします。
33.7.4. Web コンテキストメトリクスの設定
- トップメニューの Inventory タブをクリックします。
- 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。次に、mod_cluster サービス(マスターノード)をホストする JBoss EAP 7 サーバーを選択します。
- mod_cluster service リソースに移動します。
- リソースエントリーの Operations タブをクリックします。
- ドロップダウンメニューから Add (Custom) Metrics 操作を選択します。
- メトリック情報を入力します。デフォルトのメトリクスは mod_cluster ドキュメント に記載されています。
- ページ下部の Schedule ボタンをクリックします。
33.8. JBoss Enterprise Application Platform 7 のパッチ適用
33.8.1. パッチ操作
$EAP/.installation
、$EAP/.installation/.rhq
(エージェントがメタデータを保存する場所)、および EAP ディレクトリーに対する読み取りおよび書き込み権限があることを確認します。これにより、JON エージェントは EAP サーバーにパッチを当てることができます。
33.8.1.1. バンドルおよび宛先
33.8.1.2. パッチデプロイの実行
33.8.1.2.1. パッチを使用したバンドルの作成
- Bundles タブをクリックします。
- Bundle セクションの New ボタン Bundle Creation Wizard をクリックして起動します。
- 必要なパッチをアップロードします。
- 設定を更新し、Next ボタンをクリックします。
- Next ボタンをクリックします。
- Finish ボタンをクリックします。
33.8.1.2.2. 新しい宛先へのパッチデプロイの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Deploy ボタンをクリックして、バンドルのデプロイウィザードを起動します。
- 宛先情報を入力し、をクリックし Nextます。
- Deployment Bundle Version を選択し、をクリックし Nextます。
- Deployment Configuration を選択し、をクリックし Nextます。注記
- この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
- リソースグループのサーバーにパッチデプロイメントのデフォルトの場所として提供された新しい宛先を設定するには、takeOver オプションをに設定し trueます。
- Deployment Information を指定して、をクリックし Nextます。
- Finish をクリックし、バンドルを宛先にデプロイします。
33.8.1.2.3. 既存の宛先へのパッチデプロイの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Destinations サブタブをクリックします。
- バンドルをデプロイする宛先をクリックします。
- Deploy ボタンをクリックします。
- デプロイするバンドルバージョンを選択し、をクリックし Nextます。
- Deployment Configuration を選択し、をクリックし Nextます。注記この restart オプションを使用すると、ユーザーは JBoss Enterprise Application Platform インスタンスを再起動してパッチをすぐに有効にできます。がに設定 restart された場合 no、次回のインスタンスの再起動までパッチが有効になりません。
- 必要なデプロイメント情報を指定して、をクリックし Nextます。
- Finish をクリックし、バンドルを宛先にデプロイします。
33.8.1.3. パッチ変換の実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Summary セクションの Destinations タブをクリックします。
- 元に戻す宛先を選択します。
- odo をクリックし Revert、をクリックし Yesます。
- Next 2 回クリックし、をクリックし Finishます。
33.8.1.4. パッチパージの実行
- Bundles タブをクリックします。
- EAP バンドルをクリックします。
- Summary セクションの Destinations タブをクリックします。
- パージする宛先を選択します。
- odo をクリックし Purge、をクリックし Yesます。
付録A よくある質問
- A.1. 全般
- 問: JBoss Operations Network と RHQ の違いは何ですか?
- 問: バグを検索して機能拡張要求を送信するには、公開されている問題トラッカーシステムが存在するか?
- 問: サポートされるデータベース
- 問: JBoss ON を Java 5 で起動できないのはなぜですか?
- 問: ユーザーの設定内容を見つけるにはどうすればよいですか?
- 問: JBoss ON で使用される正規表現の構文
- 問: JBoss ON がリソースの可用性をチェックする頻度
- 問: JBoss ON エージェントは起動時に待機する理由
- 問: How do I install a supported version of PostgreSQL on Red Hat Enterprise Linux?
- 問: JBoss ON コンソールから JBoss ON データベースに SQL コマンドを実行するにはどうすればよいですか?
- 問: VMWare で JBoss ON はサポートされますか?
- 問: メモリー不足の状態をデバッグできるようにするには、メモリー不足または要求に応じてエージェントまたはサーバーがヒープをダンプするにはどうすればよいですか?
- A.2. インストールおよびアップグレードの問題
- 問: サーバーのインストール(またはアップグレード)時にエラーメッセージが表示されます。意味は?
- 問: サーバーをインストールしましたが、接続できません。What's wrong?
- 問: インストーラーは「Relation RHQ_Principal does not exist」で PostgreSQL で失敗します。
- 問: サーバーをアップグレードしましたが、インストーラーページに接続して設定しようとすると、引き続き(以前の) coregui/ モジュールにリダイレクトしようとします。インストーラーにアクセスする方法は?
- 問: ORA-01843 では、Oracle で JBoss ON インストールに失敗します。
- A.3. ユーザーインターフェース
- A.4. server
- 問: サーバーを起動すると、ログにサーブレットエラーが表示されます。What's wrong?
- 問: JBoss ON サーバーからデバッグメッセージを取得する方法
- 問: サーバーの JVM のコマンドラインオプションを指定する方法
- 問: すべてのデータのスキーマをどのようにパージするか?
- 問: JDBC アクセスおよびトレース SQL をデバッグする方法
- 問: サーバーの email/SMTP 設定が正しいことを確認するにはどうすればよいですか?
- 問: サーバーマシンには /var/run という書き込み可能なディレクトリーがありません。rhq-server.sh スクリプトを取得して、その pid ファイルを正常に書き込みするにはどうすればよいですか?
- 問: サーバーを起動しようとすると、「Exception created identity」で例外が発生し、サーバーは起動に失敗します。どうすればよいですか?
- 問: サーバーログに「Have not packet from agent ...」というメッセージが表示されます。ダウンしていると疑われるため、バックフィルが行われます。 意味は?
- 問: サーバーとエージェント間でファイアウォールを設定する際に考慮すべきポートは何ですか?
- 問: サーバーを Windows サービスとしてインストールしましたが、エラーメッセージなしで起動できません。サーバーを Windows サービスとして起動するにはどうすればよいですか?
- 問: Oracle── の使用時に ORA-12519, TNS:no appropriate service handler found error を修正するにはどうすればよいですか?
- 問: サーバーログまたはスタックトレースにこのエラーが表示 されています: WARN [QueryTranslatorImpl] firstResult/maxResults with collection fetch; apply in memory.その意味と原因は何ですか?
- 問: 「同一の論理プラグイン」と「異なるコンテンツ」および「非推奨とみなされる」というメッセージをサーバーが定期的にログに記録しないようにするにはどうしたらよいですか?
- 問: JBoss ON の LDAP ユーザー認証と LDAP グループ承認の違い
- 問: LDAP グループ承認を設定するにはどうすればよいですか?
- A.5. エージェント
- 問: 共有ディスクリソースを持つ複数の仮想マシンをホストする物理マシンがあります。各仮想インスタンスでエージェントを実行する方法
- 問: JBoss ON エージェントからデバッグメッセージを取得する方法
- 問: サーバーへの接続が許可されているエージェントを制限するにはどうすればよいですか?
- 問: root でエージェントを実行する必要がありますか?
- 問: JBoss ON エージェントを新たにインストールしたかのようにクリーンアップするにはどうすればよいですか?
- 問: バックグラウンドの Windows サービスとして実行中のエージェントの「clean config」を実行する方法
- 問: すべてのエージェントでプラグインを更新するにはどうすればよいですか?
- 問: 登録後にエージェント名を変更するにはどうすればよいですか?
- 問: すべてのマシンでエージェントを実行したいが、正常に起動するのは 1 つだけです。残りのアドレスは正しくないアドレスにバインドされるため失敗します。
- 問: Windows サービス経由でエージェントを起動すると、エージェントが起動しなくなり、エージェントラッパーログファイルで「java.lang.IllegalStateException: The name of this agent is not defined - you cannot start the agent」というエラーが表示されます。意味は?
- 問: エージェントのセットアップは適切ですが、エージェントは「Cause: org.jboss.remoting.CannotConnectException: Can not connect http client invoker」というメッセージが表示されます。
- 問: 使用しているエージェントマシンには、という書き込み可能なディレクトリーがありません /var/run。rhq-agent-wrapper.sh スクリプトを取得して、pid ファイルを正常に書き込みするにはどうすればよいですか?
- 問: エージェントがリソースをスキャンする頻度。
- 問: エージェントの永続化設定を表示するにはどうすればよいですか?
- 問: エージェントの JVM プロセスに設定された環境変数と Java システムプロパティーを確認するにはどうすればよいですか?
- 問: 別のマシンで実行しているエージェントからインベントリー情報をダンプするにはどうすればよいですか?
- 問: エージェントマシンの IP アドレスを変更する必要があります。この変更でサーバーとエージェントを最新の状態に維持するにはどうすればよいですか?
- 問: サーバーが稼働状態のままになったときに、サーバーが稼働し続けることをエージェントが停止するにはどうすればよいですか?
- A.6. ログメッセージ
- A.7. サーバーおよびエージェントプラグイン
- A.8. 一般的なリソースに関する質問
- A.9. JBoss リソース
- 問: すべての JNP クレデンシャルがリソースの接続プロパティーで適切に設定されていても、JBoss AS サーバーが緑色の可用性を示し、1 つの JBoss AS サーバーのみが緑色の状態で表示されるのはなぜですか?
- 問: JBoss EAP 5 や Tomcat などのサーバーをインポートする場合、インベントリー内に子 JVM リソースが表示されますが、これは Red(DOWN)になります。なぜですか?
- 問: JBoss EAP インスタンスの監視を試みると、「Connection failure Failed to authenticate principal=null, securityDomain=jmx-console」というエラーが表示されます。
- 問: JBoss AS インスタンスを監視する場合、その下には JVM リソースは表示されません。
- 問: JBoss AS 5.1 を監視できますか?
- 問: エージェントは JBoss サーバーを検出し、接続プロパティーを取得できますが、JNP 接続は失敗します。なぜですか?
- A.10. Postgres リソース
- A.11. Apache リソース
- 問: Apache コネクターはどこで取得できますか?
- 問: Response Time モジュールで Apache をインストルメント化しましたが、VirtualHosts に対して RT メトリックは表示されていません。
- 問: Apache メトリクスの一部はゼロの値を表示します。なぜですか?
- 問: Augeas プラグインとは何ですか?
- 問: 「java.lang.UnsatisfiedLinkError: Unable to load library 'augeas': libaugeas.so: cannot open shared object file: No such file or directory"?
- 問: Apache SNMP モジュールがエラーを出して起動できないのはなぜですか?
- A.12. Tomcat リソース
- A.13. プロビジョニングおよびコンテンツ
- A.14. アラート
- A.15. 監視
- A.16. operations
A.1. 全般
- 問: JBoss Operations Network と RHQ の違いは何ですか?
- 問: バグを検索して機能拡張要求を送信するには、公開されている問題トラッカーシステムが存在するか?
- 問: サポートされるデータベース
- 問: JBoss ON を Java 5 で起動できないのはなぜですか?
- 問: ユーザーの設定内容を見つけるにはどうすればよいですか?
- 問: JBoss ON で使用される正規表現の構文
- 問: JBoss ON がリソースの可用性をチェックする頻度
- 問: JBoss ON エージェントは起動時に待機する理由
- 問: How do I install a supported version of PostgreSQL on Red Hat Enterprise Linux?
- 問: JBoss ON コンソールから JBoss ON データベースに SQL コマンドを実行するにはどうすればよいですか?
- 問: VMWare で JBoss ON はサポートされますか?
- 問: メモリー不足の状態をデバッグできるようにするには、メモリー不足または要求に応じてエージェントまたはサーバーがヒープをダンプするにはどうすればよいですか?
select id, name, string_value from rhq_config_property where configuration_id = (select configuration_id from rhq_subject where name = 'your-user-name')
rhq.agent.plugins.availability-scan.period-secs
設定で定義されます。デフォルトは 30 秒です。パフォーマンス上の理由から、30 秒未満になることはありません。新しい間隔を ADDITIONAL_JAVA_OPTIONS 値のいずれかに設定することで、スキャン間隔を拡張できます。例:
RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Drhq.agent.plugins.availability-scan.period-secs=45"
サーバーはエージェントの登録要求を拒否しました。
エージェントが起動時にこのメッセージを返すと、エージェントは 1 つの名前でサーバーで認識されているが、起動時に別の名前を送信することを意味します。
Cause: [org.rhq.core.clientapi.server.core.AgentRegistrationException:The agent asking for registration is trying to register the same address/port [172.31.7.7:16163] that is already registered under a different name [example]; if this new agent is actually the same as the original, then re-register with the same name]
エージェントはサーバーに到達できません。
これは、サーバーがダウンしているか、ファイアウォールがトラフィックをブロックしたためにサーバーにアクセスできないエージェントの状態です。サーバーマシンのポート 7080 がエージェントのマシンから到達可能であることを確認します。これは、Web ブラウザーで確認できます。
サーバーはエージェントに接続できません。
サーバーがエージェントのエンドポイントに ping できないことを示すエラーは、エージェントがサーバーと通信できるが、サーバーはエージェントと通信できないことを意味します。これは、エージェントポートがファイアウォールによってブロックされていることを意味します。
The server has rejected the agent registration request. Cause: [org.rhq.core.clientapi.server.core.AgentRegistrationException:Server cannot ping the agent's endpoint. The agent's endpoint is probably invalid or there is a firewall preventing the server from connecting to the agent. Endpoint: socket://172.31.7.3:12345/....
エージェントにはプラグインがありません。ダウンロードするまで待機します。
これは通常、サーバーがエージェントが送信したセキュリティートークンとは異なることを意味します。これにより、異なるエージェントバージョンや仮想マシンでテストするなどして、Java プリファレンスエントリーが mangled になります。
11:40:48,454 WARN [CommandProcessor] {CommandProcessor.failed- authentication}Command failed to be authenticated! This command will be ignored and not processed: Command: type=[remotepojo]; cmd-in-response= [false]; config=[{rhq.security-token=1217855913569-109582636-403140853869881172, rhq.send-throttle=true}]; params= [{targetInterfaceName=org.rhq.core.clientapi.server.core.CoreServerService, invocation=NameBasedInvocation[getLatestPlugins]}]
エージェントの起動は問題ありませんが、ping コマンドは失敗します。
ここでは、エージェントは正常に起動しますが、監視データが送信されないなど、他のエージェント通信の問題が生じる可能性があります。エージェントコマンドラインに ping を試みると、以下のようなエラーが返されます。
sending> ping Pinging... Failed to execute prompt command [ping]. Cause: org.rhq.enterprise.communications.command.server.AuthenticationException:Command failed to be authenticated! This command will be ignored and not processed: Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.security- token=1214208960346-102975580-7334156733284942657, rhq.send-throttle=true}]; params=[{targetInterfaceName=org.rhq.enterprise.communications.Ping, invocation=NameBasedInvocation[ping]}]
高可用性の IP アドレスの正引きおよび後方マッピングは一致しません。
コンピューターの IP アドレスをコンピューター名に逆マッピングでき、この名前が同じ IP アドレスにマッピングされていることを確認します。すべてのホストで true である必要があります。
$ dig -x 172.31.7.7 [...] ;; ANSWER SECTION: 7.7.31.172.in-addr.arpa. 86400 IN PTR example $ $ dig example [...] ;; ANSWER SECTION: example 74030 IN A 172.31.7.7
- RHN/JBoss の認証情報 を使用 して http://rhn.redhat.com にログインします。
- Red Hat Application Stack v2 チャネルを追加します。
- システムを更新します。
sudo yum update
- 具体的には PostgreSQL を更新します
sudo yum install postgresql-server
。data
ディレクトリーがインストールされている/var/lib/pgsql/data
。JBoss ON は、PostgreSQL 8.2.4 以降および 8.2.x バージョンと PostgreSQL 8.3、8.4、および 9.0 のすべてのリリースをサポートします。 - JBoss ON サーバーを通常通りにインストールおよび設定します。
http://server.example.com:7080/coregui/#Test/
RHQ_AGENT_ADDITIONAL_JAVA_OPTS
または RHQ_SERVER_ADDITIONAL_JAVA_OPTS
変数)。
-XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpOnCtrlBreak特定の場所にヒープダンプファイルをドロップするには、path:
-XX:HeapDumpPath=location「 SUN JVM Debugging Options 」を参照してください。
A.2. インストールおよびアップグレードの問題
- 問: サーバーのインストール(またはアップグレード)時にエラーメッセージが表示されます。意味は?
- 問: サーバーをインストールしましたが、接続できません。What's wrong?
- 問: インストーラーは「Relation RHQ_Principal does not exist」で PostgreSQL で失敗します。
- 問: サーバーをアップグレードしましたが、インストーラーページに接続して設定しようとすると、引き続き(以前の) coregui/ モジュールにリダイレクトしようとします。インストーラーにアクセスする方法は?
- 問: ORA-01843 では、Oracle で JBoss ON インストールに失敗します。
ERROR [ClientCommandSenderTask] {ClientCommandSenderTask.send-failed}Failed to send command [Command: type=[remotepojo]; cmd-in-response=[false]; config=[{rhq.timeout=1000, rhq.send-throttle=true}]; params=[{targetInterfaceName=org.rhq.enterprise.communications.Ping, invocation=NameBasedInvocation[ping]}]]. Cause: org.jboss.remoting.CannotConnectException:[.....]
rhq-server.properties
ファイル内のサーバーに設定されません。java.rmi.server.hostname
パラメーターは、jboss.bind.address
パラメーターの値に一致するサーバーの実際の IP アドレスに手動で設定する必要があります。rhq-server.properties
ファイルを編集した後にサーバーを再起動して、新しい設定を読み込む。
pg_hba.conf
、パーミッションが有効になっていることを確認します。インストール用の PostgreSQL の設定に関する詳細は、『インストール 『ガイド』』 を参照してください。
http:/server.example.com:7080/installer/start.jsf
- Oracle を別のロケールにします。
- インストーラーを実行する前にサーバーディストリビューションファイルのいずれかを編集します。
- 古いサーバーディレクトリーを削除して、インストールパッケージを再度展開します。
serverRoot/jon-server-3.3.0.GA/jbossas/server/default/rhq-installer.war/WEB-INF/classes
ディレクトリーを開きます。- 編集
db-data-combined.xml
。01-APR-08 形式の日付を、現在のロケールにあるように更新します。 - ファイルを保存します。
- インストーラーを再実行し、データベースの上書きを選択します。
A.3. ユーザーインターフェース
- プラットフォームをインポートし、そのサーバーをオフのままにします。
- プラットフォームが正常にインポートされたら、サーバーを選択し、をクリックし Ignoreます。
java.lang.RuntimeException:[1312480384219] ...
java.lang.NoClassDefFoundError: Could not initialize class org..enterprise.gui.image.chart.ColumnChart
yum install urw-fonts
A.4. server
- 問: サーバーを起動すると、ログにサーブレットエラーが表示されます。What's wrong?
- 問: JBoss ON サーバーからデバッグメッセージを取得する方法
- 問: サーバーの JVM のコマンドラインオプションを指定する方法
- 問: すべてのデータのスキーマをどのようにパージするか?
- 問: JDBC アクセスおよびトレース SQL をデバッグする方法
- 問: サーバーの email/SMTP 設定が正しいことを確認するにはどうすればよいですか?
- 問: サーバーマシンには /var/run という書き込み可能なディレクトリーがありません。rhq-server.sh スクリプトを取得して、その pid ファイルを正常に書き込みするにはどうすればよいですか?
- 問: サーバーを起動しようとすると、「Exception created identity」で例外が発生し、サーバーは起動に失敗します。どうすればよいですか?
- 問: サーバーログに「Have not packet from agent ...」というメッセージが表示されます。ダウンしていると疑われるため、バックフィルが行われます。 意味は?
- 問: サーバーとエージェント間でファイアウォールを設定する際に考慮すべきポートは何ですか?
- 問: サーバーを Windows サービスとしてインストールしましたが、エラーメッセージなしで起動できません。サーバーを Windows サービスとして起動するにはどうすればよいですか?
- 問: Oracle── の使用時に ORA-12519, TNS:no appropriate service handler found error を修正するにはどうすればよいですか?
- 問: サーバーログまたはスタックトレースにこのエラーが表示 されています: WARN [QueryTranslatorImpl] firstResult/maxResults with collection fetch; apply in memory.その意味と原因は何ですか?
- 問: 「同一の論理プラグイン」と「異なるコンテンツ」および「非推奨とみなされる」というメッセージをサーバーが定期的にログに記録しないようにするにはどうしたらよいですか?
- 問: JBoss ON の LDAP ユーザー認証と LDAP グループ承認の違い
- 問: LDAP グループ承認を設定するにはどうすればよいですか?
Servlet.service()
ログに記録されるクラス:
22:55:35,319 ERROR [[ServerInvokerServlet]] Servlet.service() for servlet ServerInvokerServlet threw exception java.lang.reflect.UndeclaredThrowableException at $Proxy421.processRequest(Unknown Source) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:128) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:157) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) ... more ...
serverRoot/jon-server-3.3.0.GA/jbossas/server/default/conf/jboss-log4j.xml
設定ファイルを編集して、のコメントを解除してデバッグメッセージを有効にすることができます。 org.rhq
カテゴリー。これにより、DEBUG に設定されます。デバッグメッセージは、すべての JBoss ON サブシステムがログファイルに出力されます。デバッグメッセージを JBoss ON サーバー内部の小規模サブセットに対してのみ出力する場合は、コメントを解除して使用するカテゴリーを指定するか、独自のカテゴリーを追加することもできます。
log4j.xml
コメントを含むコメントアウトされたカテゴリーには、特定のカテゴリーから期待されるデバッグメッセージのタイプを簡単に説明します。JBoss/Remoting や Hibernate などのサードパーティーサブシステムのデバッグメッセージを出力することもできます。これらの一部はすでににコメントアウトされてい log4j.xml
ます。
log4j.xml
ファイルを保存し、JBoss ON サーバーを再起動します。
serverRoot/jon-server-3.3.0.GA/bin/rhq-server.sh|bat stop serverRoot/jon-server-3.3.0.GA/bin/rhq-server.sh|bat start
serverRoot/jon-server-3.3.0.GA/logs/server.log
ます。
INFO
.デバッグメッセージがコンソールにも表示されるようにするには、CONSOLE アペンダーのしきい値設定をに変更します。 DEBUG
.
RHQ_SERVER_DEBUG
任意の値を設定します。ランチャーの開始時にこの変数を設定すると、スクリプトはデバッグメッセージを出力します。
RHQ_SERVER_JAVA_OPTS
環境変数。例:
RHQ_SERVER_JAVA_OPTS="-Dapp.name=rhq-server -Xms256M -Xmx1024M -XX:PermSize=128M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack= true" export RHQ_SERVER_JAVA_OPTS
RHQ_SERVER_ADDITIONAL_JAVA_OPTS
環境変数。例:
RHQ_SERVER_ADDITIONAL_JAVA_OPTS= "-Dfoo= true" export RHQ_SERVER_ADDITIONAL_JAVA_OPTS
wrapper.java.additional.n
行を追加します <server-install-dir>\bin\wrapper\rhq-server-wrapper.inc
(ファイルの作成が必要になる場合があります)。例:
- wrapper.java.additional.12=-verbosegc:file=gc-log.txt
- wrapper.java.additional.13=-XX:+HeapDumpOnOutOfMemoryError
- wrapper.java.additional.14=-XX:HeapDumpPath=heap-dump.txt
- 現在の JBoss ON サーバーディレクトリーを保存します。
mv jon-server-3.3.0.GA/ jon-server-3.3.0.GA.bak/
- 最新の JBoss ON バイナリーを展開します。
unzip jon-server-3.3.0.GA.zip
- 新しいサーバープロセスを開始します。
serverRoot/jon-server-3.3.0.GA/bin/rhqctl.sh start
- JBoss ON GUI を開き、インストール設定を行います。選択可能な場合は、のオプションを選択し Overwrite existing dataます。これにより、サーバーの以前のインストール用のデータがすべて削除されます。
http://server.example.com:7080/coregui/#Test/
RHQ_SERVER_PIDFILE_DIR
pid ファイルを保存するディレクトリーのフルパスを設定します。スクリプトを実行すると、その変数の値がデフォルトの場所を上書きします。2.1 またはそれ以前のスクリプトがある場合は、直接編集して rhq-server.sh
、希望のディレクトリー /var/run
に切り替えます。
Caused by: java.lang.RuntimeException: Exception creating identity: my.host.name.com: my.host.name.com | at org.jboss.remoting.ident.Identity.get(Identity.java:211)
/etc/hosts
)を使用してすべてのサーバーおよびエージェントのマッピングを維持することです。これにより、DNS が失敗しても JBoss ON が正常に機能し続けます。ただし、ホストファイルの使用は、お使いの環境では実用的ではない場合があります。この場合、JBoss ON インストールを開始する前に時間がかかる必要があります。これにより、JBoss ON を実行する予定の各ホストが、nslookup などのツールを使用して計画された環境にある他のすべてのホスト名を適切に解決できることを確認してください。
[org.rhq.enterprise.server.core.AgentManagerBean] Have not heard from agent [agent_name] since [timestamp]. Will be backfilled since we suspect it is down
- エージェントは実際にシャットダウンまたはクラッシュした。
- エージェントがシャットダウンまたはクラッシュしているマシン。
- エージェントとサーバー間のネットワークがダウンし、エージェントがサーバーに接続し、可用性レポートを送信することを禁止していました。
- エージェントが実行しているマシンは偽装されるため、エージェントの速度が遅くなり、エージェントが十分な速度でレポートを送信できないようにします。
RHQ_SERVER_RUN_AS_ME
環境変数がに設定されます。 true
:
rhq-server.bat remove set RHQ_SERVER_RUN_AS_ME=true rhq-server.bat install
ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE;。これにより、Oracle── データベースを再起動します。
- LDAP URL の形式で LDAP サーバーに接続する情報。たとえば、ldap://server.example.com:1389 など です。
- サーバーへの接続に使用するユーザー名およびパスワード。このアカウントには、検索対象のサブツリーへの読み取りアクセスが必要です。
- 検索ベース。これは、エントリーを検索するディレクトリーツリー内のポイントです。これには、パフォーマンスを向上させ、不要なアクセスを防ぐのに十分なエントリーを含めて、すべてのエントリーを含めることができるはずです。たとえば、JBoss ON の両方のサブツリーに ou=Web Team,dc=example,dc=com ou=Engineering,dc=example,dc=com およびとある場合、検索ベースをツリー上に設定し dc=example,dc=comます。エンジニアリンググループを JBoss ON が使用する場合のみ使用する場合は、検索ベースをに設定し ou=Engineering,dc=example,dc=comます。
- グループフィルター。これにより、グループエントリーの検索に使用する検索フィルターが作成されます。これは、グループオブジェクトクラスを使用できます。これは、JBoss ON 関連のエントリーにカスタム属性がある場合に特に便利です。また、グループ名、ローカリティー、エントリーの説明にある文字列などの他の要素を参照することもできます。これは、JBoss ON 関連グループを特定するのに有用または意味のあるものです。
- member 属性。グループオブジェクトクラスにはさまざまなタイプがあり、ほとんどの属性を使用してグループメンバーを特定します。たとえば、groupOfUniqueNames オブジェクトクラスは
uniqueMember
属性を持つメンバーを一覧表示します。
A.5. エージェント
- 問: 共有ディスクリソースを持つ複数の仮想マシンをホストする物理マシンがあります。各仮想インスタンスでエージェントを実行する方法
- 問: JBoss ON エージェントからデバッグメッセージを取得する方法
- 問: サーバーへの接続が許可されているエージェントを制限するにはどうすればよいですか?
- 問: root でエージェントを実行する必要がありますか?
- 問: JBoss ON エージェントを新たにインストールしたかのようにクリーンアップするにはどうすればよいですか?
- 問: バックグラウンドの Windows サービスとして実行中のエージェントの「clean config」を実行する方法
- 問: すべてのエージェントでプラグインを更新するにはどうすればよいですか?
- 問: 登録後にエージェント名を変更するにはどうすればよいですか?
- 問: すべてのマシンでエージェントを実行したいが、正常に起動するのは 1 つだけです。残りのアドレスは正しくないアドレスにバインドされるため失敗します。
- 問: Windows サービス経由でエージェントを起動すると、エージェントが起動しなくなり、エージェントラッパーログファイルで「java.lang.IllegalStateException: The name of this agent is not defined - you cannot start the agent」というエラーが表示されます。意味は?
- 問: エージェントのセットアップは適切ですが、エージェントは「Cause: org.jboss.remoting.CannotConnectException: Can not connect http client invoker」というメッセージが表示されます。
- 問: 使用しているエージェントマシンには、という書き込み可能なディレクトリーがありません /var/run。rhq-agent-wrapper.sh スクリプトを取得して、pid ファイルを正常に書き込みするにはどうすればよいですか?
- 問: エージェントがリソースをスキャンする頻度。
- 問: エージェントの永続化設定を表示するにはどうすればよいですか?
- 問: エージェントの JVM プロセスに設定された環境変数と Java システムプロパティーを確認するにはどうすればよいですか?
- 問: 別のマシンで実行しているエージェントからインベントリー情報をダンプするにはどうすればよいですか?
- 問: エージェントマシンの IP アドレスを変更する必要があります。この変更でサーバーとエージェントを最新の状態に維持するにはどうすればよいですか?
- 問: サーバーが稼働状態のままになったときに、サーバーが稼働し続けることをエージェントが停止するにはどうすればよいですか?
RHQ_AGENT_DEBUG
任意の値を設定します。エージェントを起動すると、ランチャースクリプトとエージェント自体の両方がデバッグメッセージを出力します。この環境変数を使用すると、エージェントは内部 log4j
設定ファイルを使用します。
log4j
カテゴリーに DEBUG 優先順位があるかをより詳細に制御するには、conf/log4j.xml
ファイルを編集してエージェントを再起動して変更を読み込みます。未設定 RHQ_AGENT_DEBUG
エージェントが log4j.xml
ファイルを使用し、その環境変数を設定する log4j.xml
と、内部的に設定された log4j
設定でエージェントが上書きされます。
agentRoot/rhq-agent/logs
ディレクトリーにあるログファイルにあります。
RHQ_AGENT_DEBUG
サービスをインストールします。
rhq-agent-wrapper.bat install
- 以下の名前と場所を使用して、制限ルールのファイルを作成します。
vim serverInstallDir/jbossas/server/default/deploy/rhq.ear/jboss-remoting-servlet-invoker-2x.r3040.jon.war/WEB-INF/context.xml
- このコンテンツをファイルに追加します。
<Context> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.*,142.104.128.*,10.224.27.182"/> </Context>
allow=
属性は、サーバーへの接続が許可される IP の一覧です。その他の IP はすべてブロックされます。
postgres.conf
ます。PostgreSQL 権限のない root 以外のユーザーとしてエージェントを実行すると、エージェントはファイルの読み取りおよび管理ができません。(また、エージェントログにはこのようなログメッセージがあります)。 iptables や一部の JBoss サーバーなど、同様の特権ファイルを持つ他のリソースがあります。
- JBoss ON サーバーインベントリーから platform エントリーを削除します。プラットフォームエントリーは agent エントリーの代表であるため、実際には JBoss ON トポロジーからエージェントが削除されます。
- エージェントを停止し、--fullcleanconfig (-L) コマンドラインオプションを使用して再起動します。
agentRoot/rhq-agent/bin/rhq-agent.sh --fullcleanconfig
--fullcleanconfig オプションは、エージェントのローカルインベントリーをすべて削除し、agent-configuration.xml
ファイルから新しい設定を再読み込みし、サーバーでエージェントを再登録します。必要に応じて、--config
引数を渡して、ユーザーが指定した設定ファイルで起動できるようにします。それ以外の場合は、デフォルトのconf/agent-configuration.xml
ファイルが使用されます。ディレクトリーが指定されていない場合は、コマンドでエージェントのconf/
ディレクトリー内の設定ファイルを検索します。agentRoot/rhq-agent/bin/rhq-agent.sh --fullcleanconfig -c my-agent-configuration.xml
agent-configuration.xml
ファイルから設定を読み取るように強制できます。エージェントがファイルから設定を再読み込みするよう強制するには、フォアグラウンドで起動できないため、再設定がより困難になります。
rhq-agent-wrapper.conf
ファイルを編集し、行を追加することができます。
wrapper.app.parameter.3=--cleanconfigこれにより、サービスとして起動される
agent-configuration.xml
たびにエージェントの設定を再読み込みします。この場合、エージェントに必要な(およびオプション)の設定をすべて事前に設定し、正しい設定で再起動するように agent-configuration.xml
する必要があります。
resource.resourceType.pluginName = RHQAgent resource.resourceType.typeName = RHQ Agent
FATAL [main] (org.jboss.on.agent.AgentMain)- {AgentMain.startup-error}The agent encountered an error during startup and must abort java.net.BindException: Cannot assign requested address
agent-configuration.xml
手動で変更になりましたか?(例: IP アドレスの変更)。エージェントの設定 XML ファイルは、Java Preferences を使用して永続化されるため、エージェントの設定後に参照され ません。設定を保持すると、設定が失われずにエージェントを更新または再インストールできます。エージェントの設定ファイルを変更し、それらの変更を取得するに -c は、エージェントを再起動して、--config コマンドラインオプション(または短所 --config)を渡します。これにより、エージェントは設定ファイルを再読み込みし、以前永続化した古い設定をオーバーライドするように指示します。
$HOME/.java
を選択することになります。Java 設定はレジストリーに保存されるため、通常は Windows では問題ありません。エージェントをユーザーと同じユーザーとして実行し、ユーザーのホームディレクトリーを共有している場合は、エージェントが異なる Java 設定名を使用します。エージェントの agent-configuration.xml
ファイルを編集し、Java プリファレンスノード名を次のように変更します。 デフォルト
すべてのエージェントで一意となるものにすることができます。例:
<node name="NewName">
--pref
オプションを使用して、エージェントに新しい優先順位を指示します。設定ファイルを変更したら、でエージェントを再起動して設定ファイル -c
を指定します。
agentRoot/rhq-agent/bin/rhq-agent.sh --pref NewName -c agent-configuration.xml
--pref
オプションを使用してエージェントを再起動して、ノード名を渡すようにします。
java.util.prefs.userRoot
別の一意の場所をポイントします。エージェントが起動すると、Java はそのシステムプロパティーの値を Java Preferences を格納する場所として使用します。このシステムプロパティーは、に設定して、エージェントに設定できます。 RHQ_AGENT_ADDITIONAL_JAVA_OPTS
環境変数。その環境変数を設定すると、エージェントの Java 仮想マシンにオプションを渡すと、デフォルトの Java オプションに値が rhq-agent.sh
追加されます。
set RHQ_AGENT_ADDITIONAL_JAVA_OPTS="-Djava.util.prefs.userRoot=/etc/rhq-agent-prefs" agentRoot/rhq-agent/bin/rhq-agent.sh
/var/run
。rhq-agent-wrapper.sh スクリプトを取得して、pid ファイルを正常に書き込みするにはどうすればよいですか?
RHQ_AGENT_PIDFILE_DIR
pid ファイルを保存するディレクトリーのフルパスを設定します。スクリプトを実行すると、その変数の値がデフォルトの場所を上書きします。古いスクリプト(2.1 以前)がある場合は、直接編集して rhq-agent-wrapper.sh
、希望のディレクトリー /var/run
に切り替えます。
agent-configuration.xml
れている値で読み取られ、上書きされます。エージェントを最初に設定した後は、その設定が永続化され、設定をクリアしない限り agent-configuration.xml
、その設定に再び参照されることはありません。
- エージェントが JBoss ON インベントリーにある場合は、エージェントの Configuration タブに移動し、ライブ設定を表示します。これは永続する設定と同じです。
- エージェントがデーモン以外のモードで実行されている場合は(たとえば、コンソールにエージェントプロンプトがある場合は)、getconfig または config prompt コマンドを使用してライブ設定を表示できます。詳細は help getconfig、または help config を入力します。
- エージェントが JBoss ON インベントリーにある場合は、Execute Prompt Command 操作を実行し、getconfig prompt コマンドを実行します。
- エージェント設定は標準の Java Preferences API バッキングストアに保存されるため、Google の Java Preferences Tool などの Java 設定を調べることのできるツールを使用できます。これは、ファイルシステムのような表示を Java 設定に提供できる GUI ツールです。エージェントの設定は、ノード名の User preferences ノードに保存され rhq-agentます。起動時にノード名のエージェントに渡される -p オプションに応じて、実際の構成設定は、以下のサブノードの下にあります。
rhq-agent
.デフォルトの設定ノードが呼び出されます。デフォルト
したがって、通常、エージェントの永続化された設定は、以下のユーザー設定にあり rhq-agent/defaultます。
data/inventory.dat
ファイルを取得します。そのファイルをローカルマシンにコピーします。次に、他のエージェントと同じプラグインを使用して、ローカルマシンでエージェントを実行します。エージェントは必ずしもサーバーに接続する必要はなく、プラグインコンテナーを起動する必要があるため、エージェントが登録されている必要があります。次に、インポートされた DAT ファイルから情報をエクスポートします。
inventory --xml --export=/bad-inventory.xml /the/bad/inventory.dat
--export
オプションを指定しないと、XML は単に stdout コンソールウィンドウにダンプされます。
rhq.communications.connector.bind-address
値を設定します(サーバーから受信メッセージをリッスンします)。
- 優先順位が新しい IP アドレスと同じになるように、エージェントの設定を変更します。agent プロンプトで setconfig prompt コマンドを実行します。
setconfig rhq.communications.connector.bind-address=IP_address
Do not changeagent-configuration.xml
。変更は反映されません。エージェントがバックグラウンドでデーモンプロセスとして実行している場合は、スクリプト(rhq-agent-wrapper.sh|bat)を使用してシャットダウンし、再起動します。 - 設定の編集後にエージェントを再起動します。
INFO (org.rhq.enterprise.agent.AgentAutoDiscoveryListener)- {AgentAutoDiscoveryListener.server-offline} The Agent has auto-detected the Server going offline [InvokerLocator [servlet://server:7080/jboss-remoting-servlet-invoker /ServerInvokerServlet?rhq.communications.connector.rhqtype=server]] - the agent will stop sending new messages ... INFO (org.rhq.enterprise.agent.AgentAutoDiscoveryListener)- {AgentAutoDiscoveryListener.server-online} The Agent has auto-detected the Server coming online [InvokerLocator [servlet://server:7080/jboss-remoting-servlet-invoker /ServerInvokerServlet?rhq.communications.connector.rhqtype=server]] - the agent will be able to start sending messages now
- rhq.agent.server-auto-detection
- rhq.communications.multicast-detector.enabled
rhq.agent.client.server-polling-interval-msecs
値が 0(通常は 60000)よりも大きくなります。それ以外の場合は、エージェントはサーバーがダウンしたタイミングを認識できません。
A.6. ログメッセージ
02:31:33,095 WARN [CommandProcessor] {CommandProcessor.failed-authentication} Command failed to be authenticated! This command will be ignored and not processed: Command: type=[identify]; cmd-in-response=[false]; config=[{}]; params=[null]
13:43:10,781 WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@103583b <rs=org.postgresql.jdbc3.Jdbc3ResultSet@d16f5b>
A.7. サーバーおよびエージェントプラグイン
rhq-plug-in.xml
プラグイン記述子が含まれる Maven pom が含まれます。
A.8. 一般的なリソースに関する質問
> discovery -f
/etc/sysconfig/network
以下のように変更します。
NETWORKING_IPV6=no
/etc/modprobe.conf
を追加します。
alias net-pf-10 off alias ipv6 off
service ip6tables stop
chkconfig ip6tables off
/etc/rsyslog.conf
)でメッセージをフォーマットして JBoss ON が理解できるようにします。例:
$template RHQfmt,"%timegenerated:::date-rfc3339%,%syslogpriority-text%,%syslogfacility-text%:%msg%\n"
$template RHQfmt,"%timegenerated:::date-rfc3339%,%syslogpriority-text%,%syslogfacility-text%:%msg%\n" *.* /var/log/messages-for-rhq;RHQfmt *.* @@127.0.0.1:5514;RHQfmt
/var/log/messages-for-rhq
送信します。
chmod a+x scriptname
A.9. JBoss リソース
- 問: すべての JNP クレデンシャルがリソースの接続プロパティーで適切に設定されていても、JBoss AS サーバーが緑色の可用性を示し、1 つの JBoss AS サーバーのみが緑色の状態で表示されるのはなぜですか?
- 問: JBoss EAP 5 や Tomcat などのサーバーをインポートする場合、インベントリー内に子 JVM リソースが表示されますが、これは Red(DOWN)になります。なぜですか?
- 問: JBoss EAP インスタンスの監視を試みると、「Connection failure Failed to authenticate principal=null, securityDomain=jmx-console」というエラーが表示されます。
- 問: JBoss AS インスタンスを監視する場合、その下には JVM リソースは表示されません。
- 問: JBoss AS 5.1 を監視できますか?
- 問: エージェントは JBoss サーバーを検出し、接続プロパティーを取得できますが、JNP 接続は失敗します。なぜですか?
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=5222 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jmxremote.access
jboss.platform.mbeanserver
システムプロパティーが設定されている。たとえば、Red Hat Enterprise Linux では、この ${JBOSS_HOME}\bin\run.conf
ファイルには以下の設定が必要です。
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
C:\Program Files
ます。
2012-01-12 15:03:38,982 DEBUG [ResourceContainer.invoker.daemon-1] (org.rhq.plugins.jbossas5.ApplicationServerComponent)- Failed to connect to Profile Service. java.lang.RuntimeException: Failed to lookup JNDI name 'ProfileService' from InitialContext. at org.rhq.plugins.jbossas5.connection.AbstractProfileServiceConnectionProvider.lookup(AbstractProfileServiceConnectionProvider.java:84) [snip]
A.10. Postgres リソース
- postgres ユーザーが削除されている。
- postgres ユーザーのパスワードが変更になりました。
- Linux では、管理ログインがに設定されてい ident sameuserます。
- 検出された Postgres リソースをインベントリーします。この可用性はダウン状態になり、子リソースを見つけることはありません。
- Postgres リソースの INVENTORY タブに移動します。
- の下 Connection Propertiesにある Edit ボタンをクリックします。
- Postgres インスタンスで有効なスーパーユーザーアカウントを反映するように、ロール名およびパスワードフィールドを変更します。
pg_hba.conf
ファイルの設定を変更してパスワードベースのログインを許可するために、Red Hat Enterprise Linux システムで Postgres を変更する必要がある場合があります。
postgres.conf
ファイルで以下の行を追加または変更します。
stats_start_collector = on
A.11. Apache リソース
- 問: Apache コネクターはどこで取得できますか?
- 問: Response Time モジュールで Apache をインストルメント化しましたが、VirtualHosts に対して RT メトリックは表示されていません。
- 問: Apache メトリクスの一部はゼロの値を表示します。なぜですか?
- 問: Augeas プラグインとは何ですか?
- 問: 「java.lang.UnsatisfiedLinkError: Unable to load library 'augeas': libaugeas.so: cannot open shared object file: No such file or directory"?
- 問: Apache SNMP モジュールがエラーを出して起動できないのはなぜですか?
- エージェントのシステムユーザーが
_rt log
ファイルを読み取りできますか?たとえば、RHEL/Apache では、デフォルトのパーミッション/var/log/httpd
は 700、root です。ls -arltd /var/log/httpd/ drwx------ 2 root root 4096 Jul 28 11:36 /var/log/httpd/
回避策として、httpd ログに代替ログディレクトリーを指定するか、権限を変更することです/var/log/httpd
。これら両方には、特定のセキュリティー上の影響があります。root としてエージェントを実行することもできますが、これが最も望ましいオプションですが、ファイルのパーミッションを変更してシステムセキュリティーを侵害しないようにする必要がある場合があります。たとえば、JBoss ON は、700、postgres パーミッションをデータディレクトリー上でアクセスするため、root 権限なしで postgres デーモンを監視できません。これらのパーミッションは変更されないため、エージェントを root として実行するのは残りの唯一のオプションです。 - Apache Vhost テンプレートに対する Response Time Metric を有効にし、応答時間が有効にされているか?これはデフォルトで無効になっています。
- Administration > > System Configuration Templates | Apache HTTP Server> Apache Virtual Hostで、をクリックし Edit Metric Templateます。
- の横にあるチェックボックスを選択し HTTP Response Timeます。
- ページの下部で、を選択し Update schedules for existing resources of marked typeます。
- コレクションの間隔を設定します。
- Go ボタンをクリック[>]します。
- 1 分あたりの GET リクエストの受信バイト数
- 1 分あたり POST リクエストの受信バイト数
- 1 分あたり受信バイト数の合計
- hosts
- grub
- apt
error | 原因 |
---|---|
/etc/httpd/conf/httpd.conf の 1376 行での構文エラー: Unable to write to SNMPvar directory"(stderr) | 「 SNMPVar」ディレクティブで指定されているディレクトリーが存在し、Apache プロセスを所有するユーザーが書き込み可能であることを確認します。 |
init_master_agent: Invalid local port(Permission denied)"(error_log ファイル内) |
Apache error_log に以下のようなログメッセージが含まれるかどうかを確認します。
[Notice] SELinux policy enabled; httpd running as context user_u:system_r:httpd_t:s0
これは、SELinux(Security-Enhanced Linux)ポリシーにより httpd プロセスが SNMP エージェントポート 1610 にバインドされないようにします。この問題を解決するには、コマンドを実行してから Apache を再起動して /usr/bin/setenforce 0、SELinux を Permissive モードに変更します。その後、error_log に以下のようなメッセージが表示されるはずです。
[notice] SELinux policy enabled; httpd running as context user_u:system_r:unconfined_t"
このメッセージには、unconfined_t という用語があります。これは、SELinux がプロセスの制限を解除していることを示します。
|
A.12. Tomcat リソース
A.13. プロビジョニングおよびコンテンツ
A.14. アラート
INFO [CacheConsistencyManagerBean] localhost took [51]ms to reload global cache INFO [CacheConsistencyManagerBean] localhost took [49]ms to reload cache for 1 agents
A.15. 監視
- 有効になっています。
- ログへのパスが有効である。
- 選択した日付の形式がログにあるものと一致します。
java.text.SimpleDateFormat
.
A.16. operations
付録B ドキュメント履歴
改訂履歴 | |||||||
---|---|---|---|---|---|---|---|
改訂 3.3.7-1 | Tue 11 Apr 2017 | Conscot ムムー | |||||
| |||||||
改訂 3.3.2-11 | Thu Jun 23 2016 | Conscot ムムー | |||||
| |||||||
改訂 3.3.2-7 | Thu 02 July 2015 | Jared イタリア | |||||
| |||||||
改訂 3.3.2-2 | Tue 28 Apr 2015 | Jared イタリア | |||||
| |||||||
改訂 3.3.2-1 | Tue 28 Apr 2015 | Jared イタリア | |||||
| |||||||
改訂 3.3.1-3 | Wed Feb 25 2015 | Jared イタリア | |||||
| |||||||
改訂 3.3-71 | Mon Nov 17 2014 | Jared イタリア | |||||
|