wu-sheng commented on code in PR #911:
URL: 
https://github.com/apache/skywalking-banyandb/pull/911#discussion_r2638956670


##########
docs/design/fodc/proxy.md:
##########
@@ -0,0 +1,1278 @@
+# FODC Proxy Development Design
+
+## Overview
+
+The FODC Proxy is the central control plane and data aggregator for the First 
Occurrence Data Collection (FODC) infrastructure. It acts as a unified gateway 
that aggregates observability data from multiple FODC Agents (each co-located 
with a BanyanDB node) and exposes ecosystem-friendly interfaces to external 
systems such as Prometheus and other observability platforms.
+
+The Proxy provides:
+
+1. **Agent Management**: Registration, health monitoring, and lifecycle 
management of FODC Agents
+2. **Metrics Aggregation**: Collects and aggregates metrics from all agents 
with enriched metadata
+3. **Cluster Topology**: Maintains an up-to-date view of cluster topology, 
roles, and node states
+4. **Configuration Collection**: Aggregates and exposes node configurations 
for consistency verification
+
+### Responsibilities
+
+**FODC Proxy Core Responsibilities**
+- Accept bi-directional gRPC connections from FODC Agents
+- Register and track agent lifecycle (online/offline, heartbeat monitoring)
+- Aggregate metrics from all agents with node metadata enrichment
+- Maintain cluster topology view based on agent registrations
+- Collect and expose node configurations for audit and consistency checks
+- Expose unified REST/Prometheus-style interfaces for external consumption
+- Provide proxy-level metrics (health, agent count, RPC latency, etc.)
+
+## Component Design
+
+### 1. Proxy Components
+
+#### 1.1 Agent Registry Component
+
+**Purpose**: Manages the lifecycle and state of all connected FODC Agents
+
+##### Core Responsibilities
+
+- **Agent Registration**: Accepts agent registration requests via gRPC
+- **Health Monitoring**: Tracks agent heartbeat and connection status
+- **State Management**: Maintains agent state (online/offline, last heartbeat 
time)
+- **Topology Building**: Aggregates agent registrations into cluster topology 
view
+- **Connection Management**: Handles connection failures, reconnections, and 
cleanup
+
+##### Core Types
+
+**`AgentInfo`**
+```go
+type AgentInfo struct {
+       NodeID      string                    // Unique node identifier
+       NodeRole    databasev1.Role          // Node role (liaison, 
datanode-hot, etc.)
+       Address     string                    // Agent gRPC address
+       Labels      map[string]string        // Node labels/metadata
+       RegisteredAt time.Time                // Registration timestamp
+       LastHeartbeat time.Time               // Last heartbeat timestamp
+       Status      AgentStatus               // Current agent status
+}
+
+type AgentStatus string
+
+const (
+       AgentStatusOnline  AgentStatus = "online"
+       AgentStatusOffline AgentStatus = "offline"
+       AgentStatusUnknown AgentStatus = "unknown"

Review Comment:
   @hanahmily I think we could just maintain the active list? Or there are only 
two statuses, one `online`, the other is `unconnected`, which is only 
short-term. `unconnected` means the health check failed before reaching the 
threshold of removing?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to