Runtime 상태 조회와 운영 진단¶
Observability 주제 목차 · 스펙 목차 · 다음: 02. Runtime metric
특정 시점의 완전한 host·topology status, status 변화 stream과 structured log identifier의 공개 계약을 정의한다. 이 주제 안 다른 문서와의 소유 경계는 Observability 책임 지도를 따른다.
1. Runtime 상태 조회 개요¶
Application 운영자는 Framework runtime의 현재 상태를 한 번 조회하고, 이후 변화를 관찰하며, 상태가 바뀐 이유를 log에서 찾는다. Application은 이 정보로 새 작업을 받을 수 있는지와 장애 범위, relocation·shutdown 결과를 판단한다.
이 문서는 특정 시점의 완전한 status, status 변화 stream과 structured log identifier를 소유한다. 시간에 따라 누적하거나 수집하는 수치의 이름·단위·label은 Runtime metric, message 한 건의 진행 기록은 Message flow tracing, relocation과 shutdown의 상태 전이는 Host relocation과 shutdown이 소유한다. 전체 소유 지도는 주제 README를 참고한다.
2. 역할과 책임 · public 미노출 값¶
| 주체 | 책임 |
|---|---|
| Application | 등록 이름으로 status를 조회·관찰하고, logger provider와 backend를 구성한다. |
| Framework | 내부 service 값을 조합하여 완전한 status를 만들고 상태 변화의 표준 identifier를 기록한다. |
| Provider | Application이 선택한 logger backend로 log를 전달한다. Provider 실패가 runtime 결과를 바꾸지 않게 한다. |
| Remote runtime | 자신의 service 제공 가능 여부와 운영 상태를 게시한다. 현재 runtime은 이를 topology status에 반영한다. |
Remote 등록 정보가 바뀐 순서를 나타내는 descriptor revision과 host가 현재 lifecycle의 소유권을 계속 사용할 수 있음을 나타내는 owner lease는 내부 판단에만 사용한다. Public interface에는 이 두 값, 작업 수락의 내부 상태, claim, capacity reservation, socket 상태, exporter, 저장소, raw event DTO와 native handle을 노출하지 않는다.
3. Host 상태 — 한 번에 읽는 값¶
Application은 startup에 등록한 이름으로 기능별 status를 읽는다. 여러 내부 service의 값을 직접 조합하지 않는다.
처음 등장하는 등록 이름을 구분하면 다음과 같다.
- 한 process에서 RouteMesh의 peer 연결과 Channel 메시징을 제공하는 runtime 단위를 MeshNode라고 한다. 여러 MeshNode가 같은 메시징 규칙을 공유하는 논리 runtime을 RouteMesh라고 하며, RouteMesh 하나를 식별하는 startup 등록 이름을 MeshName이라고 한다.
- Channel 하나를 식별하는 startup 등록 이름을 ChannelName이라고 한다.
- Client와 Server가 ChannelName으로 요청과 reply를 교환하는 topology를 ClientServer Channel이라고 한다.
- 주소와 상태를 가지고 message를 받는 논리 실행 단위를 Spot이라고 한다.
- 기능별 serving 조건을 모두 만족하여 application message를 받을 수 있는 상태를 Ready라고 한다.
| 상태 범위 | 한 status에서 확인하는 값 |
|---|---|
| Host | Runtime state, ready 여부, 새 작업 수락 여부, deadline, relocation·shutdown 결과와 inbound dispatch 상태 |
| RouteMesh | MeshName, 전체 state, ready peer 수, Channel별 ready target 수, peer별 운영 상태와 현재 process의 Actor·Spot 수 |
| ClientServer | ChannelName, local role, 전체 state, ready target 수와 target별 운영 상태·weight |
| Automatic fanout | ChannelName, 전체 state, 연결을 시도하는 publisher 수와 ready publisher 수 |
Status는 호출이 끝난 뒤에도 보관할 수 있는 변경 불가능한 값이다. Native handle, caller buffer, payload와 application metadata를 참조하지 않으므로, 호출부가 status를 계속 들고 있어도 runtime 내부 자원을 붙잡지 않는다.
다음 C#은 공통 동작을 보여 주는 발췌다. 다른 언어에 같은 signature를 요구하지 않는다. 정확한 type과 signature는 .NET topology monitoring이 정한다.
public interface IZLinkRouteMeshRuntime
{
ZLinkRouteMeshStatus GetStatus(string meshName); // 등록한 RouteMesh의 현재 상태를 읽는다.
IAsyncEnumerable<ZLinkObservedStatus<ZLinkRouteMeshStatus>> ObserveAsync(
string meshName,
CancellationToken cancellationToken = default); // 이후의 완전한 상태와 유실 누계를 순서대로 받는다.
}
Host 상태는 특정 MeshName에 속하지 않는다. Relocation과 shutdown의 최종 결과도 host
status에서 한 번만 제공한다.
Host runtime state는 다음 값으로 닫혀 있다. 표에 없는 값을 추가해서는 안 된다. 새 작업을 차단하고 이미 수락한 작업을 제한 시간 안에 정리하는 절차를 drain이라고 한다. 그 제한 시각을 deadline이라고 한다.
| 값 | Application이 관찰하는 의미 |
|---|---|
preparing |
Startup 구성을 검증하고 runtime을 준비하고 있다. |
serving |
새 application operation을 받을 수 있다. |
relocating |
새 작업 수락을 중단하고 stateful object를 다른 node로 이전하고 있다. |
relocated |
Relocation을 끝냈으며 infrastructure와 연결은 유지한다. |
draining |
Relocation 없이 남은 처리와 resource를 정리하고 있다. |
stopped |
Runtime과 infrastructure 정리가 끝났다. |
error |
Runtime을 계속 운영할 수 없는 오류가 발생했다. |
IsReady는 State가 serving일 때만 true다. AcceptingWork는 현재 host가 새
application operation을 수락하는지를 나타내는 별개 값이며, 두 값을 서로 대신하는
조건으로 재해석하지 않는다. Relocation option, deadline과 result의 정확한 의미는
Host relocation과 shutdown이 정한다.
Host status는 relocation 뒤 source runtime을 안전하게 종료할 수 있는 시점을 나타내는
SafeToShutdown 관찰 상태를 함께 제공한다.
- Source runtime은 자기가 시작한 relocation operation에 대해, 모든 relocation unit이,
relocation 뒤에도 이전 owner에 도착한 message를 새 owner에게 대신 전달하는
Message Follow route를 제거할 수
있는 시점(follow 기간 만료 기준)에 도달하고 각 unit의 cutover 재전송 창이 끝난
뒤에만
SafeToShutdown을 자기 host status에 게시한다. 두 조건 모두 source에서 일어나는 사건이므로 이 판정에 다른 node의 시각을 사용하지 않는다. - 이 값은 target이나 다른 주체가 보내는 완료 ACK가 아니라 source가 게시하는 값이다. Deployment orchestrator는 §6의 상태 조회·변화 관찰로 이 값을 확인한다.
- 게시 전에, runtime을 종료 절차로 진입시켜 새 operation admission을 막는
Shutdown을 호출하는 것도 허용된다. 이 경우 남은 Message Follow route가 transport와 함께 사라져 이전 route를 캐시에 둔 sender의 request는Unavailable로 끝날 수 있다.
Message Follow와 cutover 재전송 창의 정의는 Actor와 Spot relocation 전체 흐름이 소유한다.
4. Host status의 capacity 항목¶
Host status의 capacity 항목은 같은 measurement epoch에서 Core HWM snapshot과, application callback 시작 전까지 host가 보유하는 공유 supply permit queue인 Application job queue snapshot을 coherent하게 읽는다. Queue를 순회해서 snapshot을 만들지 않는다.
Core HWM snapshot에서는 다음을 관찰할 수 있다 — configured memory limit·manual
budget·profile, effective budget, total applied HWM, core queue의 current·provisional·peak
accounted bytes, completion current·peak·pending, total messaging, monitor queue
applied/accounted, total instance applied/accounted bytes, blocked ratio, active
ordinary/completion/send/receive queue 수. application accounted bytes,
outstanding application lease, retired queue, deferred origin credit 네 field는
ABI 호환을 위해 남은 reserved field이며 0.13.1 이후 항상 0이다. Application byte
HWM이나 lease가 존재한다는 뜻이 아니다. Framework는 Core runtime snapshot을 그대로
투영하며 다시 계산하거나 다른 의미로 사용하지 않는다.
이 Core 의미에서 DEALER-ROUTER reply byte는 core_queue_accounted_bytes·current·provisional·
peak와 total messaging에 포함되고 Completion current·peak·pending·direction count에는 포함되지
않는다. ROUTER-ROUTER Completion connection의 reply byte만 Completion field에 포함된다. Framework
status는 Core runtime snapshot의 topology별 분류, field 이름, snapshot layout과 ABI version을
사용한다.
Application job queue snapshot에서는 다음을 관찰할 수 있다 — configured profile·manual
max, configured pause·resume percent, effective processor count·effective max, 계산된
pause·resume permit count, reserved supply permits, queued application jobs, permits in
use·peak, running|paused pressure state, current pause duration, capacity
waiter·wait count·duration. Reset은 configuration, pressure state와 current pause
duration을 유지하고 measurement epoch을 증가시키며, pressure transition count,
cumulative pause duration과 flow-state config failure count는 0으로 만든다. 동시
event는 이전 또는 새 epoch 중 정확히 하나에만 포함되며 peak는 current보다 작을 수
없다. Measurement epoch의 소유와 이 snapshot 값에 지속적으로 대응하는 계기는
Runtime metric §3이
정의하며, 이 문서는 한 시점에 무엇을 조회할 수 있는지만 다룬다.
이 status는 payload, Actor ID, Spot을 식별하는 전역 논리 주소인 Spot ID, session ID, RID, endpoint, message type이나 owner별 목록을 포함하지 않는다. Owner별 top-N은 public contract로 제공하지 않는다.
5. Topology 상태 — RouteMesh·ClientServer·automatic fanout¶
Topology state는 host state와 다른 범위를 나타낸다. Host state는 process 전체의
startup, relocation과 shutdown 진행 상태다. Topology state는 MeshName 또는
ChannelName으로 등록한 RouteMesh·ClientServer·automatic fanout 하나가 현재
application message를 처리할 수 있는지를 나타낸다.
따라서 host가 serving이어도 특정 ClientServer Channel에 ready target이 없으면 그
topology만 degraded일 수 있다. 반대로 host가 relocating, relocated 또는
draining이면 연결이 남아 있어도 모든 topology의 IsReady는 false다. 이때 연결된
peer·target 수는 현재 연결 상태를 그대로 제공한다. Host가 application traffic을 받지
않는다는 이유로 count를 0으로 바꾸지 않는다.
| 상태 종류 | 허용 값 |
|---|---|
| Topology state | starting, ready, degraded, stopping, stopped, failed |
| Topology reason | runtime_not_ready, no_ready_peer, no_ready_target, location_unavailable, capacity_exceeded, draining, internal_failure |
| Peer state | connecting, ready, draining, not_connected, not_required |
| ClientServer local role | client, server, client_and_server |
| Topology state | 의미 |
|---|---|
starting |
해당 topology의 listener, connection과 registration을 준비하고 있다. |
ready |
Host가 serving이고 해당 topology가 application message를 처리할 수 있다. |
degraded |
일부 peer·target 또는 Location Store를 사용할 수 없어 해당 topology의 기능 전부를 제공할 수 없다. |
stopping |
Host shutdown에 따라 해당 topology가 이미 수락한 작업과 연결을 정리하고 있다. |
stopped |
해당 topology의 작업과 연결 정리가 끝났다. |
failed |
해당 topology를 계속 운영할 수 없는 오류가 발생했다. |
RouteMesh peer는 node의 transport identity인 Routing ID를 Node RID 값으로 제공한다. Endpoint, descriptor revision과 connection generation은 제공하지 않는다.
Peer state는 연결이 없는 두 경우를 구분한다.
| Peer state | 의미 | Ready·장애 집계 |
|---|---|---|
not_connected |
Topology상 연결이 필요하지만 현재 ready connection이 없다. | Ready peer 수에서 제외한다. Topology degraded 여부와 liveness·health failure 집계에 반영한다. |
not_required |
두 MeshNode가 모두 Object Client이고 양쪽 모두 RouteMesh Channel Server membership이 없어 연결할 필요가 없다. Automatic은 descriptor 확인 단계에서 제외하고 Manual은 handshake에서 확인한다. | Ready peer 수에서 제외한다. Liveness probe·reconnect·health failure 집계 대상도 아니다. |
not_required peer도 status의 peer 목록에는 남긴다. 운영자는 이 값으로 정상적인
연결 생략과 연결 장애를 구분할 수 있다. 이 상태 하나만으로 RouteMesh를 degraded로
바꾸지 않는다.
RouteMesh placement 상태는 새 object 수락 여부와 현재 active Actor·Spot 수를 제공한다. Status는 Spot과 그 안에서 application message를 처리하는 Actor의 개수를 각각 제공한다. Startup에 등록한 type별 capacity reservation, Spot 초기화가 끝나기 전에 최초 message 전달을 막는 activation barrier와 내부 capacity counter는 제공하지 않는다.
Placement의 IsAvailable은 host가 serving이고 Object Server이며 placement weight가
양수이고, Actor 또는 Spot capacity와 activation concurrency에 모두 여유가 있을 때만
true다. Activation concurrency의 현재 값과 limit은 public status에 별도 field로
노출하지 않는다.
새 target 선택 비율에 사용하는 weight는 signed integer
0..10000이다. 값이 0이면 새 placement 대상으로 선택하지 않는다.
같은 process의 ClientServer Server도 remote Server와 같은 후보다. Status는 target
수와 각 target의 상태·weight를 제공한다. client_and_server는 같은 ChannelName에
두 역할이 등록되었다는 뜻이며 별도 registration role이 아니다.
Automatic fanout publisher의 ready 판정은 transport liveness §4가
소유하며, monitoring status는 그 결과를 보여 준다. Publisher별로 첫 application record 또는
liveness beacon 수신으로 ready가 시작되고
disconnect나 15초 무수신으로 끝난다는 판정은 그 문서의 규칙이다. 연결 계획이나 connect 수락만으로
ready가 되지 않는다.
6. 상태 변화를 관찰한다 — Sequence와 완전한 status¶
각 언어는 현재 status 조회와 비동기 변화 관찰을 제공한다. 이름과 type은 언어별 interface가 정한다.
var current = routeMeshRuntime.GetStatus("game-mesh");
// Readiness와 target 상태가 같은 시점에 만들어진 한 값에 들어 있다.
await foreach (var observed in routeMeshRuntime.ObserveAsync("game-mesh", cancellationToken))
{
await RecordStatusAsync(observed.Status, cancellationToken);
// observed.Loss가 이 관찰자가 지금까지 놓친 개수다.
// 관찰 코드는 routing이나 lifecycle 결정을 변경하지 않는다.
}
Status는 runtime instance 안에서 단조 증가하는 Sequence와 관찰 시각을 포함한다.
같은 source에서는 큰 Sequence가 더 나중 상태다. 서로 다른 source의 값은 비교하지
않는다. Process가 다시 시작되면 Sequence는 0부터 시작할 수 있다.
변화 stream의 각 항목은 일부 field만 담은 event가 아니라 완전한 status다. Nullable
field를 조합하는 범용 event DTO는 제공하지 않는다. 관찰자가 Sequence gap을
발견하면 현재 status를 다시 조회하여 모든 field를 복원한다.
7. 관찰자가 느릴 때 — source, 합치기, 유실 누계¶
7.1 Source의 정의¶
합치기의 단위인 source는 Sequence를 소유한 것과 같다. 각 status 항목이
Sequence 하나를 갖고 오므로, 그 Sequence를 발행하는 주체가 source다.
| Stream 종류 | Source | Source 키 |
|---|---|---|
| Host 상태 | 이 runtime instance 하나 | runtime instance ID. process 수명 동안 하나다 |
| Topology 상태 | topology runtime 하나 | RouteMesh는 MeshName, ClientServer·fanout은 ChannelName |
peer와 객체 이동은 별도 source가 아니다. 이들은 topology status 안에 목록으로
실려 오며 자기 Sequence를 갖지 않는다. peer 하나가 바뀌면 그 topology의 status
전체가 새 Sequence로 발행된다. peer별·이동별 slot을 따로 두려면 먼저 별도
stream과 언어별 계약을 정의해야 하며, 그때까지 이 합치기 규칙의 단위가 아니다.
Source 키는 그 대상이 처음 관측 대상이 될 때 만들고, terminal status가 전달되거나
폐기된 뒤 없앤다. 키가 살아 있는 동안 Sequence는 그 키 안에서 단조 증가한다.
7.2 합치기¶
Framework는 느린 관찰자 때문에 message dispatch, location claim과 host lifecycle이 지연되지 않도록 중간 status를 합칠 수 있다. 합치기는 source별 최신 status 한 자리를 유지하는 방식이다. 같은 source의 이전 중간 status는 최신 status가 대신한다. 이 경우에도 다음 결과를 보장한다.
- 보관 중인 source에 대해 가장 최근 status의
Sequence를 전달한다. - Relocation과 shutdown의 terminal status는 중간 status로 덮어쓰지 않는다.
- 한 관찰자의 지연, 취소 또는 실패가 다른 관찰자와 runtime 결과를 바꾸지 않는다.
- 누계 field는 합친 뒤에도 최신 값을 반영한다. Backpressure와 drop counter의 증가분을 합치기로 잃지 않는다.
Source별 한 자리 구조에서도 관찰자가 계속 읽지 않으면 종료된 source의 terminal status가 쌓인다. 이 보관량에는 상한이 있으며, 상한을 넘기면 framework는 가장 오래된 terminal status부터 버린다. Terminal status를 무한히 보관하는 구조는 느린 관찰자 하나가 runtime memory를 소진시키므로 허용하지 않는다.
버릴 때 관찰자가 유실을 알 수 있어야 한다. 유실 수는 관찰자마다 다르므로 status 안에 넣지 않는다 — status는 관찰자 사이에 공유하는 값이고, 여기에 관찰자별 값을 넣으면 공유할 수 없게 된다.
대신 stream이 전달하는 단위를 status와 전달 정보의 쌍으로 정의한다.
| 구성 | 내용 |
|---|---|
| status | 지금까지와 같은 완전한 status. 관찰자 사이에 공유한다 |
| 유실 누계 | 이 관찰자가 구독을 시작한 뒤 잃은 항목 수 |
유실 누계는 중간 status 합치기로 사라진 것과 terminal 폐기로 사라진 것을 각각
센다. 둘을 하나로 합치면 관찰자가 "따라잡기로 건너뛴 것"과 "영영 못 보는 것"을
구분하지 못한다. 두 counter는 구독마다 0에서 시작하고 각각 단조 증가하다
9223372036854775807(2^63 - 1)에서 포화한다. 언어의 정수 표현형은 이 관찰 범위를
바꾸지 않는다.
runtime 전체 metric은 이 값을 대신할 수 없다 — 어느 관찰자가 무엇을 잃었는지
판정하지 못하기 때문이다. 관찰자는 이 값의 증가와 Sequence gap으로 유실을 안다.
Source의 최신 slot은 그 source lifecycle이 끝나고 terminal status가 전달되거나 폐기된 뒤에 제거한다. 제거된 source는 위 "보관 중인 source"에서 빠진다.
Framework는 관찰자 queue가 가득 찼다는 이유로 stream을 종료하지 않는다. 위의 합치기와 보관 상한으로만 따라잡으며, 관찰자가 계속 느려도 stream은 열려 있다. 관찰 취소는 해당 stream만 종료한다. 이미 수락한 runtime 작업이나 다른 관찰자는 취소하지 않는다.
8. Object의 현재 위치 조회¶
운영 도구는 Actor ID 또는 Spot ID로 현재 위치를 정확히 조회하거나, 저장된 위치 정보의 관리 범위를 page 단위로 열거할 수 있다. 이 결과를 messaging target이나 placement selector로 사용하지 않는다.
위치 정보의 기준 저장소인 Location Store가 제공하는 field, page 크기와 cache 계약은 Location runtime의 운영 조회가 정한다.
ID별 조회와 page는 Creating, Ready, Unavailable entry를 같은 의미로 반환한다.
Record가 없으면 ID별 조회는 empty이고 page에는 항목이 없다. Store 조회 실패는
Unavailable Framework error이며 page 일부를 성공 결과로 반환하지 않는다.
9. Structured log¶
Framework는 상태가 바뀐 이유를 표준 structured logger에 기록한다. Application은 logger provider와 backend를 구성한다. Framework public interface는 sink, file path, exporter lifecycle과 event DTO를 제공하지 않는다.
다음 identifier는 모든 언어에서 같은 문자열을 사용한다. 그중
zlink.runtime.host.relocation_changed는 host의 stateful object를 이전할 application
version을 정하는 caller intent인
Relocation mode가 바뀔 때도
기록한다.
| Identifier | 기록하는 변화 |
|---|---|
zlink.runtime.mesh_node.state_changed |
MeshNode의 lifecycle 또는 ready 상태가 바뀌었다. |
zlink.runtime.mesh_node.peer_changed |
Peer의 작업 수락, ready 또는 service 상태가 바뀌었다. |
zlink.runtime.mesh_node.channel_changed |
Channel weight, ready target 수 또는 선택 가능 상태가 바뀌었다. |
zlink.runtime.object.placement_changed |
Reservation, Ready, abort, capacity exhaustion 또는 relocation으로 placement 집계가 바뀌었다. |
zlink.runtime.mesh_node.routing_id_conflict |
Automatic Node RID owner claim이 active conflict로 실패했다. |
zlink.runtime.host.relocation_changed |
Relocation mode, effective target version, host state 또는 terminal result가 바뀌었다. |
zlink.runtime.host.termination_changed |
Shutdown state 또는 terminal result가 바뀌었다. |
zlink.runtime.relocation.changed |
Actor 또는 Spot relocation phase·recovery 상태가 바뀌거나 한 unit의 admission 중단 시간이 1초를 넘었다. |
zlink.runtime.client_server.state_changed |
ClientServer local role, lifecycle 또는 ready 상태가 바뀌었다. |
zlink.runtime.client_server.server_changed |
ClientServer target의 weight, ready 또는 service 상태가 바뀌었다. |
zlink.runtime.fanout.publisher_changed |
Automatic publisher의 연결 대상 또는 ready 상태가 바뀌었다. |
zlink.runtime.location.store_changed |
Location Store가 ready와 degraded 사이에서 바뀌었다. |
Log는 timestamp, source 종류와 등록 이름을 기록한다. 필요한 변화에는 Node RID, weight, reason과 state를 추가한다. Payload, metadata, Actor ID, Spot ID, owner token, generation, raw frame와 native handle은 기록하지 않는다.
Mailbox에 work가 들어오거나 빠질 때 structured log나 전용 metric을 기록하지 않는다. Framework는 mailbox의 개별 enqueue·dequeue와 turn을 운영 event로 만들지 않는다. Operation 실패는 drop·timeout·backpressure metric으로 집계하고, 개별 message 지연은 Message flow tracing으로 조사한다.
Publisher 상태는 excluded_draining, excluded_stale, reconnecting,
disconnected로 기록한다. Log는 기록 시점의 판단이며 현재 위치나 상태의 기준이
아니다. 현재 상태는 fanout status에서 읽는다.
Relocation unit의 source admission seal부터 one-way cutover submit의 성공 또는 실패
terminal까지 1초를 넘기면 zlink.runtime.relocation.changed에 unit_kind, 필요한
경우 execution_mode, interruption_target_exceeded=true와 실제 duration을
기록한다. unit_kind는 actor, instance_spot, user_spot 중 하나다. 이는 운영
경고이며 relocation outcome이나 recovery 판단을 바꾸지 않는다. Actor ID와 Spot ID는
structured log에 넣지 않고 제한된 trace에서만 확인한다. Target admission open은
source로 ACK하지 않으며 target-local status와 trace에서 관찰한다.
10. Startup과 실패¶
- 등록하지 않은
MeshName이나ChannelName의 status를 요청하면 구성 오류다. - Manual subscriber로만 등록한 fanout
ChannelName에 automatic status를 요청하면 구성 오류다. - Location Store가 없는 runtime은 store 상태를
not_configured로 표시한다. - Object role이
Client또는Server인데 Location Store가 없으면 host startup이 실패한다. - Metric이나 trace를 끄더라도 runtime status는 계속 사용할 수 있다.
- Logger provider의 실패는 message dispatch, reply, topology 조정과 host lifecycle 결과를 바꾸지 않는다.
11. 검증 요구¶
공개 표면(host·topology status 조회 API, status 변화 관찰 API, SafeToShutdown 관찰
값, 운영 도구의 위치 조회 API, structured log identifier)만으로 다음을 확인한다. 각
항목은 구현 또는 contract test 하나로 이어진다.
Host status
- Host status 하나만으로 readiness, 새 작업 수락 여부, relocation과 shutdown 결과를 판단할 수 있다.
- Public status에는 endpoint, descriptor revision, owner lease, claim, reservation, native handle과 raw event DTO가 없다.
SafeToShutdown은 모든 relocation unit의 Message Follow route 제거 가능 시점 도달과 각 unit의 cutover 재전송 창 종료보다 먼저 게시되지 않으며, 두 판정에 다른 node의 시각을 사용하지 않는다.- Controlled ClientServer DEALER-ROUTER reply byte는 Core HWM ordinary accounting과 total messaging에 나타나고 Completion field에는 나타나지 않는다. RouteMesh ROUTER-ROUTER reply byte는 Completion current·peak·pending에 나타난다.
Topology status
- RouteMesh, ClientServer와 automatic fanout은 각각 하나의 완전한 status로 readiness와 target 상태를 제공한다.
- Placement weight
0, capacity exhaustion과 recovery가 public status와 일치한다. - Automatic fanout의 15초 record timeout은 해당 publisher만 unavailable로 바꾼다.
변화 관찰
Sequencegap 뒤 현재 status를 다시 조회하면 모든 상태가 복원된다.- 느린 관찰자, 관찰 취소와 logger provider 실패는 dispatch, reply와 lifecycle terminal result를 바꾸지 않는다.
위치 조회와 log
- Object 위치 조회는 Location runtime의 page와 cache 계약을 지킨다.
- Publish target 수와 target별 수락·실패 결과는 status나 runtime structured log에 나타나지 않는다.