システム正常性の管理

ここでは、次の内容について説明します。

システムとアプリケーションの正常性のモニター

Crosswork プラットフォームは、マイクロサービスで構成されるアーキテクチャ上に構築されます。これらのマイクロサービスの性質上、Crosswork システム内のさまざまなサービスには依存関係があります。すべてのサービスが稼働している場合、システムとアプリケーションは正常と見なされます。1 つ以上のサービスがダウンしている場合、正常性は [Degraded(低下)] と見なされます。すべてのサービスがダウンしている場合、正常性のステータスは [ダウン(Down)] です。

メインメニューから [Crosswork Manager] を選択して、[Crosswork の概要(Crosswork Summary)] ウィンドウと [Crosswork の正常性(Crosswork Health)] ウィンドウにアクセスします。各ウィンドウには、システムとアプリケーションの正常性をモニターするためのさまざまなビューがあります。また、このウィンドウには、Cisco Crosswork クラスタ、プラットフォーム インフラストラクチャ、およびインストールされているアプリケーションの問題を特定、診断、および修正するために使用できるツールと情報が、シスコ カスタマー エクスペリエンス アカウント チームからのサポートとガイダンスとともに表示されます。

両方のウィンドウで同じタイプの情報にアクセスできますが、各サマリーとビューの目的は異なります。

クラスタの正常性のモニター

[Crosswork の概要(Crosswork Summary)] ウィンドウ([Crosswork Manager] > [Crosswork の概要(Crosswork Summary)])には、システム全体の正常性の概要が表示されます。[Crosswork の概要(Crosswork Summary)] ウィンドウの主な目的は、ハードウェアリソースと VM の観点から Crosswork クラスタの正常性を表示することです。たとえば、アプリケーションをインストールまたはアップグレードする前に、ハードウェアリソースが正常であり、VM が正常に動作しているかどうかを確認できます。[Crosswork クラスタ(Crosswork Cluster)] タイルをクリックすると、リソース使用率を視覚的に確認し、VM をドリルダウンして、VM またはクラスタ関連のアクティビティを実行できます。また、サービスが低下したり、ハードウェアリソースが過剰に使用されたりすることもあります。その時点で、ハードウェアの観点から、システム内の VM の数が不足していることがわかり、システムを拡張するためにさらに VM を追加するように求められることがあります。詳細については、「クラスタの正常性の確認」を参照してください。

Crosswork クラスタの正常性を表示するだけでなく、[Cisco Crosswork プラットフォーム インフラストラクチャ(Cisco Crosswork Platform Infrastructure)] タイルとアプリケーションタイルをクリックして、マイクロサービスやアラームなどの詳細を表示することもできます。

プラットフォーム インフラストラクチャとアプリケーション正常性のモニター

[Crosswork の正常性(Crosswork Health)] ウィンドウ([Crosswork Manager] > [Crosswork の正常性(Crosswork Health)] タブ)には、Cisco Crosswork プラットフォーム インフラストラクチャとインストールされているアプリケーションの正常性の概要と、マイクロサービスステータスの詳細が表示されます。

[Crosswork の正常性(Crosswork Health)] ウィンドウ

このウィンドウ内で、アプリケーションの行を展開して、マイクロサービスとアラームの情報を表示します。

[マイクロサービス(Microservices)] タブで、次の手順を実行します。

  • マイクロサービス名をクリックして、マイクロサービスのリストと、該当する場合は関連付けられているマイクロサービスのリストを表示します。

  • [Edit] アイコン をクリックして再起動するか、マイクロサービスごとに Showtech データとログを取得します。


    (注)  


    Showtech ログは、アプリケーションごとに個別に収集する必要があります。


[アラーム(Alarms)] タブから、次の手順を実行します。

  • アラームの詳細をドリルダウンするには、アラームの説明をクリックします。

  • アラームのステータス変更(確認、未確認、クリア)

  • アラームへメモを追加します。

また、Cisco Crosswork アプリケーションまたは Cisco Crosswork Platform Showtech サービスログをすべてダウンロードし、[アプリケーションの詳細(Application Details)] ウィンドウからインストール関連の操作を実行することもできます。アプリケーション詳細を表示 をクリックして、[アプリケーションの詳細(Application Details)] ウィンドウを開きます。

システム機能をリアルタイムで視覚的にモニター

[Crosswork Manager] ウィンドウからアクセスできる一連のモニタリングダッシュボードを使用すると、Cisco Crosswork の正常性とその機能をリアルタイムでモニターできます。

