프로브(API)
일반 프로브 REST API
아래 정보는 Apstra API 규칙에 이미 익숙한 사람을 위해 IBA를 사용하는 방법을 이해하는 데 필요한 만큼의 API에 대해 설명합니다. 공식적인 API documenation은 API 설명서 자체에 대해 예약됩니다.
소개에서 설명한 워크플로우 예제에 사용되는 API를 살펴보면서 구체적인 예를 통해 일반적인 기능을 시연할 수 있습니다.
프로브 생성
프로브를 생성하려면 운영자 POST가 다음 형식으로 을( /api/blueprints/<blueprint_id>/probes 를) 수행합니다.
{
"label": "server_tx_bytes",
"description": "Server traffic imbalance",
"tags": ["server", "imbalance"],
"disabled": false,
"processors": [
{
"name": "server_tx_bytes",
"outputs": {
"out": "server_tx_bytes_output"
},
"properties": {
"counter_type": "tx_bytes",
"graph_query": "node('system', name='sys').out('hosted_interfaces').node('interface', name='intf').out('link').node('link', link_type='ethernet', speed=not_none()).in_('link').node('interface', name='dst_intf').in_('hosted_interfaces').node('system', name='dst_node', role='server').ensure_different('intf', 'dst_intf')",
"interface": "intf.if_name",
"system_id": "sys.system_id"
},
"type": "if_counter"
},
{
"inputs": {
"in": "server_tx_bytes_output"
},
"name": "std",
"outputs": {
"out": "std_dev_output"
},
"properties": {
"ddof": 0,
"group_by": []
},
"type": "std_dev"
},
{
"inputs": {
"in": "std_dev_output"
},
"name": "server_imbalance",
"outputs": {
"out": "std_dev_output_in_range"
},
"properties": {
"range": {
"max": 100
}
},
"type": "range_check"
},
{
"inputs": {
"in": "std_dev_output_in_range"
},
"name": "server_imbalance_anomaly",
"outputs": {
"out": "server_traffic_imbalanced"
},
"type": "anomaly"
}
],
"stages": [
{
"name": "server_tx_bytes_output",
"description": "Collect server tx_bytes",
"tags": ["traffic counter"],
"units": "Bps"
}
]
}
위에서 볼 수 있듯이 엔드포인트에는 프로브 메타데이터, 프로세서 인스턴스 목록 및 출력 단계 목록의 입력이 제공됩니다.
프로브 메타데이터는 다음 필드로 구성됩니다.
| label | 사람이 읽을 수 있는 프로브 레이블, 필수 |
| description | 프로브에 대한 선택적 설명입니다. |
| tags | 프로브 태그가 있는 문자열 목록; 선택적 |
| disabled | 선택적 boolean을 사용하여 프로브를 비활성화해야 하는지 여부를 알려줍니다. 비활성화된 프로브는 데이터를 제공하지 않으며 리소스를 소비하지 않습니다. 프로브는 기본적으로 비활성화되지 않습니다. |
각 프로세서 인스턴스에는 인스턴스 이름(사용자 정의), 프로세서 유형(플랫폼 및 참조 설계에 의해 정의된 카탈로그의 선택) 및/또는 outputs이inputs(가) 포함됩니다. 각 프로세서의 모든 추가 필드는 해당 프로세서 유형에 properties 따라 지정되며, 하위 필드에 지정되며, 내성 API를 통해 내성 API/api/blueprints/<blueprint_id>/telemetry/processors를 통해 학습할 수 있습니다. 나중에 이 API를 진행합니다.
작업 예와 일치하면 위 예제의 프로세서 목록에 있는 각 항목을 확인합니다.
첫 번째 엔트리에는 이름을 지정server_tx_bytes하는 유형의 프로세서 인스턴스 if_counter 가 있습니다. 은(는) 그래프 쿼리인 라는 graph_query 쿼리를 입력으로 합니다. 그리고 그리고 라는 두 개의 다른 필드 interface 가 있습니다system_id. 이 세 필드는 함께 시스템의 모든 서버 대면 포트에 대한 (최초 파생) 카운터를 수집하려는 것을 나타냅니다. 에 의해 graph_query지정된 쿼리의 모든 일치에 대해, 결과 경로(프로세서 필드에 지정된 대로)와 인터페이스 이름에서 노드 필드sys(프로세서 필드에 지정됨system_id)를 취 if_name intf interface 하여 system_id 추출 system_id 합니다. 시스템 ID와 인터페이스의 조합은 네트워크에서 인터페이스를 식별하는 데 사용되며, (에 의해 counter_type지정됨) 해당 tx_bytes 카운터는 이 프로세서의 출력에 배치됩니다. 이 프로세서의 출력은 NS(Number Set)라는 유형입니다. 단계 유형은 나중에 전면적으로 논의됩니다. 이 프로세서는 입력이 없으므로 필드를 공급 input 하지 않습니다. 레이블이 out 지정된 출력이 하나 있으며(if_counter 프로세서 유형으로 정의됨), 해당 출력을 레이블이 지정된 단계로 매핑합니다server_tx_bytes_output.
두 번째 프로세서는 유형 std_dev 이며, 이전에 server_tx_bytes_output생성한 단계를 입력으로 합니다. 은(는) 필드의 ddof 의미에 대한 프로세서별 설명서를 참조하십시오. 또한 필드의 전체 의미 group_by 에 대한 프로세서별 설명서를 참조하십시오. 지금은 이 경우 group_by 입력 NS에서 단일 출력 "Number"(N)를 구성하도록 지시하는 것으로 충분합니다. 즉, 이 프로세서는 여러 입력 번호에서 취해진 단일 번호 표준 편차를 출력합니다. 이 출력은 "std_dev_output"로 명명됩니다.
세 번째 프로세서는 유형 range_check 이며 입력std_dev_output으로 걸립니다. 입력이 지정된 range 예상 범위를 벗어나는지 확인합니다. 이 경우 입력이 100보다 큰 경우(서버 방향 트래픽의 불균형 여부를 나타내기 위해 이 임의 값을 선택했습니다). 이 프로세서에는 레이블std_dev_output_in_range을 지정하기로 선택한 단일 출력이 있습니다. 이 출력은 (range_check 프로세서 유형으로 정의됨) 유형 DS(개별 상태)이며, 값이 범위를 벗어나는지 여부를 나타내는 또는 false중 하나를 true 취할 수 있습니다.
최종 프로세서는 유형 anomaly 이며 입력std_dev_output_in_range으로 이루어집니다. 입력 true 이 상태일 때 Apstra 이상을 발생합니다. 이 프로세서에는 레이블server_traffic_imbalanced을 지정하기로 선택한 단일 출력이 있습니다. 이 출력(이상 프로세서 유형에 의해 정의됨)은 DS 유형(개별 상태)이며, 또는 false을(를) 통해 이상 발생 여부를 나타내는 값을 true 취할 수 있습니다. 이 예에서 이 비정상적인 상태 데이터로 더 이상 처리를 수행하지는 않지만, 이것이 일반적인 가능성을 배제하지는 않습니다.
마지막으로, 필드가 있습니다 stages . 이것은 출력 단계의 하위 집합 목록이며, 각 단계는 스테이지 레이블을 name 가리키는 필드로 표시됩니다. 이 목록은 DAG 자체에서 추론할 수 없는 각 출력 단계에 메타데이터를 추가하기 위한 것입니다. 현재 지원되는 필드는 다음과 같습니다.
| description | 단계 설명이 있는 문자열입니다. |
| tags | 단계에 대한 태그 집합을 만드는 문자열 목록, |
| units | 은(는) 무대 데이터의 단위를 설명하기 위한 문자열입니다. |
이러한 모든 필드는 선택 사항입니다.
REST API를 통해 해당 단계에서 데이터를 가져오고 GUI가 시각화에 사용할 때 이 단계 메타데이터가 반환됩니다.
HTTP POST는 으로 /api/blueprints/<blueprint_id>/probes전송할 수 있습니다. 여기서는 새로운 프로브를 생성하기 위한 "프로브 생성을 위한 POST" 그림의 예와 같이 프로브 구성을 게시합니다. 이 엔드포인트에 POS팅하면 Apstra의 다른 생성 엔드포인트의 대부분과 같이 UUID가 반환되며, 이는 추가 작업에 사용될 수 있습니다.
버전 2.3에서 변경됨: 위에서 설명한 UUID 대신 예측 가능한 프로브 ID를 얻으려면 요청 본문에 "id" 속성을 추가하여 이를 지정할 수 있습니다.
{
"id": "my_tx_bytes_probe",
"label": "server_tx_bytes",
"processors": [],
"rest_of_the": "request_body"
}
버전 2.3에서 변경됨: 이전에는 스테이지 정의가 다음과 같은 프로세서 정의에 포함되었습니다.
{
"label": "test probe",
"processors": [
{
"name": "testproc",
"outputs": {"out": "test_stage"},
"stages": [{"name": "out", "units": "pps"}]
}
]
}
이것은 더 이상 작동하지 않으며, 무대 이름은 내부 무대 이름 대신 무대 레이블을 참조해야 합니다. 따라서 위의 예는 다음과 같이 봐야 합니다.
{
"stages": [{"name": "test_stage", "units": "pps"}]
}
추가 사항: 인라인 스테이지 정의를 프로세서 정의에 입력하지 말고 위의 POST 예제와 같이 독립 실행형 요소로 배치하는 것이 좋습니다.
HTTP DELETE는 에 /api/blueprints/<blueprint_id>/probes/<probe_id> 의해 지정된 프로브를 삭제할 위치로 전송될 수 있습니다 probe_id.
HTTP GET는 POSTed로 프로브 구성을 검색하기 위해 /api/blueprints/<blueprint_id>/probes/<probe_id> 전송될 수 있습니다. 프로브 생성에서 지정된 것보다 더 많은 필드가 포함됩니다.
| id | 은(는) 프로브 id(또는 생성 시간에 지정되지 않은 경우 UUID)를 통해 |
| state | 프로브의 실제 상태를 확인합니다. 가능한 값은 구성되는 프로브에 대해 "생성"되고, 성공적으로 구성된 프로브에 대해 "작동"하며, 프로브 구성에 실패하면 "오류"가 발생합니다. |
| last_error | 에는 "오류" 상태의 프로브에 대한 가장 최근의 오류에 대한 자세한 오류 설명이 포함되어 있습니다. 다음과 같은 하위 필드가 있습니다.
|
HTTP GET 요청을 에 발행하여 전체 프로브 메시지 목록을 얻을 수 있습니다 /api/blueprints/<blueprint_id>/probes/<probe_id>/messages.
메시지는 '타임스탬프' 필드로 정렬되며 가장 오래되었습니다.
또한 HTTP GET를 전송하여 /api/blueprints/<blueprint_id>/probes 청사진 <blueprint_id>에 대한 모든 프로브를 검색할 수 있습니다.
2.3
프로브에 대한 HTTP 패치 및 PUT 방법은 Apstra 버전 2.3 이후 사용할 수 있습니다.
HTTP 패치를 전송하여 /api/blueprints/<blueprint_id>/probes/<probe_id> 프로브 메타데이터를 업데이트하거나 프로브를 비활성화하거나 활성화할 수 있습니다.
{
"label": "new server_tx_bytes",
"description": "some better probe description",
"tags": ["production"],
"stages": [
{
"name": "server_tx_bytes",
"description": "updated stage description",
"tags": ["server traffic"],
"units": "bps"
}
]
}
이 예에서는 위에 나열된 POST 요청으로 생성된 프로브에 대한 프로브 메타데이터를 업데이트합니다. 여기에 있는 모든 필드는 선택 사항이며, 지정되지 않은 값은 변경되지 않습니다.
또한 모든 단계 인스턴스는 선택 사항입니다. 즉, 지정된 단계만 업데이트되며 지정되지 않은 단계는 변경되지 않습니다.
태그 수집이 완전히 업데이트됩니다. 즉, 패치 페이로드가 지정된 tags: ["c"]경우tags: ["a", "b"], 결과 컬렉션은 (NOTtags: ["a", "b", "c"])처럼 tags: ["c"] 보입니다.
패치를 사용하면 프로브의 프로세서 및 단계를 변경할 수 없습니다. 자세한 내용은 PUT 설명에 대해 자세히 알아보시기 바랍니다.
HTTP PUT를 전송하여 /api/blueprints/<blueprint_id>/probes/<probe_id> 프로브를 교체할 수 있습니다.
이것은 POST와 매우 유사하며, 프로브 <probe_id> 에 대한 이전 구성을 페이로드에 지정된 새 구성으로 대체한다는 점이 다릅니다. 이 요청에 대한 페이로드 형식은 POST와 동일하지만 id 허용되지 않습니다.
프로브 검사
단계는 다양한 프로세서의 입력 및 출력에 명명됨으로써 암묵적으로 생성됩니다. 프로브의 다양한 단계를 검사할 수 있습니다. 특정 단계를 읽기 위한 API는 /api/blueprints/<blueprint_id>/probes/<probe_id>/stages/<stage_name>
각 단계에는 유형이 있습니다. 이는 생성 프로세서 및 해당 프로세서에 대한 입력 단계의 기능입니다. 유형은 다음과 같습니다: 번호(N), 번호 타임 시리즈(NTS), 번호 설정(NS), 번호 설정 타임 시리즈(NSTS), 텍스트(T), TTS(Text Time Series), 텍스트 세트(TS), TSTS(Text Set Time Series), 개별 상태(DS), DSTS(Discrete State Time Series), DSS(Discrete State Set), DSSTS(이산 세트 타임 시리즈)
NS는 바로 숫자 집합입니다.
마찬가지로 DSS는 개별 상태 변수 집합입니다. DSS(및 DSSTS) 단계 사양의 일부는 개별 상태 변수가 취할 수 있는 가능한 값입니다.
텍스트 세트는 문자열 집합입니다.
NSTS는 숫자가 값으로 포함된 타임 시리즈 세트입니다. 예를 들어, 이 세트의 멤버는 (시간=0초, 값=3), (시간=3초, 값=5), (시간=6초, 값=23) 등입니다.
DSTS는 이산 상태인 값을 제외하고 NSTS와 동일합니다.
TSTS는 문자열을 제외한 NSTS와 동일합니다.
숫자(N), DS(Discrete State) 및 텍스트(T)는 단순히 숫자 세트, 개별 상태 세트 및 텍스트 세트가 길이 1로 보장됩니다.
NTS, DSTS 및 TS는 위와 동일하지만 단일 값이 아닌 타임 시리즈입니다.
첫 번째 단계인 "server_tx_bytes"을 고려해 보죠. 이 단계에는 시스템의 모든 서버 대면 포트에 대한 tx_bytes 카운터가 포함됩니다. URL에서 얻을 수 있습니다. /api/blueprints/<blueprint_id>/probes/<probe_id>/stages/server_tx_bytes_output
받는 응답은 다음과 동일한 형식입니다.
{
"properties": [
"interface",
"system_id"
],
"type": "ns",
"units": "bytes_per_second",
"values": [
{
"properties": {
"interface": "intf1",
"system_id": "spine1"
},
"value": 22
},
{
"properties": {
"interface": "intf2",
"system_id": "spine1"
},
"value": 23
},
{
"properties": {
"interface": "intf1",
"system_id": "spine3"
},
"value": 24
}
]
}
실행 예에서 알 수 있듯이 "server_tx_bytes" 단계에는 네트워크의 모든 서버 대면 인터페이스에 대한 tx_bytes 값이 포함되어 있습니다. 위의 예를 보면, 이 단계는 NS 또는 Number-Set을 나타내는 "ns"의 유형임을 알 수 있습니다. 앞서 언급했듯이 단계별 데이터는 컨텍스트와 관련이 있습니다. 즉, 단계 집합의 모든 요소가 키-값 쌍 그룹과 연결되어 있음을 의미합니다. 모든 단계에서 키는 모든 데이터 조각(또는 이와 동등한 세트의 항목)에 대해 동일합니다. 이러한 키는 주어진 단계의 "속성" 필드에 나열되며 일반적으로 생성 프로세서의 기능입니다. "값"의 각 항목은 단계의 각 속성에 값을 할당하고 값("번호 설정"의 "번호")을 제공합니다. 이 단계에서 이 데이터의 의미는 spine1의 intf1에서 tx_bytes 22개, spine1의 intf2는 23개이고, Spine3의 intf1에서는 초당 24바이트입니다.
실행 중인 예에 명시된 대로 이 단계에 대해 "유닛"이 설정됩니다.
프로브의 두 번째 단계를 쿼리하려면 HTTP GET를 std 엔드포인트 /api/blueprints/<blueprint_id>/probes/<probe_id>/stages/std_dev_output로 보냅니다.
{
"type": "n",
"units": "",
"value": 1
}
이 단계는 숫자입니다. 컨텍스트가 없고 단일 값만 있습니다. 예를 들어, 이는 모든 스파인의 표준 편차입니다.
프로브의 끝에서 두 번째 단계는 엔드포인트 /api/blueprints/<blueprint_id>/probes/<probe_id>/stages/server_traffic_imbalanced에서 쿼리할 수 있습니다.
{
"possible_values": [
"true",
"false"
],
"type": "ds",
"units": "",
"value": false
}
표시된 바와 같이, 이 단계는 서버 트래픽이 모든 서버 대면 포트의 tx_bytes 전반의 표준 편차가 100보다 큰지를 나타내어 서버 트래픽이 불균형("true") 인지 아닌지("거짓")인지를 나타냅니다. "possible_values" 필드는 이산 상태 "값"이 취할 수 있는 모든 값을 설명합니다.
프로브의 모든 프로세서는 을(를) 통해 /api/blueprints/<blueprint_id>/probes/<probe_id>/processors/<processor_name>쿼리할 수도 있습니다. 이러한 쿼리를 수행하면 해당 프로세서를 생성하는 데 사용되는 구성을 확인할 수 있습니다.
쿼리 프로브 이상
예제 프로세서의 마지막 단계는 서버 대면 인터페이스 전반에서 tx_bytes 표준 편차가 100보다 클 때 Apstra Anomaly를 높이고 출력을 "true"로 설정합니다.
에서 표준 이상 API /api/blueprints/<bluprint_id>/anomalies?type=probe를 통해 프로브 이상 징후를 쿼리할 수 있습니다.
다음은 예제 프로브에 의해 제기될 이상 징후의 JSON 형태입니다(이 예에서는 신경 쓰지 않는 데이터에 대한 타원 포함).
{
"actual": {
"value_int": 101
},
"anomaly_type": "probe",
"expected": {
"value_int": 100
},
"id": "...",
"identity": {
"anomaly_type": "probe",
"probe_id": "efb2bf7f-d8cc-4a55-8e9b-9381e4dba61f",
"properties": {},
"stage_id": "server_traffic_imbalanced"
},
"last_modified_at": "...",
"severity": "critical"
}
위의 예에서 볼 수 있듯이 ID에는 이상 현상이 발생했으며 운영자의 추가 검사가 필요한 단계의 이름과 probe_id 포함됩니다. 주어진 단계에서 단계 유형이 설정 기반 유형인 경우 이상 징후의 "속성" 필드가 이상 현상을 유발한 세트의 특정 항목의 속성으로 채워질 것입니다. 따라서 각 항목이 세트의 다른 항목에 있는 한 단일 단계에서 여러 가지 이상을 발생시키는 중요한 지점이 됩니다. 예를 들어, 문제의 단계는 NS 유형이므로 "속성" 필드는 설정되지 않습니다.
내성 프로세서
운영자가 사용할 수 있는 프로세서 집합은 플랫폼 및 레퍼런스 설계의 기능입니다. Apstra는 운영자가 사용 가능한 모든 프로세서를 나열하고, 어떤 매개 변수를 취하는지 학습하고, 필요한 입력과 출력을 학습할 수 있는 API를 제공합니다.
문제의 API는 에서 찾을 수 있습니다 /api/blueprints/<blueprint_id>/telemetry/processors.
프로세서 설명 목록이 표시됩니다. 다음 예에서는 std_dev 프로세서에 대한 설명을 보여줍니다.
{
"description": "Standard Deviation Processor.\n\n Groups as described by group_by, then calculates std deviation and\n outputs one standard deviation for each group. Output is NS.\n Input is an NS or NSTS.\n ",
"inputs": {
"in": {
"required": true,
"types": [
{
"keys": [],
"possible_values": null,
"type": "ns"
},
{
"keys": [],
"possible_values": null,
"type": "nsts"
}
]
}
},
"outputs": {
"out": {
"required": true,
"types": [
{
"keys": [],
"possible_values": null,
"type": "ns"
}
]
}
},
"label": "Standard Deviation",
"name": "std_dev",
"schema": {
"additionalProperties": false,
"properties": {
"ddof": {
"default": 0,
"description": "Standard deviation correction value, is used to correct divisor (N - ddof) in calculations, e.g. ddof=0 - uncorrected sample standard deviation, ddof=1 - corrected sample standard deviation.",
"title": "ddof",
"type": "integer"
},
"enable_streaming": {
"default": false,
"type": "boolean"
},
"group_by": {
"default": [
"system_id"
],
"items": {
"type": "string"
},
"type": "array"
}
},
"type": "object"
}
}
위에서 볼 수 있듯이, 문자열 기반 설명, 유형 프로세서 유형의 이름(프로브 구성에서 REST API에 제공)이 있습니다. 특정 프로브에 대한 매개 변수 집합은 "스키마"에 설명되어 있습니다.
특별 공지는 "입력"과 "출력"으로 지급되어야 합니다. 이는 "스키마" 섹션에 있지만 모든 유형의 프로세서에 존재합니다. 각 프로세서는 0개 이상의 입력 단계를 취할 수 있으며, 1개 이상의 단계를 출력해야 합니다. 선택적 단계는 "필요"로 설정됩니다. 그들이 취하는 단계 이름(프로세서의 특정 인스턴스와 상대적인)은 이러한 변수에 설명되어 있습니다. "std_dev" 프로세서는 "in"이라는 단일 입력과 "out"이라는 단일 출력을 갖는 것을 볼 수 있습니다. 이는 이전 예제에서 사용량에 반영됩니다.
하나의 특별한 입력 이름이 있습니다. * 예를 들어:
"inputs": {
"*": {
"required": true,
"types": [
{
"keys": [],
"possible_values": null,
"type": "ns"
},
{
"keys": [],
"possible_values": [],
"type": "dss"
},
{
"keys": [],
"possible_values": null,
"type": "ts"
}
]
}
}
즉, 프로세서는 임의의 이름을 가진 지정된 유형의 하나 이상의 입력을 허용합니다.
3.0에서 변경: 이전에는 입력 및 출력 섹션이 특정 입력 또는 출력이 필요한지 지정하지 않았기 때문에 형식이 다음에서 변경되었습니다.
이 구문은 더 이상 사용되지 않으며 유효하지 않습니다.
"inputs": {
"in": [
{
"data_type": "ns",
"keys": [
"system_id"
],
"value_map": null,
"value_type": "int64"
}
...
]
}
데이터 스트리밍
모든 프로브의 모든 프로세서 인스턴스는 Apstra 스트리밍 출력의 "퍼프몬" 채널에서 출력 단계를 스트리밍하도록 구성할 수 있습니다. 속성 "enable_streaming"가 모든 프로세서 구성에서 "true"로 설정된 경우, 출력 단계는 모든 데이터를 스트리밍합니다.
비시간 시리즈 기반 단계의 경우, 각 단계는 값이 변경될 때마다 메시지를 생성합니다. 타임 시리즈 기반 단계의 경우, 각각은 새로운 항목이 타임 시리즈로 생성될 때마다 메시지를 생성합니다. 세트 기반 단계에서 세트의 각 항목은 두 개의 이전 규칙에 따라 메시지를 생성합니다.
생성되는 각 메시지에는 값, 타임스탬프 및 키-값 쌍 집합이 있습니다. 그 값은 자명합니다. 타임스탬프는 비 타임 시리즈 기반 단계의 값이 변경된 시간과 타임 시리즈 기반 단계의 새 항목 타임스탬프입니다. 키-값 쌍은 단계의 "값" 섹션에서 앞에서 관찰한 "속성" 필드에 해당하므로 컨텍스트를 제공합니다.
아래에는 PerfMon 메시지(그리고 AosMessage에서 인턴)로 캡슐화된 IBA의 메시지 형식이 있습니다. 컨텍스트의 키-값 쌍은 "속성" 반복 필드(키로 "이름"와 값으로 "값")에 배치되고 값은 "값" 필드에 배치됩니다. "probe_id"와 "stage_name"은 표시됩니다. 이 blueprint_id 캡슐화된 AosMessage의 "origin_name"에 포함됩니다. 마찬가지로 타임스탬프는 일반적인 "타임스탬프" 필드에 배치됩니다.
message ProbeProperty {
required string name = 5;
required string value = 6;
}
message ProbeMessage {
repeated ProbeProperty property = 1;
oneof value {
int64 int64_value = 2;
float float_value = 3;
string string_value = 4;
}
required string probe_id = 5;
required string stage_name = 6;
}