モデリング ゲートウェイでのサービス管理コンポーネントの作成

内容
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 コンソールで表示される階層を示します。
SPEC--hierarchy_OneClick_Console_scr
重要:
フレームワーク タグ内の 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 つのルータの接続ステータスが監視され、いずれかのルータの接続が失われた場合に重大なアラームが生成されます。
SPEC--example_xml_monitor_resources_directly
  • サービス モデルには 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 つの直接子サービスを持つアプリケーション サービスです。
SPEC--XML_Define_Service_Template_1
アプリケーション サービスは、高感度ポリシーを使って、それぞれの子サービスを監視します。そのため、アプリケーション サービスのサービス ヘルスが、最低の直接リソースのサービス ヘルスと同等になることがあります。
アプリケーション サーバ サービスは、個々のサーバを表す子サービスを監視するように設計されています。各サーバは、5 つのリソース モニタを持つサービス モデルによって表されます。XML の例には Application Server 1 だけが含まれていますが、必要に応じて、このセクションに任意の数のサーバを追加できます。
SPEC--XML_Define_Service_Template_2
アプリケーション サーバ サービスは、冗長性、低感度ポリシー(パーセント)を使って、個々の子サービスのヘルスを監視できます。
ただし、各アプリケーション サーバ サービスは、高感度ポリシーを使ってリソース モニタを監視します。リソース モニタは、ホスト自体、クリティカルなプロセス、システム リソース、アプリケーション接続およびアプリケーションのパフォーマンスに焦点を当てています。ホスト リソース モニタは、パフォーマンスに基づく CA eHealth 通知を除外します。アプリケーション パフォーマンス リソース モニタは、CA eHealth 通知によってのみ影響を受けます。両方のリソース モニタは、リソースと同じホスト モデルを対象とする可能性が高くなりますが、別のタイプのリソース停止によって影響を受けます。このため、サービス停止を可用性またはパフォーマンスに関連付けるかどうか、ユーザが決定できます。
SPEC--XML_Define_Service_Template_3
データベース サーバ サービスは、アプリケーション サーバと同様の構造があります。複数の個別サーバのサポートが可能です。
SPEC--XML_Define_Service_Template_4
個別のサーバはそれぞれ 4 つのリソース モニタをサポートします。これらは、ホスト モデル、クリティカルなデータベース プロセス、システム リソースおよびデータベース接続に関する障害を検出します。繰り返しになりますが、ホスト リソース モニタが CA eHealth 通知を除外することが分かります。
SPEC--XML_Define_Service_Template_5
最後に、サービスには、パフォーマンスおよびレスポンス時間の監視用コンポーネントも含まれます。アプリケーション レスポンス時間サブ サービスは、CA Spectrum 内の SPM テストの監視に焦点を当てています。デフォルトのレスポンス時間ポリシーを使用することも、平均レスポンス時間用にカスタム ポリシーを開発することもできます。パフォーマンス サブ サービスは、CA Spectrum に送信される CA eHealth パフォーマンス通知に基づいて、リソース障害を検出します。パフォーマンス サービスは、CA eHealth 通知がリソース アラームにマップされるリソースとして、一連のホスト モデルを使用する可能性が高くなります。
SPEC--XML_Define_Service_Template_6
この例は、特定のシナリオに適合するように設計されていませんが、使用環境で一般的なパターンをモデリングするために、モデリング ゲートウェイをどのように使用できるかの例を示します。
すべてのリソースを識別できる場合、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」というカスタマが定義されています。
SPEC--example_create_customer_customer_group
例:XML 入力ファイルのインポート
モデリング ゲートウェイを使用して、Service Manager の設定ファイルをインポートできます。「例:リソースを直接監視するサービス」の XML ドキュメントをテストするには、モデリング ゲートウェイを使用します。
以下の手順に従います。
  1. サンプルの XML ドキュメントが含まれているファイルを作成し、slm_test1.xml というファイル名で <
    $SPECROOT
    >/SS-Tools ディレクトリに保存します。
  2. 1 つのファイルをインポートするために modelinggateway ツールを実行するには、以下の構文を使用します。
    Windows
    modelinggateway.bat -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
    Linux
    modelinggateway -vnm vnm_name -i import_file [-o outputfile] [-debug debugfile]
    • -vnm
      vnm_name
      SpectroSERVER
      ホスト名を指定します。
    • - i
      import_file
    必要な入力情報が含まれている XML ファイル名を指定します(.modelinggateway.dtd でコンパイルされます)。
    注:
    複数のファイルからインポートする場合は、各ファイル名をカンマ区切りの {} かっこで囲んで指定してください。たとえば、複数のファイルをインポートするための構文例を参照してください。
    • -o
      outputfile
    (オプション)
    outputfile
    パラメータで名前を付けられたファイルにエラー情報を記録します。
    注:
    デバッグ/出力ファイル名を指定しないと、エラー情報が
    import_file
    .log という名前のファイルに記録されます。
    import_file
    は XML ファイルの名前です。複数インポートの場合、デバッグ/出力ファイルが追加され、統合ログを表示できます。
    • -debug
      debugfile
    (オプション)インポート プロセス中にデバッグ出力ファイルを作成することを示します。-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]
  3. エラーがレポートされない場合は、デバイスおよびコンテナ モデルが作成されます。出力は以下のようになります。
    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