Cisco Crosswork は Grafana を使用してこれらのダッシュボードを作成します。データベースで収集されたメトリックを使用して、製品のインフラストラクチャをグラフィカルに表示します。これらのダッシュボードを使用して、個々の Cisco Crosswork アプリケーションまたはその基盤となっているサービスで発生する可能性がある問題を診断できます。

複数のモニターダッシュボードがあり、モニターする機能のタイプとそれらが提供するメトリックによって分類されます。次の表に、インストールされている Cisco Crosswork アプリケーションに応じて使用可能なカテゴリを示します。

表 1. モニタリング ダッシュボードのカテゴリ

このダッシュボードカテゴリ...

モニターの対象

Change Automation

プレイブックの機能。メトリックには、実行された MOP ジョブの数、応答遅延、API コール、データベースアクティビティなどが含まれます。

Optima

機能パック、トラフィック、および SR-PCE ディスパッチャ機能。

収集 - マネージャ(Collection - Manager)

デバイスデータ収集機能。メトリックには、テレメトリ収集遅延、収集操作合計、テレメトリに関連するメモリおよびデータベースアクティビティ、遅延収集などが含まれます。

Health Insights

重要業績評価指標。メトリックには、KPI アラート、API コールなどの数が含まれます。

Infra

システム インフラストラクチャ メッセージングとデータベースアクティビティ。

インベントリ(Inventory)

インベントリマネージャ機能。これらのメトリックには、インベントリ変更アクティビティの合計数が含まれます。

プラットフォーム(Platform)

システムハードウェアおよび通信の使用状況とパフォーマンス。メトリックには、ディスクと CPU の使用率、データベースサイズ、ネットワークとディスクの動作、およびクライアント/サーバー通信が含まれます。

ZTP

ゼロタッチプロビジョニング機能。

ディスク容量を節約するために、Cisco Crosswork は最大 24 時間の収集されたメトリックデータを保持します。

Grafana は、オープンソースの可視化ツールです。次に、Grafana の Cisco Crosswork 実装の使用方法に関する一般的な情報を示します。Grafana 自体の詳細については、https://grafana.comhttp://docs.grafana.org を参照してください

手順


ステップ 1

メインメニューから、[管理(Administration)] > [Crosswork Manager] > [Crosswork クラスタ(Crosswork Cluster)] を選択します。

ステップ 2

右上にある [その他の可視化の表示(View more Visualizations)] をクリックします。

Grafana のユーザーインターフェイスが表示されます。

ステップ 3

Grafana のユーザーインターフェイスで、[ホーム(Home)] をクリックします。Grafana には、次の例に示すように、モニタリングダッシュボードとそのカテゴリのリストが表示されます。

Grafana ダッシュボードリスト

ステップ 4

表示するダッシュボードをクリックします。たとえば、[プラットフォーム:概要(Platform - Summary)] ダ ッシュボードをクリックすると、次の図のいずれかのようなビューが表示されます。

例:[プラットフォーム:概要(Platform - Summary Dashboard)] ダッシュボード

ステップ 5

必要に応じてダッシュボードをスクロールし、ダッシュボードが提供するすべてのメトリックを表示するか、または次の表に示す機能のいずれかを選択します。

項目

説明

1

[ダッシュボード(Dashboard)] アイコン:アイコンをクリックしてダッシュボードリストを再表示し、別のダッシュボードを選択します。

2

[時系列グラフのズーム(Time Series Graph Zoom)]:次のように、時系列データのグラフ内の特定の期間を拡大できます。

  1. グラフの線で期間の開始点をクリックし、マウスを押したままにします。

  2. カーソルを終了点にドラッグします。選択しているブロックにライトグレーの網掛けが表示されます。終了点に到達したら、マウスを離します。

ズームした時系列グラフをデフォルトにリセットするには、[ズームアウト(Zoom Out)] アイコンをクリックします。

3

