モデリング ゲートウェイでのサービス管理コンポーネントの作成
内容
casp1032jp
内容
CA Spectrum のモデリング ゲートウェイ ツールキットを使用してサービス管理コンポーネント モデルを作成して、XML 入力ファイルでサービス コンポーネント モデルの設定を定義し、それらのファイルを CA Spectrum にインポートできます。サービス エディタを使用してサービス管理モデルを作成する代わりに、モデリング ゲートウェイ ツールキットでサービス管理モデルを定義し、それを CA Spectrum にインポートすることには、以下の利点があります。
- モデリング ゲートウェイでは、複数の新しいモデルをまとめて定義できます。あるサービス管理モデルを作成したら、そのモデルの XML 入力ファイルを、同じタイプの他のモデルを作成するためのテンプレートとして使用できます。
- モデリング ゲートウェイを介してインポートしたサービス管理モデルは、サービス エディタを使用するか、または単純にオリジナルの XML ファイルを編集して再インポートすることにより、編集できます。
- サービス管理モデルの作成を自動化するためには、外部データ ソースに基づくインポート用 XML ファイルを作成することが条件になります。モデリング ゲートウェイ機能と前提条件を確認できます。詳細については、「モデリング ゲートウェイ ツールキット」を参照してください。
XML フレームワークについて
階層モデル(SM_Service_Mgt、SM_ServiceMgr、SM_SLA_Mgr、CustomerManager)は、XML 入力ファイル内で以下の例のように、配置および名前付けされている必要があります。
XML 入力ファイルの基本的なフレームワークの例を以下に示します。各サービス管理コンポーネントは、ファイルの適切なセクションにそれぞれ追加されます。サービス モデルは SM_ServiceMgr ブロック内か、その他のサービス内で作成できます。カスタマ モデルおよびカスタマ グループ モデルは CustomerManager ブロック内で作成されます。最後に、SLA モデルは SLA_Mgr ブロック内で作成されます。
<?xml version="1.0" standalone="no"?> <!DOCTYPE Import SYSTEM ".import.dtd"> <Import> <SM_Service_Mgt name="Service Management" containment_relation="SlmHasServiceComponent"> <SM_ServiceMgr name="Services" containment_relation="SlmContains"> </SM_ServiceMgr> <SM_SLA_Mgr name="SLAs" containment_relation="SlmContainsSLAs"> </SM_SLA_Mgr> <CustomerManager name="Customers" containment_relation="Groups_Customers"> </CustomerManager> </SM_Service_Mgt> </Import>
以下の図に、OneClick コンソールで表示される階層を示します。

重要:
フレームワーク タグ内の name および containment_relation 属性の値は、インポートする XML ファイルに準拠している必要がありますが、インポートする個々のサービス、リソース監視、カスタマ、SLA、および保証のモデルには一意の名前が必要です。これは OneClick クライアントの場合とは異なります。モデリング ゲートウェイでは名前によって一意性を示します。同じ名前を持つサービスは同じモデルとして解釈されます。サービス モデル
サービス モデルは、インポートする XML ファイルの SM_ServiceMgr タグに定義されている必要があります。Service Manager がインストールされている各ランドスケープには、Services というモデル名の SM_ServiceMgr モデルが 1 つだけあります。
1 つのランドスケープ内の各サービス モデルは、Service Manager による SlmContains か、または別のサービス モデルによる SlmMonitors のいずれかである必要があります。
モデリング ゲートウェイを効果的に使用するには、ポリシーとポリシー ID 間のマッピングについて理解しておく必要があります。たとえば、あるサービスが他のサービスまたはリソース監視を監視する場合は、そのサービスはサービス ヘルスのポリシー(ID 6-9)で設定されている必要があります。また、サービス ポリシー エディタで ID を表示するようにポリシー テーブルを設定して、ユーザが作成したポリシーのポリシー ID を特定することもできます。
ポリシーおよびウォッチ対象属性
モデリング ゲートウェイを使用してサービスをモデリングする場合は、MonitorPolicy_ID の値を、サービスが使用するポリシーと関連付けられた ID 番号に設定できます。[サービス ポリシー ID]列をサービス ポリシー テーブルに追加すると、サービス ポリシー ID をサービス ポリシー エディタで確認できるようになります。標準装備のポリシーは 1 で始まり、ユーザ作成のポリシーは 1000 で始まります。
サービス ポリシー エディタにポリシー ID を表示することに加えて、以下のリンクで表示されるポリシー ID を確認できます。
http://<server>/spectrum/slm/ policyrep.jsp
Monitor Policy_ID を指定する場合には、AttrToWatch と選択したポリシーの属性が一致していることを確認します。
注:
XML ファイルで、監視ポリシー ID とウォッチ対象属性(たとえば、ポリシー ID 2 を使用している、ウォッチ中の接続ステータス)間で不整合がある場合、Service Manager では、そのサービスが機能停止の状態にされます。これは停止としてレポートされ、サービス ダッシュボードで表示できます。サービスがデフォルトになると、[サービス管理]モデルにアラームが生成されます。このアラームは、SLA に関連付けられているサービスの場合は「メジャー」となり、SLA に関連付けられていないサービスの場合は「マイナー」となります。例:リソースを直接監視するサービス
以下の XML ドキュメントでは「Test Service」というサービスが設定されています。このサービスでは、Cisco の 2 つのルータの接続ステータスが監視され、いずれかのルータの接続が失われた場合に重大なアラームが生成されます。

