OTLP receiver

默认选 gRPC（:4317）：序列化效率高、长连接复用、双向流支持，是 OTel 生态的「first-class」transport。选 HTTP（:4318）当：① 网络只允许 HTTP/HTTPS（企业代理、严格防火墙）；② 后端要走 reverse proxy 做 TLS 卸载 / load balance；③ OTel SDK 版本太旧没 gRPC 支持。两栈在 agentprof 这边完全等价 —— 同一份 mapper 把 OTLP typed event 转 TypedEvent 进 pipeline。

// crates/agentprof-storage/src/otlp/server_grpc.rs:84
pub async fn serve_grpc(
    cfg: OtlpServerConfig,
    pipeline: Arc<IngestPipeline>,
) -> Result<GrpcServerHandle, OtlpServerError>;

// crates/agentprof-storage/src/otlp/server_http.rs:96
pub async fn serve_http(
    cfg: OtlpServerConfig,
    pipeline: Arc<IngestPipeline>,
) -> Result<HttpServerHandle, OtlpServerError>;

两个 fn 都返回 JoinHandle + oneshot::Sender<()> 的 graceful-shutdown 句柄；serve --ingest-otlp 同时 spawn 两者，await 任一异常即整体退出。

业界标准做法是「agent → OTel Collector → backend」三段式。agentprof 把后两段合并是为了降低个人 / 小团队的安装摩擦 —— 不需要先装 collector 配 receiver 配 exporter 配 pipeline yaml 才能看 agent 数据。trade-off 是 agentprof 自己要处理一部分 collector 该做的事（per-signal size cap、bearer auth、LRU eviction）—— ADR-0022 就是补这部分的硬化。如果用户已经有 collector，serve --ingest-otlp 也可以当 backend exporter target —— 兼容并存。

1. receiver（server_grpc / server_http）— 收 OTLP bytes，过 bearer auth / TLS / per-signal size cap，decode 成 protobuf 结构。
2. mapper（otlp/mapper.rs）— OTLP ResourceLogs / ResourceMetrics / ResourceSpans → agentprof 的 TypedEvent；从 resource attrs 抽 session.id（截断到 256 byte，mapper.rs:521）。
3. router（otlp/router.rs::SessionRouter）— DashMap<SessionId, SessionBuffer>；新 session 创 buffer、已存在的拿现成的；LRU evict 超过 max_open_sessions = 1024。
4. buffer（otlp/router.rs::SessionBuffer）— per-session 攒事件；每 buffer 自己有 OOM cap（默认 16 MiB / 100 000 events / 5 min idle）；达到任一阈值触发 flush。
5. flush sink（otlp/sink_storage.rs）— buffer 满 / session 结束 / idle 超时 → 序列化整 session 的 events → 喂 agentprof-core 的 analyzer 算 AnalysisReport。
6. upsert（Db 写）— INSERT OR REPLACE INTO sessions ... WHERE id = ?；同 schema 同 path 同 dual-path 兼容性。

OTLP receiver 是 high-concurrency 场景 —— 多个 gRPC stream 并发 push，每个 stream 进 router 找自己 session 的 buffer。Mutex<HashMap> 会让全部 stream 串行化，吞吐塌方。DashMap 是 sharded map（默认 64 段），每个 shard 独立 lock，不同 session 完全并行。Tradeoff：iter 不是一致 snapshot（LRU sweep 时要小心），但 agentprof 的 LRU 是 epoch + heap 维护、不依赖 map iter 顺序。

两个 server fn 都返回 (JoinHandle, oneshot::Sender<()>)。cli 收到 SIGINT/SIGTERM → 通过 oneshot::send(()) 触发；server 内部 select shutdown signal vs tonic / axum 的 graceful 关闭，等 in-flight request 处理完才退；同时 SessionRouter flush 所有 buffer 落 SQLite —— 不丢已收的 event。这是 cli 退出码 0（正常）vs 130（SIGINT）的关键。

// crates/agentprof-storage/src/otlp/auth.rs
use subtle::ConstantTimeEq;
const BEARER_PREFIX: &str = "Bearer ";

// 字符比较走 ConstantTimeEq -- 不让 attacker 用 timing 探测 token 前缀

为什么：naive 的 == short-circuit —— attacker 喂「a」「b」「c」...，agentprof 在错的字节就早退；通过测「拒绝多花了几纳秒」能逐字符暴力。subtle::ConstantTimeEq 对每个字节都走完比较再返结果，时间分布不泄露信息。不防什么：长度差异本身可被旁路检测（agentprof 假设攻击者已知 token 长度 —— 通常 32 字节 hex）；这不是问题，密码学社区认可的取舍。

问题：tonic 和 axum 的缺省解码限制都很宽（4 MB 量级），但 OTLP 是 protobuf —— 一份 4 MB 的恶意 protobuf 解码后可能膨胀几百 MB（嵌套 list、recursive message）。方案：gRPC 侧每个 service 单独 .max_decoding_message_size(cfg.max_*_request_bytes)（在 InterceptedService 之前）；HTTP 侧每条路由单独挂 DefaultBodyLimit::max(...) layer。关键细节（server_http.rs 注释里专门标了）：router-level middleware 不能 drain body，否则 413 保护会先 OOM 再触发 —— 加 logger / decompressor 时要把它移到 per-route layer 里。

// crates/agentprof-storage/src/otlp/router.rs:171
SessionBufferCaps {
    max_bytes:         16 * 1024 * 1024,   // 16 MiB per session
    max_events:        100_000,            // per session
    max_idle:          Duration::from_secs(5 * 60),  // 5 min
    max_open_sessions: 1024,               // 全局 router 容量
}

问题：attacker 用大量不同 session.id 发 1 event 然后停 —— 每个 session 都创 buffer，DashMap 无限增长。方案：第 1025 个 session 来时，evict 最久未触达的那个 —— 触发 CloseReason::CapacityEvict，flush 它的 buffer 到 SQLite，腾出位。取舍：被 evict 的 session 如果之后又有 event 来，会被视作新 session 重新建 buffer —— 极端情况会被切成多段 SessionRef，但数据不丢。1024 这个数字是「单机一天健康活跃 session ≤ 几十、留 20x 余地」拍的，可调。

// crates/agentprof-storage/src/otlp/mapper.rs:521
// ADR-0022 D-5: cap session_id at 256 bytes BEFORE allocating
//               the SessionId String -- prevents an attacker
//               from forcing GiB-sized id allocations.

问题：OTLP resource attrs 是 string —— attacker 设 session.id 为 1 GB string，agentprof 在 String::from 时就 OOM。方案：从 wire bytes 取 id 前 先看长度，超 256 直接截断 / reject。256 byte 远超合理 session id（UUID 36 字节、SHA256 64 hex 字符）—— 给 prefix path 也留足空间。这个 cap 在 mapper.rs 里、在 SessionRouter::lookup_or_create 之前，确保恶意 id 永远进不了 router map。

ADR-0022 还有 D-1 / D-4 等条目处理别的边缘（如 tonic 的 TLS 配置必须成对、TLS provider 安装时机）。暂未硬化的有：① per-IP rate limit（依赖前置 reverse proxy）；② OTLP attribute key 长度（理论上 attacker 可塞 1 GB 的 key name 进 resource attrs）—— audit list 里记着，但低优先级，没真实场景。