[ダッシュボードの共有(Share Dashboard)] アイコン:表示されているダッシュボードを他のユーザーと共有できるようにするには、このアイコンをクリックします。このアイコンをクリックすると、次のいずれかの必要な形式でダッシュボードを共有するためのタブとオプションを含むポップアップウィンドウが表示されます。

  • URL リンク:[リンク(Link)] タブをクリックし、[コピー(Copy)] をクリックして、ダッシュボードの URL をクリップボードにコピーします。現在の時刻とテンプレートの設定を URL とともに保持するかどうかも選択できます。

  • ローカル スナップショット ファイル:[スナップショット(Snapshot)] タブをクリックし、[ローカルスナップショット(Local Snapshot)] をクリックします。Grafana は、サーバー上にダッシュボードのローカルスナップショットを作成します。スナップショットの準備が整ったら、[リンクのコピー(Copy Link)] をクリックして、スナップショットの URL をクリップボードにコピーします。

  • JSON ファイルへのエクスポート:[エクスポート(Export)] タブをクリックし、[ファイルに保存(Save to file)] をクリックします。エクスポートされた JSON ファイルを保存するか、開くかを尋ねられます。[ファイルに保存(Save to file)] をクリックする前に、[外部で共有するためにエクスポート(Export for Sharing for Externally)] チェックボックスをオンにして、ファイル内のデータソース名をテンプレートにすることもできます。

  • JSON ファイルの表示とクリップボードにコピー:[エクスポート(Export)] タブをクリックし、[JSON の表示(View JSON)] をクリックします([JSON の表示(View JSON)] をクリックする前に、[外部で共有するためにエクスポート(Export for sharing externally)] チェックボックスをオンにしてデータソース名をテンプレート化できます)。Grafana は、エクスポートされた JSON コードをポップアップウィンドウに表示します。[クリップボードにコピー(Copy to Clipboard)] をクリックし、クリップボードにファイルをコピーします。

4

[ビューモードのサイクル(Cycle View Mode)] アイコン:デフォルトの Grafana TV ビューモードと [キオスク(Kiosk)] モードを切り替えるには、このアイコンをクリックします。[キオスク(Kiosk)] ビューでは、Grafana メニューのほとんどが非表示になります。[キオスク(Kiosk)] ビューを終了するには、[Esc] キーを押します。

5

[時間/更新セレクタ(Time/Refresh Selector)]:ダッシュボードに表示されるメトリックの期間と、メトリックが更新される頻度を示します。セレクタをクリックして、別の時間範囲と更新レートを選択します。

時間範囲の開始点と終了点のカスタムペアを指定することも、[今日まで(Today so far)] または [過去 3 時間(Last three hours)] など、いくつかの定義済み範囲のいずれかを選択することもできます。

[オフ(Off)] から [2 日(2 Days)] までの事前定義された更新レートを選択できます。

変更を終えたら、[適用(Apply)] をクリックします。

選択する際は、24 時間分のデータのみが保存されることを覚えておいてください。時間範囲を選択するか、その制限を超える更新レートを選択すると、ダッシュボードが空白になることがあります。

6

[ズームアウト(Zoom Out)] アイコン:このアイコンをクリックすると、ズームした時系列グラフがズーム前の状態にリセットされます。

7

[更新(Refresh)] アイコン:表示されるデータをすぐに更新するか、または更新する時間間隔を選択します。


システム正常性の確認の例

この例では、さまざまなウィンドウや、正常な Crosswork システムで確認すべき領域を検討します。

手順


ステップ 1

システム全体の正常性を確認します。

  1. メインメニューから、[管理(Administration)] > [Crosswork Manager] > [Crosswork の概要(Crosswork Summary)] タブを選択します。

  2. すべてのノードが動作状態([アップ(Up)])であり、Crosswork クラスタとプラットフォーム インフラストラクチャが正常であることを確認します。

    図 1. [Crosswork の概要(Crosswork Summary)]
    [Crosswork の概要(Crosswork Summary)]

ステップ 2

Crosswork プラットフォーム インフラストラクチャの一部として実行されているマイクロサービスに関する詳細情報を確認および表示します。

  1. [Crosswork の正常性(Crosswork Health)] タブをクリックします。

  2. [Crosswork プラットフォーム インフラストラクチャ(Crosswork Platform Infrastructure)] の行を展開し、[Edit] アイコン をクリックして [アプリケーションの詳細(Application Details)] を選択します。

    図 2. [Crosswork の正常性(Crosswork Health)]
    [Crosswork の正常性(Crosswork Health)]
  3. [アプリケーションの詳細(Application Details)] ウィンドウから、マイクロサービスの詳細をチェックおよび確認し、マイクロサービスを再起動し、showtech 情報を収集できます。このウィンドウからインストール関連のタスクを実行することもできます。

    図 3. アプリケーションの詳細(Application Details)
    [マイクロサービス(Microservices)]

ステップ 3

マイクロサービスに関連するアラームを確認および表示します。

  1. [アラーム(Alarms)] タブをクリックします。リストには、Crosswork Platform Infrastructure のアラームのみが表示されます。アクティブなアラームのみを表示することで、リストをさらにフィルタ処理できます。

    図 4. アラーム

ステップ 4