- サービス モデルには Test Service が含まれます(SlmContains 関係が保持されています)。これにより Test Service を Service Manager の直接の子とすることができます。Test Service は OneClick ナビゲーション画面で[サービス]アイコンの下に表示されます。
- Test Service では 10.253.9.7 および 10.253.9.8 のデバイスが監視され(SlmMonitors 関係が保持されています)、Contact Status High Sensitivity ポリシーの使用により、Contact_Status 属性がウォッチされます。
- Generate_Service_Alarms の値が true である、つまりサービス ヘルス値がダウン、低下、またはやや低下していることを示している場合には、CA Spectrum では、そのサービスに対してアラームが生成されます。
例:リソース監視でリソースを監視するサービス
以下の XML ドキュメントでは、その他の 2 つのサービス(コア ルータおよび DNS)を直接監視するサービスである XYZ サービスを定義します。さらに、SM_AttrMonitor エレメントを指定することにより、XYZ サービスで 3 つのリソース監視を定義します。最初のリソース監視 XYZ Condition は、XYZ Network コンテナのコンテンツを監視します。2 番目のリソース監視 XYZ Response Time は SPM テスト コール XYZ_RTM_1 を監視します。最後に、サービスでは、インターフェース モデルを監視するリソース監視 XYZ Port Status も定義します。
<SM_Service containment_relation="SlmMonitors" name="XYZ Service" Criticality="25" AttrToWatch="Service_Health" MonitorPolicy_ID="8" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmWatchesContainer" name="XYZ Condition" AttrToWatch="Condition" MonitorPolicy_ID="2"> <Topology_Container model_type="Network" name="XYZ Network Servers" /> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="XYZ Response Time" AttrToWatch="LatestErrorStatus" MonitorPolicy_ID="18"> <RTM_Test name="XYZ_RTM_1" /> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="XYZ Port Status" AttrToWatch="Port_Status" MonitorPolicy_ID="15"> <Port ip_dnsname="10.253.50.5" identifier_name="ifIndex" identifier_value="45" /> </SM_AttrMonitor> <SM_Service name="Core Routers"/> <SM_Service name="DNS"/> </SM_Service>
例: XML を使用したサービス テンプレートの定義
多くのサービスが共通のパターンまたは構造を共有するシナリオに遭遇した場合。XML でこの構造を定義し、共通テンプレートとして使用することができます。たとえば、すべての異なっているにもかかわらず、共通のサービス モデリング コンポーネントが存在する一連のアプリケーションを監視するサービスを構築できます。構造を定義して、サービスを必要な数だけその構造からインポートすることができます。一部のデータは、インポート用に追加したり、空のサービスやリソース モニタを作成したりすることができます。OneClick クライアントを使用して、リソースをそれらに追加できます。
以下の構文は、再利用可能なサービスとリソース定義のセットを定義する、小さなサービス階層用の XML の例を示しています。TMPL テキストは、インポート対象のサービス セットごとに、もっと意味のある名前に変更できるワイルドカード テストを表しています。
この例の場合、アプリケーション サーバおよび関連するデータベース サーバに対する監視容量が含まれているサービスを確認できます。また、追加レスポンス時間とパフォーマンス モニタリングも確認できます。この例は特定の要件に合わせることを意図していませんが、一般的な要件を持ったサービス セット用の XML テンプレートを作成するための例として役に立ちます。
<SM_Service containment_relation="SlmMonitors" name="TMPL Application Service" Criticality="10" AttrToWatch="Service_Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Servers" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="9" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Server 1" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Host 1" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="2" Special_Cause_List="0x1106f-0x11232"> // Excludes all eHealth alerts </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Critical Processes" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 System Resources" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Connection" AttrToWatch="Response Time" MonitorPolicy_ID="19"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL App Server 1 Performance" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="1" Special_Cause_List="0x1120a,0x11219"> // Includes 2 specific eHealth alerts only </SM_AttrMonitor> </SM_Service> </SM_Service> <SM_Service containment_relation="SlmMonitors" name="TMPL Database Servers" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="6" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Database Server 1" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Host 1" AttrToWatch="Condition" MonitorPolicy_ID="3" Cause_List_Control="2" Special_Cause_List="0x1106f-0x11232"> // Excludes all eHealth alerts </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 Critical Processes" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 System Resources" AttrToWatch="Condition" MonitorPolicy_ID="3"> </SM_AttrMonitor> <SM_AttrMonitor containment_relation="SlmMonitors" name="TMPL DB Server 1 Connection" AttrToWatch="Response Time" MonitorPolicy_ID="19"> </SM_AttrMonitor> </SM_Service> </SM_Service> </SM_Service containment_relation="SlmMonitors" name="TMPL Application Performance & Response Time" Criticality="10" AttrToWatch="Service Health" MonitorPolicy_ID="7" Generate_Service_Alarms="true"> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Response Time" Criticality="10" AttrToWatch="Response Time" MonitorPolicy_ID="20" Generate_Service_Alarms="true"> <SM_Service> <SM_Service containment_relation="SlmMonitors" name="TMPL Application Performance Criticality="10" AttrToWatch="Condition" MonitorPolicy_ID="4" Cause_List_Control="1" Special_Cause_List="0x1106f-0x11232"> // Includes eHealth alerts only Generate_Service_Alarms="true"> <SM_Service> </SM_Service> </SM_Service>
XML の各コンポーネントを確認して、その目的と、XML によって定義されるサービス階層内で各コンポーネントがどのように適合しているかを理解しましょう。階層の最上位は、3 つの直接子サービスを持つアプリケーション サービスです。

