RCI障害モデル(API)
「プラットフォーム>開発者」セクションにあるWebインターフェイスから、完全なApstra APIドキュメントにアクセスできます。
- ブループリントは、0 つ以上の根本原因の識別インスタンスに関連付けられています。
- ブループリントの下の根本原因識別サブリソースの CRUD API を介して、根本原因の特定インスタンスが有効(作成)/無効(削除)されます。
- 作成できるインスタンスは、ブループリントのリファレンスデザインによって異なります。根本原因の特定のこの第 1 フェーズでは、根本原因の特定をサポートしているのは two_stage_l3closのみで、現在はブループリントごとに 1 つの根本原因識別インスタンスのみを許可しています。
根本原因の特定インスタンスの作成
POST /api/blueprints/<blueprint_id>/arca
Request Payload schema
{
"model_name": s.String() # Name of ARCA instance's system fault model (ref
design specific)
"trigger_period": s.Float(min=10.0) # ARCA instance runs every <trigger_period>
seconds.
}
参照設計two_stage_l3closのブループリントの例:
{
"model_name": "default",
"trigger_period": 10.0
}
Return values:
201 - Successfully created the RCI instance. Response payload:
{"id": <RCI instance ID>}
The ID is used in GET, PUT, DELETE
404 - Blueprint does not exist or is not deployed
422 - Validation error. Response payload:
{"error": <message>}
Possible error messages:
Model name is not found for the reference design
An ARCA instance already exists for given model name
trigger_period is too small
根本原因の特定インスタンスの更新
PUT API を使用すると、根本原因の特定インスタンスの実行頻度を微調整できます。
PUT /api/blueprints/<blueprint_id>/arca/<arca_id>
Request Payload schema
{
"trigger_period": s.Float(min=10.0)
}
Return values:
200 - Update succeeded.
404 - ARCA instance not found.
422 - Validation error. Response payload:
{"error": <message>}
Possible error messages:
trigger_period is too small
根本原因識別インスタンスの削除
GET API を使用すると、根本原因識別インスタンスの現在のステータス(根本原因のセット)を取得できます。
GET /api/blueprints/<blueprint_id>/arca/<arca_id> Return values: 200 - see response schema below 404 - ARCA instance not found
Response payload schema
{
"id": String, # ARCA instance ID
"model_name": String, # see POST payload
"trigger_period": Float, # see POST payload
"state": Enum("created", "operational"),
"config_updated_at": Timestamp # of last update to instance via POST/PUT
"status_updated_at": Timestamp # of last update to ARCA results
"root_cause_count": Integer(min=0) # Number of root causes identified
"root_causes": List(ROOT_CAUSE_OBJ) # Actual root causes
}
タイムスタンプはUTCタイムゾーンのISO8601形式で、例えば「2018-10-16T22:12:34+0000」、状態==「作成」の場合、Status_updated_at== UNIXスライブroot_cause_count == 0 「root_causes」キーは返されません。
各ROOT_CAUSE_OBJには、次のスキーマがあります。
{
"id": String, # Unique ID for the root cause in the ARCA instance
"context": String, # Encoded context such as references to graph nodes
"description": String, # Human-readable text, e.g. "link <blah> broken"
"timestamp": Timestamp, # of when RC is detected (ISO8601 format)
"symptoms": List(SYMPTOM_OBJ), # List of symptoms; always non-empty
}
根本原因の検出と ID に関するメモ:ブループリントの有効期間中に、根本原因が複数回検出されることがあります。たとえば、スパイン1とリーフ1の間の壊れたケーブルに根本原因が定義されています。この根本原因はいつでも現れ、問題が修正されると消える可能性があります。根本原因には、ARCA インスタンスで有効な一意の ID があります。つまり、問題の発生か修復されたかに対応して ID が表示され、消える可能性があることを意味します。例えば、ケーブルが壊れたり、再接続されたりする根本原因 ID として期待するもの:two_stage_l3clos、根本原因 ID はグラフ ノードと関係 ID の構成であり、根本原因は不変だが読み取り可能な名前です。例:<グラフ リンク ノード id>/壊れています。
各SYMPTOM_OBJには、次のスキーマがあります。
{
"id": String, # Unique ID for the symptom in the ARCA instance
"context": String, # Encoded context such as system ID, service name
"description": String, # Readable, e.g. "interface swp1 on leaf1 is down"
}
同じ ARCA システム障害モデルを考えると、症状 ID のセットは、特定の根本原因に対して常に同じです。ただし、コンテキストは異なる場合があります。たとえば、「leaf1のインターフェイスswp1がダウンしている」という症状は同じですが、この症状の異なるインスタンスのコンテキストでは、この症状の根本原因が検出された場合にリーフ1に割り当てられたシステムIDに応じて、異なるシステムIDを持つ場合があります。症状 ID の例:<graph interface node id>/down
根本原因の特定インスタンスのリスト
GET /api/blueprints/<blueprint_id>/arca Return values 200 - see response schema below 404 - blueprint not found or blueprint not deployed
応答スキーマ:
{
"items": List(ARCA_INSTANCE_DIGEST), # list may be empty
}
ARCA_INSTANCE_DIGESTは、GET 個々の ARCA インスタンスの応答ペイロードと同じスキーマを持ちますが、「root_causes」キーが含まれていない点が異なります。
このフェーズでは、two_stage_l3closブループリントでは、ブループリントごとに1つのARICAインスタンスしか許可されないため、リストには最大1つの要素があります。