ObjectOS運維
可觀測性
日誌、請求 id、指標、錯誤、會話與審計日誌。
ObjectOS 的運維既需要基礎設施層訊號，也需要應用層訊號。框架提供 請求 id、指標、錯誤上報和審計原語;由部署方決定把它們匯出到哪裡。
請求標識
每個生產部署都應當傳遞或生成一個請求 id：
X-Request-Id用它來關聯：
- 入口日誌;
- ObjectOS 日誌;
- 資料庫慢查詢;
- 錯誤上報;
- 客戶支援工單。
指標與錯誤
執行時暴露可插拔的指標介面和錯誤上報介面。請將其對接到客戶選定 的系統，例如 Prometheus、OpenTelemetry、Datadog、Sentry 或其他經過 審批的後端。
至少跟蹤：
| 訊號 | 用途 |
|---|---|
| 按路由/狀態碼統計的請求數 | 檢測錯誤激增 |
| 請求時延 | 檢測時延迴歸 |
| 5xx 錯誤 | 對執行時故障告警 |
| 認證失敗 | 發現配置錯誤或攻擊模式 |
| 產物/核心快取未命中 | 理解冷啟動行為 |
最小化 Prometheus 示例
啟用指標服務後，ObjectOS 暴露一個 Prometheus 相容的指標端點：
# prometheus.yml
scrape_configs:
- job_name: objectos
metrics_path: /metrics
static_configs:
- targets: ['objectos:3000']可以作為起點的告警規則：
groups:
- name: objectos
rules:
- alert: ObjectOS5xxSpike
expr: |
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.02
for: 5m
annotations:
summary: "ObjectOS 5xx rate above 2% for 5 minutes"
- alert: ObjectOSAuthFailureSpike
expr: rate(auth_failures_total[5m]) > 5
for: 10m
annotations:
summary: "Sustained auth failure rate — check for misconfiguration or attack"
- alert: ObjectOSKernelColdStartHigh
expr: rate(kernel_cache_misses_total[15m]) > 1
for: 15m
annotations:
summary: "Frequent project kernel cold starts — consider raising OS_KERNEL_CACHE_SIZE"對於 OpenTelemetry，設定 OS_OBS_EXPORTER=otlp 以及 OS_OTLP_ENDPOINT
（例如 https://<collector>/otlp），ObjectOS 會以 OTLP 格式發出 trace 與
指標。匯出器預設為 noop（執行時零成本），因此 OTLP 匯出為按需啟用 ——
僅設定端點而不設 OS_OBS_EXPORTER=otlp 不會發出任何資料。本地除錯用
OS_OBS_EXPORTER=console 或 json，用 OS_OBS_DEPLOYMENT_ENV 標記部署
（預設 production）。span 的形狀與
請求流程一致。
審計日誌
啟用審計能力後，ObjectOS 將審計記錄寫入 sys_audit_log。
審計日誌用於：
- 許可權敏感的變更;
- 設定變更;
- 使用者/會話排查;
- 整合活動;
- 拒絕訪問的分析。
在受監管環境中，將審計表在資料庫或儲存層設為僅追加，並定義保留 策略。
Console 診斷
Console 暴露面向運維的功能頁面，例如：
- 會話;
- 審計日誌;
- 通知;
- 啟用 webhook 時的 Webhook 投遞記錄;
- 系統與安全總覽儀表盤。
這些頁面面向運維與支援工程師，而不僅僅是開發者。