アプリケーション サービスは、高感度ポリシーを使って、それぞれの子サービスを監視します。そのため、アプリケーション サービスのサービス ヘルスが、最低の直接リソースのサービス ヘルスと同等になることがあります。
アプリケーション サーバ サービスは、個々のサーバを表す子サービスを監視するように設計されています。各サーバは、5 つのリソース モニタを持つサービス モデルによって表されます。XML の例には Application Server 1 だけが含まれていますが、必要に応じて、このセクションに任意の数のサーバを追加できます。

アプリケーション サーバ サービスは、冗長性、低感度ポリシー(パーセント)を使って、個々の子サービスのヘルスを監視できます。
ただし、各アプリケーション サーバ サービスは、高感度ポリシーを使ってリソース モニタを監視します。リソース モニタは、ホスト自体、クリティカルなプロセス、システム リソース、アプリケーション接続およびアプリケーションのパフォーマンスに焦点を当てています。ホスト リソース モニタは、パフォーマンスに基づく CA eHealth 通知を除外します。アプリケーション パフォーマンス リソース モニタは、CA eHealth 通知によってのみ影響を受けます。両方のリソース モニタは、リソースと同じホスト モデルを対象とする可能性が高くなりますが、別のタイプのリソース停止によって影響を受けます。このため、サービス停止を可用性またはパフォーマンスに関連付けるかどうか、ユーザが決定できます。

データベース サーバ サービスは、アプリケーション サーバと同様の構造があります。複数の個別サーバのサポートが可能です。

個別のサーバはそれぞれ 4 つのリソース モニタをサポートします。これらは、ホスト モデル、クリティカルなデータベース プロセス、システム リソースおよびデータベース接続に関する障害を検出します。繰り返しになりますが、ホスト リソース モニタが CA eHealth 通知を除外することが分かります。

