大家好，
我在 Google Cloud Run 上使用單一授權金鑰運行多個 n8n 執行個體。
追蹤每個部署/租戶的使用情況（執行、活躍工作流程、API 使用情況等）的最佳方法是什麼？
嗨 @rgrzesk
我認為最好的方式是使用insights：
但如果你想將多個資料實例放入單一框架，我會推薦這個：
我已經使用過它，一直都能正常運作。
另外，你也可以直接呼叫N8N API：
GET /api/v1/executions?status=success&limit=250
如果你不是在n8n雲端上，Ud metrics選項是最好的。
這是否有幫助，@rgrzesk ？
若要在多個 Cloud Run 執行個體間進行追蹤並匯總到一個地方，API 輪詢方法的擴展性不佳 - 每個執行個體都有自己的 API 端點，且沒有統一檢視。更簡潔的模式是為每個執行個體添加一個專用的「執行記錄器」工作流程：它按排程執行，使用時間視窗呼叫 GET /api/v1/executions，添加 instance_id 標籤，並將結果發佈到共享的 Postgres 資料表或 Google Sheet。這樣你就有一個中央位置來查詢所有執行個體的使用情況。你可以透過在部署時注入的環境變數，將 Cloud Run 服務名稱包含為執行個體識別碼。
這個聽起來確實不錯，但問題是我無法存取每個實例，而且今後也不會有。我可以協調它，但無法成為使用者。
我需要在部署時建立這樣的預定義工作流程，但我想這不太可能輕易做到。唯一的方法是以某種方式使用公開可用的數據。是否可以使用 /metric 端點？我會獲得足夠的數據來使用嗎？
如果你無法存取每個實例的 API 或使用者權限，我會將 ⁄metrics 視為部分基礎設施訊號，而不是完整的使用模型。
它可以協助回答「這個實例是否運作中、負載有多重、執行失敗是否比平時更頻繁」之類的問題，但通常無法提供清晰的業務歸屬，例如租戶使用量、每個客戶的活躍工作流程數量，或可計費的 API 呼叫次數，除非你從一開始就圍繞這些標籤設計部署。
針對你的情況，因為你可以協調部署，我建議把追蹤邊界推進到部署樣板中：
- 為每個 Cloud Run 服務指定一個穩定的 deployment_id / tenant_id 標籤
- 在部署時啟用指標/日誌匯出，而不是在客戶開始使用後才啟用
- 讓 Cloud Run 日誌包含相同的部署標籤
- 如果可能的話，在佈建期間預先安裝一個小型內部日誌工作流程
- 如果無法存取工作流程，至少要集中蒐集實例健康狀態、執行總數、失敗次數、延遲時間和重啟/錯誤訊號
重點是該 ID 必須存在於 n8n 之外。如果每個實例都發出指標，但這些指標抵達時沒有穩定的部署標籤，你最終還是會得到一堆難以協調的全局數字。
因此我會使用 ⁄metrics 進行運營監控，但不要單獨依賴它進行租戶/客戶報告。對於使用量報告，我會希望有預定義的日誌工作流程、API 存取權限，或你的收集器在資料進入中央儲存區之前新增的部署級標籤。
感謝，這很合理。
用資料庫作為歷史/授權使用的真實資料來源呢？這樣做有意義嗎，它能保留我需要的資料嗎？
透過 execution_entity 檢查並計算所有未標記為 manual 的項目？
Hi @rgrzesk
針對你的設置有另一個方法是使用 OpenTelemetry tracing。由於你控制部署，在配置時設定這些環境變數：
N8N_OTEL_TRACE_ENABLED=true
N8N_OTEL_TRACE_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-central-collector:4318
每次執行都會發出一個 workflow.execute span，包含執行模式、狀態、工作流程 ID 以及該實例的唯一 n8n.instance.id。將所有實例指向一個收集器（Jaeger、Grafana Tempo 等），你就能獲得按實例、按執行的追蹤，支援模式過濾。不需要資料庫存取、沒有清理風險、使用標準協議，而且完全在部署時配置，非常符合你的限制條件。
資料庫路由作為備選方案：是的，execution_entity 搭配 mode != 'manual' 可行，但要注意清理會根據 EXECUTIONS_DATA_MAX_AGE 刪除這些記錄。以比清理窗口更短的間隔將資料聚合到你自己的存儲中。
希望有幫助 
不錯！
OL 對於已有的新實例來說是個不錯的解決方案。我們有辦法也取得歷史數據嗎？
OTel 只會從啟用時開始擷取資料，不會進行追溯追蹤。
對於現有執行個體的歷史資料，由於您可以存取資料庫，有兩個選項：
-
execution_entity表：查詢mode != 'manual'以取得生產計數。只能回溯到修剪允許的範圍內。 -
Insights 表：n8n 將壓縮的 insights 資料單獨儲存在 execution_entity 之外，預設保留 365 天（
N8N_INSIGHTS_MAX_AGE_DAYS）。這會在執行修剪後保留。檢查 Postgres 結構描述中的insight_*表以取得彙總的歷史計數。
對於資料庫中比這更舊的任何資料，已無法復原。
嗨！
我有段時間沒有關注這個主題，但我回來了 
很高興從 2.27.0 版本開始，我也可以在 UI 中配置 OpenTelemetry。
不過我有兩個問題：
- 我可以隱藏這些選項嗎？因為它會洩露 opentelemetry 系統的 API 密鑰。
- 我應該在哪個 execution.mode 下查看 OTL？我是指 - 其中哪些是可計費的？包括 !manual 的嗎？
EDIT - 關於第 2 個問題 - 我剛注意到已經有一個標誌了 N8N_OTEL_TRACES_PRODUCTION_ONLY
Settings 中沒有內建的開關可以隱藏 OTel API 金鑰欄位 — 這是一個已知的缺口，已在此追蹤為功能請求：community.n8n.io/t/opentelemetry-visible-ui/300678。在該功能推出之前，解決方法是透過 RBAC/專案角色限制誰可以存取 Settings，或直接設定 OTel 環境變數 (N8N_OTEL_*)，而不是透過 UI，這樣金鑰就不會在那裡顯示。
關於 execution.mode：只有生產環境觸發的執行計入您的計費配額（webhook、排程、有資料的輪詢觸發器）。「manual」執行永遠不計費，子工作流程呼叫、錯誤工作流程執行或空輪詢也不計費。因此，如 houda_ben 建議的那樣，在您的 OTel/insights 查詢上篩選 mode != ‘manual’，您已經在查看正確的計費集合。
什麼是 integrated 模式？它也會被計算嗎？
如果子工作流不被計算，它們如何可見 - 作為手動的嗎？
「integrated」是工作流程作為透過執行工作流程節點呼叫的子工作流程執行時設定的模式，其本身的執行記錄上不會帶有父層的手動/生產區分。對於計費，只有當父層執行本身是由生產觸發時，子工作流程呼叫才會計入父層的配額：生產父層觸發可計費的整合子執行，手動父層的整合子執行保持不可計費。因此在 OTel/Insights 中調整計數時，應根據父層的模式進行篩選，而非子工作流程本身的模式欄位。
厚顏無恥地推廣 LumaTrack，我們可以透過我們已驗證的社群節點、OTel、MCP、API 等輕鬆做到這一點。
好的，所以如果我沒理解錯的話，如果我們有一個生產執行，它觸發5個不同的子工作流，而這5個子工作流執行（例如滿足條件），我們只為主生產執行支付一次費用？
@rgrzesk 是的，那是正確的。計費是根據父工作流程的執行模式，而不是每個子工作流程個別的模式。所以如果主工作流程在生產模式中觸發（webhook/排程/輪詢），並且它通過「執行工作流程」呼叫 5 個子工作流程，那些子執行會在「整合」模式下執行，不會單獨計費，你只需為一個父生產執行付費。這僅在子工作流程被作為同一執行的子項呼叫時成立；如果你通過它們自己的生產觸發獨立觸發其中任何一個，該執行會單獨計費。