インストールされている Crosswork アプリケーションを表示します。

  1. メインメニューから、[管理(Administration)] > [Crosswork Manager] > [アプリケーション管理(Application Management)] タブを選択し、[アプリケーション(Applications)] をクリックします。このウィンドウには、インストールされているすべてのアプリケーションが表示されます。[ファイル(.tar.gz)の追加(Add File (.tar.gz)] をクリックして、さらにアプリケーションをインストールすることもできます。

ステップ 5

ジョブのステータスを表示します。

  1. [ジョブ履歴(Job History)] タブをクリックします。このウィンドウには、ジョブのステータスと、ジョブプロセスの一部として実行された一連のイベントに関する情報が表示されます。


システムおよびネットワークアラームの表示

アラームを表示するには、次のいずれかに移動します。

  • メインの [Crosswork] ウィンドウで、通知アイコン をクリックします。

  • メインメニューから、[管理(Administration)] > [アラーム(Alarms)] を選択します。

  • アプリケーション固有のアラームの場合は、[管理(Administration)] > [Crosswork Manager] > [Crosswork の正常性(Crosswork Health)] タブを選択します。いずれかのアプリケーションを展開し、[アラーム(Alarms)] タブを選択します。

[アラーム(Alarms)] タブから、次の手順を実行します。

  • アラームの詳細をドリルダウンするには、アラームの説明をクリックします。

  • アラームのステータス変更(確認、未確認、クリア)

  • アラームへメモを追加します。

システム イベント

オペレータが問題をトラブルシューティングできるように、Crosswork インフラストラクチャには、システム関連のイベントを外部サーバーに転送する Syslog 機能があります(Syslog サーバーの設定およびトラップサーバーを設定を参照)。

Crosswork プラットフォームに関連するすべてのイベントは、3 つのカテゴリ(Day 0、Day 1、Day 2)に大きく分類されます。次の表に、イベントカテゴリ(day 0、day 1、および day 2)と、そのカテゴリ内のイベントまたはアクションの例を示します。


(注)  


サポートされるアラームとイベントの完全なリストについては、『Cisco Crosswork Network Controller Supported Alarms and Events』ドキュメントを参照してください。


表 2. イベント分類

イベント分類

イベントとアクションの例

Day 0:Crosswork インフラストラクチャのインストールのみに関連するイベント。

  • クラスタのステータスの確認

  • ワーカーノードの追加

  • ディスクの問題または遅延の問題

Day 1:Crosswork アプリケーションのインストールに関連するイベント。

  • マイクロサービスの再起動

  • マイクロサービスの再起動に失敗

  • アプリケーションの正常なインストール

  • アプリケーションの正常なアクティブ化

  • アプリケーションがアクティブ化から 3 分以内に正常な状態にならない

  • ノードのドレインの失敗

  • アプリケーションのアクティブ化の失敗

  • ワーカーノードの削除

Day 2:システムの運用とメンテナンスに関連するイベント。

  • ノード削除

  • ノード削除によるクリーンアップの失敗

  • アプリケーションの非アクティブ化の失敗

  • アプリケーションのアンインストールの失敗

  • ディスクまたはネットワークの速度の低下

  • ノードの削除

  • ノードの挿入

  • ノードのドレインの失敗

  • k8s ETCD のクリーンアップ

  • ノードの削除の失敗

  • ノードの削除の失敗

  • アプリケーションの正常な非アクティブ化

  • アプリケーションの正常なアンインストール

Day 0、Day 1、Day 2 のイベント例

次の表に、機能システムでの Day 0、Day 1、Day 2 のさまざまなイベントに関連する情報を示します。

Day 0 イベント

これらのチェックは、システムが正常かどうかを判断するのに役立ちます。

表 3. ワーカー ノードの追加

シビラティ(重大度)

[メジャー(Major)]

説明

VM ノードが追加されました。このイベントは、K8 クラスタがノードを検出したときに発生します。

アラームの例

なし

syslog メッセージの例

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
orchestrator-capp-infra - b54ec903-9e0f-49b8-aaf3-1d72cf644c28
vm4wkr-0 'Successfully added new VM into Inventory: vm4wkr'

推奨

VM ノードをモニターし、正常なことを示すステータスで UI に表示されていることを確認します。

表 4. ネットワークでの低速ディスクまたは遅延の問題

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、インフラストラクチャ Capp の展開に 1.5 分以上かかった場合か、または Docker プッシュの完了に 2 分以上かかった場合に発生します。

このメッセージは、firstboot.log ファイルで確認できます。

アラームの例

N/A

syslog メッセージの例

N/A

推奨

この問題は、システムでさらに操作を行う前に対処する必要があります。次の手順を実行します。

  • ディスクストレージとネットワークの SLA 要件が満たされていることを確認します。

  • 確認した帯域幅が、ノード間でプロビジョニングされた帯域幅と同じであることを確認します。

  • RAID を使用している場合は、RAID 0 であることを確認します。

Day 1 イベント

表 5. ワーカーノードの削除

シビラティ(重大度)

[メジャー(Major)]

説明

このイベントは、VMノードが消去されると発生します。

アラームの例

なし

syslog メッセージの例

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
CLUSTER-CLUSTER - 33a5ce0d-6cd0-4e4d-8438-85cfa8fb4ae9 CLUSTER-99
'user=admin,policyId=admin,backend=local,loginTime=2021-02-
28T01:38:48Z,Category=VM Manager,RequestId=vm4wkr [Erase VM []]'

推奨

VM ノードをモニターし、UI に表示されなくなっていることを確認します。消去操作が失敗した場合は、ノードの消去を再試行します。

表 6. アプリケーションの追加:成功

シビラティ(重大度)

情報

説明

このイベントは、アプリケーションが正常に追加されると発生します。

アラーム

生成されたアラーム

syslog メッセージ

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
CLUSTER-CLUSTER - 627b2140-a906-4a96-b59b-1af22f2af9f6 CLUSTER-99
'job_type=INSTALL_AND_ACTIVATE_APPLICATION,manager=app_manager:
,user=admin,policyId=admin,backend=local,loginTime=2021-02-
28T09:34:54Z,payload={"package_identifier":{"id":"cappztp","
version":"1.1.0-prerelease.259+build.260"}} [accepted]'

推奨

なし

表 7. アプリケーションの追加:失敗

シビラティ(重大度)

情報

説明

このイベントは、アプリケーションを追加できない場合に発生します。

アラームの例

生成されたアラームエラーメッセージ

syslog メッセージの例

なし

推奨

エラーを修正した後、アプリケーションの追加を再試行します。

表 8. アプリケーションのアクティブ化:成功

シビラティ(重大度)

情報

説明

このイベントは、アプリケーションが正常にアクティブ化された後に発生します。

アラームの例

なし

syslog メッセージ

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
orchestrator-Crosswork Health Manager - 010689d1-8842-43c2-8ebd-
5d91ded9d2d7 cw-ztp-service-0-0 ' cw-ztp-service-0 is healthy.'

推奨

アプリケーションとライセンスをアクティブ化します。

表 9. アプリケーションのアクティブ化:失敗

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、アプリケーションをアクティブ化できない場合に発生します。マイクロサービスまたはポッドが時間内に起動しないため、アクティブ化が失敗する可能性があります。

アラームの例

なし

syslog メッセージ

なし

推奨

次の手順を実行します。

  • ジョブ履歴を確認し、アクティブ化プロセスのどこで失敗したかを特定します。起動するポッドのいずれかの開始時に失敗した場合は、ポッドを再起動します。

  • アプリケーションをアンインストールしてから、アプリケーションのインストールを再試行してください。

表 10. アプリケーションが 3 分経過しても正常な状態を維持しない

シビラティ(重大度)

[メジャー(Major)]

説明

このイベントは、アプリケーションが正常にアクティブ化されたが、アプリケーションがアクティブになってから 3 分経過してもコンポーネントが正常な状態を維持しない場合に発生します。

アラームの例

なし

syslog メッセージの例

なし

推奨

しばらく待ち、正常な状態になった場合はアラームをクリアします。しばらく経っても正常な状態にならない場合は、Cisco TAC にお問い合わせください。

Day 2 イベント

表 11. ノードドレイン:クリーンアップ

シビラティ(重大度)

情報

説明

ノードのドレインは、VM ノードを消去するか、またはノードが 5 分以上応答しない場合に発生します。ドレイン操作時に、ノードで実行されているポッドが移動されます(クラスタ化されたポッドは移動または保留状態になることがあり、単一インスタンスポッドは別のノードに移動します)。

アラームの例

  • ノードのドレインの失敗

  • ノードの削除時の k8s ETCD のクリーンアップの失敗

  • ノードの削除

syslog メッセージ

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
orchestrator-Crosswork Health Manager - b062232f-54dc-49b2-8283-
506b7bf672a6 astackserver-0-0 ' astackserver-0 health is degraded.'

推奨

操作をモニターします。ドレインが削除の結果である場合は、それぞれのノードを消去し、新しいノードを挿入します。

表 12. ノードのドレイン:失敗

シビラティ(重大度)

[メジャー(Major)]

説明

ノードのドレインは、VM ノードを消去するか、またはノードが 5 分以上応答しない場合に発生します。このイベントは、ノードのドレイン操作が失敗した場合に発生します。

アラームの例

なし

syslog メッセージの例

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
orchestrator-Crosswork Health Manager - b062232f-54dc-49b2-8283-
506b7bf672a6 astackserver-0-0 ' astackserver-0 health is degraded.'

推奨

ノードを再度消去します。

表 13. ノードの削除:失敗

シビラティ(重大度)

[クリティカル(Critical)]

説明

このシナリオでは、ハイブリッドノードの 1 つに障害が発生したと想定しています。

このイベントは、ノードが 5 分以上ダウンし、自動的にサービス停止になった場合に発生します。

このイベントは、誰かが Cisco Crosswork を使用せずに VM を停止または削除した場合か、またはそのノードへのネットワークの停止が発生した場合にトリガーされることがあります。k8s はそのノードでポッドの削除を自動的に開始します(ドレイン削除操作)。正常にクリーンアップされている間、VM ノードはダウンとマークされます。

アラームの例

  • ノード削除によるクリーンアップの失敗

  • ノードの削除時の K8S ETCD のクリーンアップの失敗

syslog メッセージ

なし

推奨

障害が発生したノードを消去し、新しい VM を挿入します。

表 14. ノードの削除:クリーンアップの失敗

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、ドレイン削除が失敗すると発生します。ノードが 5 分以上ダウンしていると、k8s はそのノードのポッドの削除を自動的に開始します。

アラームの例

なし

syslog メッセージの例

なし

推奨

ノードを消去し、別のクリーンアップ操作を試行します。

表 15. リソースのフットプリントの不足

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、クラスタノードリソースの使用率が高く、リソースフットプリントが不足している場合に発生します。

アラームの例

なし

syslog メッセージの例

なし

推奨

新しいワーカーノードを追加します。

表 16. アプリケーションの非アクティブ化:成功

シビラティ(重大度)

[マイナー(Minor)]

説明

このイベントは、アプリケーションが非アクティブ化されると発生します。

アラームの例

なし

syslog メッセージの例

<time_stamp> <hosting_hybrid_node> <time_stamp> <crosswork_VIP>
CLUSTER-CLUSTER - ade982ea-7f60-4d6b-b7e0-ebafc789edee CLUSTER-99
© 2021 Cisco and/or its affiliates. All rights reserved. Cisco Confidential – DRAFT version 1
'user=admin,policyId=admin,backend=local,loginTime=2021-02-
28T09:34:54Z,job_type=UNINSTALL_APPLICATION,manager=app_manager:
,payload={"application_id":"capp-ztp"} [accepted]'

推奨

なし

表 17. アプリケーションの非アクティブ化:失敗

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、アプリケーションを非アクティブ化できない場合に発生します。これは、マイクロサービスまたはポッドがまだ実行中の場合に発生する可能性があります。

アラームの例

なし

syslog メッセージ

なし

推奨

次の手順を実行します。

  • ジョブ履歴を確認し、アクティブ化プロセスのどこで失敗したかを特定します。起動するポッドのいずれかの開始時に失敗した場合は、ポッドを再起動します。

  • アプリケーションをアンインストールしてから、アプリケーションのインストールを再試行してください。

表 18. ネットワークでの低速ディスクまたは遅延の問題

シビラティ(重大度)

[クリティカル(Critical)]

説明

このイベントは、インフラストラクチャ Capp の展開に 1.5 分以上かかった場合か、または Docker プッシュの完了に 2 分以上かかった場合に発生します。

このメッセージは、firstboot.log ファイルで確認できます。

アラームの例

N/A

syslog メッセージの例

N/A

推奨

この問題は、システムでさらに操作を行う前に対処する必要があります。次の手順を実行します。

  • ディスクストレージとネットワークの SLA 要件が満たされていることを確認します。

  • 確認した帯域幅が、ノード間でプロビジョニングされた帯域幅と同じであることを確認します。

  • RAID を使用している場合は、RAID 0 であることを確認します。


(注)  


ハードウェアがディスク SLA を満たそうとしていることを確認するために、1 回限りのチェックが実行されます。これが失敗すると、クリティカルなアラームが発行されます。ユーザーは、必要に応じてアラームに対処し、手動でアラームをクリアできます。


表 19. ETCD のクリーンアップ

シビラティ(重大度)

情報

説明

このイベントは、誰かが VM ノードを消去し、ETCD クリーンメンバーシップのクリーンアップ操作が開始された場合に発生します。

アラームの例

ETCD のクリーンアップが失敗した場合:

  • ノードの削除時の K8S ETCD のクリーンアップの失敗

  • アラームノードの削除

syslog メッセージ

なし

推奨

モニター操作。

表 20. ノードの削除時の K8S ETCD のクリーンアップの失敗

シビラティ(重大度)

[メジャー(Major)]

説明

このイベントは、ETCD クリーンアップ操作が失敗した場合に発生します。

アラームの例

なし

syslog メッセージの例

なし

推奨

ノードを再度消去します。

表 21. マイクロサービスの再起動:失敗

シビラティ(重大度)

警告(Warning)

説明

このイベントは、誰かがマイクロサービスまたはポッドを再起動し、操作が失敗したときに発生します。

アラームの例

なし

syslog メッセージの例

なし

推奨

マイクロサービスまたはポッドを再起動します。回復するかどうかを確認するために、これを数回行う必要がある場合があります。

トラップ処理の有効化

UI オプション、REST API、および Syslog に加えて、Cisco Crosswork は、アプリケーションとクラスタの正常性を通知するイベント/アラームの SNMP トラップを生成する機能も提供します。

Crosswork は、SNMPv3 および SNMPv2 を使用してトラップを送信することをサポートしています。アラームとイベントは、ユーザーが設定した条件に基づいてフィルタリングされ、トラップに変換され、CISCO-EPM-NOTIFICATION-MIB のアラームモデルを使用してトラップサーバーに送信されます(トラップサーバーを設定を参照)。詳細については、Cisco EPM Notification MIBを参照してください。

監査情報の収集

監査ログは、システムで実行されたすべての重要なユーザーアクションにユーザー情報をマッピングします。アプリケーションの Showtech ログを表示するには、「プラットフォーム インフラストラクチャとアプリケーション正常性のモニター」を参照してください。

監査ログには、次の操作に関連するユーザーアクションが含まれます。

  • デバイスのオンボーディング

  • ユーザーの作成、削除、および設定の更新

  • Crosswork Data Gateway の管理操作

  • 収集ジョブの作成

  • 管理タスク(show-tech の実行、トポロジの更新、NSO 関連のアクション)

  • Cisco Crosswork Change Automation and Health Insights

    • プレイブック(インポート、エクスポート、または削除)とプレイブックの実行の管理


      (注)  


      プレイブックの実行要求が送信されると、Change Automation は監査ログを出力します。監査ログには、プレイブック名、ユーザー情報、セッションの詳細、ジョブの実行 ID などの詳細が含まれます。Change Automation がプレイブックのメンテナンスタスクを実行すると、監査ログも出力します。メンテナンス監査ログには、実行 ID などの詳細が含まれています。NSO でコミットを実行する場合、メンテナンス監査ログの詳細にはコミットラベルも含まれます。監査ログを使用して、実行 ID に関連付けられたすべてのコミットラベルを特定できます。コミットラベルを使用して、NCS CLI でルックアップを実行します。ルックアップには、Change Automation がデバイスにプッシュした設定変更がそのまま表示されます。


    • KPI、KPI プロファイル、アラートグループの作成、削除、設定の更新

    • KPI プロファイルの有効化と無効化

  • Cisco Crosswork 最適化エンジン

    • SR-TE ポリシーおよび RSVP TE トンネルの作成、削除、および設定の更新

    • アフィニティマッピングの設定

    • オンデマンド帯域幅および帯域幅最適化機能と設定の更新

    • RESTCONF API の作成、削除、および設定の更新

Cisco Crosswork Change Automation and Health Insights 監査ログエントリの例

次に、ローカル管理者ユーザーがプレイブックを実行したときに作成される監査ログエントリの例を示します。

time="2020-06-09 21:24:31.103312" level=info msg="playbook scheduled for execution" backend=local execution_id=1591737871096-a6699d03-8264-4ea8-8f6f-03e8a58f32a3 latency=11.330355ms loginTime="2020-06-09T20:27:11Z" method=POST playbook="router_config_traffic_steering" policyId=admin set_id=5405fdb1-6b37-41cb-94a3-32b180d3b773 set_name=static-acl-b180d3b773 tag="ROBOT_manager-nca-7689b-fdn8g" user=admin

Cisco Crosswork 最適化エンジン 監査ログエントリの例

Crosswork 最適化エンジン UI 監査ログエントリの例

2020-06-12 02:48:07,990 INFO c.c.s.o.e.AuditLogger [http-nio-8080-exec-3] time=2020-06-12 02:48:07.000990 message=SR Policy created successfully. user=admin policyId=admin backend=local loginTime=1591929794 {data={"headEnd":"192.168.0.2","endPoint":"192.168.0.6","color":"999","description":"","profileId":"","bindingSid":"333", "path":{"type":"dynamic","pathName":"Automation_validating_sr","metric":"IGP", "affinity":[{"constraintType":"EXCLUDE_ANY","affinity":[31]}],"disjointness":{"disjointType":"", "associationGroup":"","subId":""}, "protectedSegment":"SEG_PROTECTED"}}}

Crosswork 最適化エンジン RESTCONF API 監査ログエントリの例

time="2020-06-06 13:49:06,308" message="action=/operations/cisco-crosswork-optimization-engine-sr-policy-operations:sr-policy-delete, input={\"input\": {\"sr-policies\": [{\"head-end\": \"192.168.0.2\", \"end-point\": \"192.168.0.3\", \"color\": 301}]}}, output={\"cisco-crosswork-optimization-engine-sr-policy-operations:output\":{\"results\": [{\"head-end\":\"192.168.0.2\",\"end-point\":\"192.168.0.3\",\"color\":301, \"message\":\"SR policy  not found in Config DB\",\"state\":\"failure\"}]}}" user=admin policyId=admin backend=local loginTime=1591451346 method=POST url=/operations/cisco-crosswork-optimization-engine-sr-policy-operations:sr-policy-delete
表 22. 監査ログの共通入力フィールド
フィールド 説明

time

Crosswork がこの監査ログを作成した時刻。

message

アプリケーション間で送信されるメッセージ。

msg

アプリケーション間で送信されるメッセージ。

user

ユーザー名。

policyId

ユーザーのロールまたは権限(ローカルデータベース、TACACS、または LDAP サーバーから取得)。

backend

ユーザーを認証するサーバー(ローカルデータベース、TACACS、または LDAP)。

loginTime

ユーザーがログインした epoch 時間。epoch 時間は日付型よりも期間が短く、タイムゾーンに依存しないため、意図的に選択されます。

その他のフィールド

個々のアプリケーションは、そのアプリケーションに固有のフィールドをより多く使用します。次に例を示します。

  • Cisco Crosswork Change Automation and Health Insights の監査ログエントリの例では、[プレイブック(playbook)] フィールドは、Change Automation が実行したプレイブックを参照します。

  • Crosswork 最適化エンジン の UI 監査ログエントリでは、[データ(data)] は SR-TE ポリシーとその属性の作成の詳細を参照するフィールドです。

監査ログの場所

Crosswork は、監査ログをそれぞれのアプリケーションポッドの下の /var/log/audit/audit.log に保存します。次に例を示します。

  • 変更自動化 監査ログの例は、ポッドの下の <robot-nca> データディレクトリにあります。

  • Crosswork 最適化エンジン UI 監査ログの例は、optima-uiservice ポッドにあります。 RESTCONF API 監査ログは optima-restconf ポッドの下にあります。

個々のアプリケーション監査ログに加えて、Cisco Crosswork はすべての監査ログファイルを 1 時間に 1 回収集します。Crosswork は、これらのファイルを gzip で圧縮された個別の tar ファイルとして /mnt/robot_datafs/<app-name>/<instance>/auditlogs/auditlogs.tar.gz データディレクトリに保存します。

Crosswork は、アプリケーションごとに指定された最大サイズとバックアップ数に基づいて監査ログファイルを収集します。例:MaxSize:20 megabytesMaxBackups: 5.

監査ログの表示

[監査ログ(Audit Log)] ウィンドウは、次の AAA 関連のイベントを追跡します。

  • ユーザーの作成、削除、更新

  • ロールの作成、削除、更新

  • ユーザー ログイン アクティビティ:ログイン、ログアウト、アクティブセッション最大制限によるログイン失敗、ログイン試行失敗によるアカウントロック。

  • [送信元IP(Source IP)]:アクションが実行されたマシンの IP アドレス。この列は、[監査のために送信元IPを有効にします(Enable source IP for auditing)] チェックボックスをオンにして、Cisco Crosswork に再ログインした場合にのみ表示されます。このチェックボックスは、[管理(Administration)] > [AAA] > [設定(Settings)] ページの [送信元IP(Source IP)] セクションにあります。

  • ユーザーによるパスワード変更

監査ログを表示するには、次の手順を実行します。

手順


ステップ 1

メインメニューから、[管理(Administration)] > [監査ログ(Audit Log)] を選択します。

[監査ログ(Audit Log)] ウィンドウが表示されます。

ステップ 2

[フィルタのクリア(Clear Filter)] アイコン をクリックして、クエリに基づいて結果をフィルタリングします。