最後に、サービスには、パフォーマンスおよびレスポンス時間の監視用コンポーネントも含まれます。アプリケーション レスポンス時間サブ サービスは、CA Spectrum 内の SPM テストの監視に焦点を当てています。デフォルトのレスポンス時間ポリシーを使用することも、平均レスポンス時間用にカスタム ポリシーを開発することもできます。パフォーマンス サブ サービスは、CA Spectrum に送信される CA eHealth パフォーマンス通知に基づいて、リソース障害を検出します。パフォーマンス サービスは、CA eHealth 通知がリソース アラームにマップされるリソースとして、一連のホスト モデルを使用する可能性が高くなります。

この例は、特定のシナリオに適合するように設計されていませんが、使用環境で一般的なパターンをモデリングするために、モデリング ゲートウェイをどのように使用できるかの例を示します。
すべてのリソースを識別できる場合、XML ファイルでサービスおよびリソース モニタのエレメントに追加できます。すべてのサービス リソースが不明の場合でも、サービスおよびリソース モニタは今までどおりインポート可能で、リソースが空の場合もあります。CA Spectrum では空のサービスおよびリソース モニタは青いアイコンで表示され、リソースの入力を求めるプロンプトが表示されます。
例:サービスの保守スケジュールの定義
サービスおよびそのリソースの構造を定義することに加えて、サービスの保守スケジュールも指定できます。以下の XML ドキュメントでは、既存のスケジュール モデルを使用して、「ABC サービス」というサービスについて保守スケジュールが定義されています。
<SM_Service containment_relation="MaintenenceScheduledBy" name="ABC Service"> <Schedule name="Every day from 6 PM - 7 AM" SCHED_Recurrence="2" SCHED_Duration="46800" SCHED_Start_Hour="18" SCHED_Start_DoM="0" SCHED_DayBitMask="0" SCHED_Start_Day="0" SCHED_Description="" SCHED_Start_Year="0" SCHED_Start_DoW="0" SCHED_Start_MoY="0" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Daily_Repeat_Limit="2" SCHED_Recurrence_Multiplier="1"/> </SM_Service>
例:サービスまたはリソース監視に対するアラーム除外リストの定義
モデリング ゲートウェイを使用して、サービスにアラーム タイプ除外リストを指定できます。この設定はサービス モデルに適用されると、ポリシー レベルで作成された任意の設定の代わりで使用できます。この XML 設定は、サービス エディタの[除外]タブでアラーム タイプ除外を指定することと同等です。このサービスに対して指定する設定がポリシー内で定義されている場合は、ポリシー ID を指定します。
以下の XML セグメントでは、3 つのアラーム(0xabcd0001、0xabcd0001、0xabcd0002)が指定されています。(Cause_List_Control=“1”)サービスはこれらのアラーム タイプにのみ影響されます。
<SM_Service containment_relation="SlmMonitors" name="Access Routers" Criticality="30" AttrToWatch="Condition" Cause_List_Control="1" Special_Cause_List="0xabcd0001,0xabcd0001,0xabcd0002" MonitorPolicy_ID="2" Generate_Service_Alarms="true"> <Device ip_dnsname="10.253.9.16" /> <Device ip_dnsname="10.253.9.17" /> <Device ip_dnsname="192.168.152.5" /> <Device ip_dnsname="172.19.17.174" /> </SM_Service>
以下の XML ドキュメントでは、サービス(Cause_List_Control=“2”)のヘルスに対する影響を除外可能なアラーム範囲(0xeeee0000-0xeeee002b)が指定されています。
<SM_AttrMonitor containment_relation="SlmMonitors" name="Access Routers" Criticality="30" AttrToWatch="Condition" Cause_List_Control="2" Special_Cause_List="0xeeee0000-0xeeee002b" MonitorPolicy_ID="2"> <Device ip_dnsname="10.253.9.16" /> <Device ip_dnsname="10.253.9.17" /> <Device ip_dnsname="192.168.152.5" /> <Device ip_dnsname="172.19.17.174" /> </SM_AttrMonitor>
例:サービスに対する SLA の関連付け
モデリング ゲートウェイを使用して、サービス モデルを SLA モデルに関連付けることができます。この関連付けでは、特定の保証モデルを作成することも、既存の保証モデルにサービスを関連付けることも行われません。保証の関連付けを明示的に実行する必要があります。これについてはこのドキュメントの後の方で説明します。
以下の XML の例には、サービスに SLA を関連付ける方法が示されています。
<SM_SLA containment_relation="SlmGuarantees" name="Acme Service Level Agreement"> <SM_Service name="Acme"/> </SM_SLA>
例: SLA に対する保証の作成
保証モデルは SLA エレメント内で作成され、サービスまたはリソース監視のモデルに関連付けることができるようになります。以下の XML では、SLA コール Acme サービス レベル アグリーメントに対して保証を作成する方法を示します。保証を「Engineering Guarantee」として呼び出して、「Engineering」サービスが「ダウン」状態にある停止時間を記録できます。
<SM_SLA containment_relation="SlmHasGuarantee" name="Acme Service Level Agreement"> <SM_Guarantee containment_relation="SlmIsMeasuredBy" name="Engineering Guarantee" GuaranteeControl="1" GuaranteeType="0" ServiceHealthType="1" WarningThresholdPercent="80.5" ViolationThresholdPercent="99.5" GuaranteeNotes="Tracks Down Time For Engineering Service" GuaranteeDescription="Availability Guarantee for Acme Engineering" MOT_Threshold="300" MTBF_Threshold="300" MTTR_Threshold="300"> <SM_Service name="Engineering"/> </SM_Guarantee> </SM_SLA>
保証の業務時間は、XML を使用して、スケジュールを定義することにより指定できます。以下の例では、「Business Hours」という名前のスケジュールを「Engineering Guarantee」モデルに関連付ける方法を示します。
<SM_Guarantee containment_relation="SlmSchedulesGuarantee" name="Engineering Guarantee" GuaranteeType="0"> <Schedule name="Business Hours" SCHED_Recurrence="2" SCHED_Daily_Repeat_Limit="0" SCHED_Duration="25200" SCHED_Recurrence_Multiplier="1" SCHED_Start_DoM="0" SCHED_Start_DoW="0" SCHED_Start_Hour="8" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Start_Day="0" SCHED_DayBitMask="0" SCHED_Start_Year="0" SCHED_Start_MoY="0" SCHED_Description="Standard Business Hours 8AM Start"/> </SM_Guarantee>
例:SLA の定義
SLA マネージャは、すべての SLA の最上位モデルです。それぞれの SpectroSERVER には SLA マネージャ モデルが 1 つ備わっています。
SLA およびその保証を作成することに加えて、モデリング ゲートウェイを使用して SLA 期間を定義できます。以下の XML の例では、期間スケジュールを指定して SLA 期間を定義する方法を示します。
<SM_SLA_Mgr name="SLAs" containment_relation="SlmContainsSLAs" > <SM_SLA containment_relation="SlaPeriod" name="Acme Service Level Agreement" SLA_Control="1" SLA_ExpirationDate="1514696400" SLA_Notes="Manages SLA for Acme Services" SLA_Description="Acme Management Technologies Internal Service Level Agreement"> <Schedule name="Daily SLA Schedule" SCHED_Recurrence="2" SCHED_Duration="0" SCHED_Start_Hour="0" SCHED_Start_DoM="0" SCHED_DayBitMask="0" SCHED_Start_Day="0" SCHED_Description="" SCHED_Start_Year="0" SCHED_Start_DoW="0" SCHED_Start_MoY="0" SCHED_Start_Minute="0" SCHED_Start_Month="0" SCHED_Daily_Repeat_Limit="0" SCHED_Recurrence_Mutiplier="1"/> </SM_SLA> </SM_SLA_Mgr>
例:カスタマおよびカスタマ グループの定義
カスタマ モデルは、XML ファイルの CustomerManager タグ内で定義されている必要があります。各 SpectroSERVER には 1 つのカスタマ マネージャ モデルが備わっており、これは Customers という名前である必要があります。
以下の例の XML ドキュメントでは、「XYZ Group」というカスタマ グループの中に「Product Development」というカスタマが定義されています。

例:XML 入力ファイルのインポート
モデリング ゲートウェイを使用して、Service Manager の設定ファイルをインポートできます。「例:リソースを直接監視するサービス」の XML ドキュメントをテストするには、モデリング ゲートウェイを使用します。
以下の手順に従います。
- サンプルの XML ドキュメントが含まれているファイルを作成し、slm_test1.xml というファイル名で <$SPECROOT>/SS-Tools ディレクトリに保存します。
- 1 つのファイルをインポートするために modelinggateway ツールを実行するには、以下の構文を使用します。Windowsmodelinggateway.bat -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]Linuxmodelinggateway -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
- -vnmvnm_nameSpectroSERVERホスト名を指定します。
- - iimport_file
必要な入力情報が含まれている XML ファイル名を指定します(.modelinggateway.dtd でコンパイルされます)。注:複数のファイルからインポートする場合は、各ファイル名をカンマ区切りの {} かっこで囲んで指定してください。たとえば、複数のファイルをインポートするための構文例を参照してください。- -ooutputfile
(オプション)outputfileパラメータで名前を付けられたファイルにエラー情報を記録します。注:デバッグ/出力ファイル名を指定しないと、エラー情報がimport_file.log という名前のファイルに記録されます。import_fileは XML ファイルの名前です。複数インポートの場合、デバッグ/出力ファイルが追加され、統合ログを表示できます。- -debugdebugfile
(オプション)インポート プロセス中にデバッグ出力ファイルを作成することを示します。-debug オプションを使用する場合、出力に独自のデバッグ ファイル名を指定できます。debugfileに値を指定しない場合、デバッグ ファイル名はデフォルトで「.debug」というサフィックスが付けられたimport_file名になります。注:-debug オプションでは、Modeling Gateway が実行されるマシン上に空きディスク容量が必要です。たとえば、import_fileのモデルの数が多い場合、またはデバイス モデルが大きなインターフェース密度を持っている場合、大きなデバッグ出力ファイルが生成される可能性があります。複数ファイルのインポートmodelinggateway ツールは、複数の XML ファイルからのインポートをサポートするようになりました。任意の数のインポート ファイルを指定できます。複数のファイルをインポートするために modelinggateway ツールを実行するには、以下の構文を使用します。modelinggateway -vnm vnm_name [-user SS user][-i{importfile1,importfile2...}]|[ -cmdb]-e exportfile][-o outputfile] [-debug debugfile] - エラーがレポートされない場合は、デバイスおよびコンテナ モデルが作成されます。出力は以下のようになります。Import session started Fri, December 29, 2006, at 02:53:32 EST Start parsing file slm_test1.xml Start importing file slm_test1.xml Container models created: 1 Identifying ports... Import session finished Fri, December 29, 2006, at 02:53:38 EST
サービス属性(SM_Service)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示すサービス属性(sm_service)の値を指定する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | SlmMonitors SlmWatchesContainer MaintenenceScheduledBy |
名前 | サービスのモデル名。 | 256 文字までのテキスト文字列。 |
重大度 | 他の現在のアラームに対して相対的な、このアラームの影響の重大度。OneClick でのアラームでは、Criticality の値が大きいほど、影響の重大度が大きくなります。 | 10 = 低 15 = やや低 20 = 中 25 = やや高 30 = 高 |
AttrToWatch | サービス リソース モデルで監視される属性。 AttrToWatch の値は、MonitorPolicy_ID と整合性がとれている必要があります。たとえば、AttrToWatch="Condition" を指定する場合は、状態ポリシーに対して MonitorPolicy_ID(1-5)を指定する必要があります。 | 条件 RM_Condition(サービス ヘルス) Contact_Status Port_Status LatestErrorStatus(レスポンス時間) |
MonitorPolicy_ID | GlobalConfig モデル タイプで定義されている特定の監視ポリシーの ID。この ID は、AttrToWatch の値と整合性がとれている必要があります。 | 1 ~ 21 (CA Spectrum のデフォルト) 1000 ~ n (ユーザ定義) |
Generate_Service_Alarms | サービス ヘルスの変化に対して、SM_Service モデルがアラームを生成するかどうかを特定します。 | True または False |
Special_Cause_List | サービスに対してアラーム タイプの除外リストに取り込むアラーム原因コード。 | 複数のアラーム原因をカンマで区切るか、または範囲をハイフン(-)で連結したテキスト文字列。 |
Cause_List_Control | どのタイプのアラームがサービスに影響を与えるか、または与えないかを定義する整数。 | 0=未使用(原因を無視) 1=含める(次の原因で発生) 2=除外(次の原因でない) |
リソース監視の監視属性(SM_AttrMonitor)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示すリソース監視の監視属性(SM_AttrMonitor)に対する値を提示する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | SlmMonitors SlmWatchesContainer |
名前 | リソース監視のモデル名。 | 256 文字までのテキスト文字列。 |
AttrToWatch | リソース監視で監視される属性。 AttrToWatch の値は、MonitorPolicy_ID と整合性がとれている必要があります。たとえば、AttrToWatch="Condition" を指定する場合は、状態ポリシーに対して MonitorPolicy_ID(1-5)を指定する必要があります。 注: 詳細については、「ポリシー ID のマッピング」を参照してください。 | 条件 RM_Condition(サービス ヘルス) Contact_Status Port_Status LatestErrorStatus(レスポンス時間) |
MonitorPolicy_ID | GlobalConfig モデル タイプで定義されている特定の監視ポリシーの ID。AttrToWatch の値と整合性がとれている必要があります。 注: 詳細については、「ポリシー ID のマッピング」を参照してください。 | 1 ~ 21 (CA Spectrum のデフォルト) 1000 ~ n (ユーザ定義) |
Special_Cause_List | リソース監視に対するアラーム タイプの除外リストを含むアラーム原因コード。 | 複数のアラーム原因をカンマで区切るか、または範囲をハイフン(-)で連結したテキスト文字列。 |
Cause_List_Control | どのタイプのアラームがリソース監視に影響するか、または影響しないかを定義する整数。 | 0=未使用(原因を無視) 1=含める(次の原因で発生) 2=除外(次の原因でない) |
カスタマ グループ属性(SM_CustomerGroup)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示すカスタマ グループ属性の値(SM_CustomerGroup)を提供する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | Groups_Customers |
名前 | カスタマ グループのモデル名。 | 256 文字までのテキスト文字列。 |
カスタマ属性(SM_Customer)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示すカスタマ属性(SM_Customer)の値を指定する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | SlmUses |
名前 | カスタマのモデル名。 | 256 文字までのテキスト文字列。 |
CustomerField4 | 住所 1 | 256 文字までのテキスト文字列。 |
CustomerField5 | 住所 2 | 256 文字までのテキスト文字列。 |
CustomerField6 | 市区町村、都道府県、郵便番号 | 256 文字までのテキスト文字列。 |
CustomerField7 | Country | 256 文字までのテキスト文字列。 |
CustomerID | ID 番号。 | 英数字の文字列。 |
重大度 | 他の現在のアラームに対して相対的な、このアラームの影響の重大度。OneClick でのアラームでは、Criticality の値が大きいほど、影響の重大度が大きくなります。 | 10 = 低 15 = やや低 20 = 中 25 = やや高 30 = 高 |
Contact_Name | カスタマ モデルに関連付けられているユーザ。 | 256 文字までのテキスト文字列。 |
Contact_Title | 連絡先の役職。 | 256 文字までのテキスト文字列。 |
Email_Address | 連絡先の電子メール アドレス。 | 256 文字までのテキスト文字列。 |
Phone_Number | 連絡先の電話番号。 | 256 文字までのテキスト文字列。 |
Mobile_Phone_Number | 連絡先の携帯電話番号。 | 256 文字までのテキスト文字列。 |
Secondary_Contact_Name | 別の連絡先名。 | 256 文字までのテキスト文字列。 |
Secondary_Contact_Title | 別の連絡先の役職。 | 256 文字までのテキスト文字列。 |
Secondary_Phone_Number | 別の連絡先の電話番号。 | 256 文字までのテキスト文字列。 |
Secondary_Mobile_Phone_Number | 別の連絡先の携帯電話番号。 | 256 文字までのテキスト文字列。 |
Secondary_Email_Address | 別の連絡先の電子メール アドレス。 | 256 文字までのテキスト文字列。 |
SLA 属性(SM_SLA)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示す SLA 属性(SM_SLA)の値を指定する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | SlaPeriod SlmHasGuarantee SlmGuarantees |
名前 | SLA のモデル名。 | 256 文字までのテキスト文字列。 |
SLA_Control | 現行の SLA 期間に SLA をアクティブにするか、または次の期間の最初にアクティブにするかを指定します。 | 0(次の期間まで非アクティブ)または 1(アクティブ) |
SLA_ExpirationDate | 1970 年 1 月 1 日からの秒数で測定されている UNIX のタイムスタンプ。 | たとえば 2017 年 12 月 31 日は 1514696400 になります。 |
SLA_Notes | SLA に関する任意のテキストによるメモ。 | 256 文字までのテキスト文字列。 |
SLA_Description | SLA に関する任意のテキストによる説明。 | 256 文字までのテキスト文字列。 |
保証属性(SM_Guarantee)
モデリング ゲートウェイでサービス管理モデルを作成する際には、XML コードで、以下の表に示す保証属性(SM_Guarantee)の値を指定する必要があります。
属性 | Description | 有効な値 |
containment_relation | サポートされている関係セット。これを使用して関連を作成できます。 | SlmIsMeasuredBy |
名前 | 保証のモデル名。 | 256 文字までのテキスト文字列。 |
GuaranteeControl | 現行の期間に、保証をアクティブにするか、非アクティブにするかを指定します。 | 0(非アクティブ)または 1(アクティブ) |
GuaranteeType | 保証が、サービスの可用性を監視するか、またはパフォーマンス(レスポンス時間)を監視するかを指定します。 | 0(可用性)または 1(パフォーマンス) |
ServiceHealthType | 保証で累積されるサービス ヘルス時間のタイプ。可用性の保証では、ダウン時間と低下時間の両方を累積できます。パフォーマンスの保証では、低下時間のみが累積されます。 | 1(ダウン)または 2(低下) |
WarningThreshold | 1 つの期間について、ここで指定された秒数よりも長く停止した場合に、警告アラームが発行されます。 | 0 ~ n |
WarningThresholdPercent | ここで指定された割合よりも多く停止した場合に、警告アラームが発行されます。 | 0 - 100% |
ViolationThreshold | 1 つの期間について、ここで指定された秒数よりも長く停止した場合に、違反が発生します。 | 0 ~ n |
ViolationThresholdPercent | 1 つの期間について、ここで指定した稼働率よりも低くなった場合に、違反が発生します。 | 0 - 100% |
GuaranteeNotes | 保証に対する任意のテキストでのメモ。 | 256 文字までのテキスト文字列。 |
GuaranteeDescription | 保証に関する任意のテキストでの説明。 | 256 文字までのテキスト文字列。 |
MOT_Threshold | 最長停止時間(秒) | 0 ~ n |
MTBF_Threshold | 平均障害間隔(秒) | 0 ~ n |
MTTR_Threshold | 平均修復時間(秒) | 0 ~ n |
スケジュール属性(Schedule)
モデリング ゲートウェイでサービス管理モデルを作成する場合には、XML コードで、以下の表に示すスケジュール属性(Schedule)の値を指定する必要があります。
属性 | Description | 有効な値 |
名前 | スケジュールのモデル名。 注: ユーザが指定したスケジュール名は、CA Spectrum により変更されます。 | 256 文字までのテキスト文字列。 |
SCHED_Recurrence | スケジュールを実行するタイミングを指定します。 | 1 = 常時(24 x 7) 2 = 毎日 3 = 毎週 4 = 毎月 5 = 毎年 |
SCHED_Start_Hour | スケジュールを開始する時刻。 | 0 - 23 |
SCHED_Start_Minute | スケジュールを開始する分。 | 0 - 59 |
SCHED_Start_DoW | スケジュールを開始する曜日。 | 0 - 6 |
SCHED_Start_DoM | スケジュールを開始する日付。 | 1 - 31 |
SCHED_Start_Month | スケジュールを開始する月。 | 0(Jan.)- 11(Dec.) |
SCHED_Start_Year | スケジュールを開始する年。「0」を入力すると、スケジュールが今年から開始されます。 | 0 |
SCHED_Start_MoY | スケジュールを開始する月。「0」を入力すると、スケジュールが今月から開始されます。 | 0 |
SCHED_Description | スケジュールの説明。 | 256 文字までのテキスト文字列。 |
SCHED_Duration | スケジュールが有効な期間(秒単位)。 | 0 ~ n |
SCHED_Recurrence_Multiplier | スケジュールを実行する回数。 | 1 ~ n |
SCHED_Daily_Repeat_Limit | 各繰り返し期間の開始時点での、毎日のスケジュールを繰り返す連続した日数。毎週、毎月、毎年の繰り返しに対してのみ適用できます。 | 0 ~ n |