From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 41AAF1FF16B for ; Tue, 26 Aug 2025 15:52:11 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B733D34FE5; Tue, 26 Aug 2025 15:52:11 +0200 (CEST) From: Lukas Wagner To: pdm-devel@lists.proxmox.com Date: Tue, 26 Aug 2025 15:51:19 +0200 Message-ID: <20250826135119.336510-25-l.wagner@proxmox.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250826135119.336510-1-l.wagner@proxmox.com> References: <20250826135119.336510-1-l.wagner@proxmox.com> MIME-Version: 1.0 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1756216282485 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.026 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pdm-devel] [PATCH proxmox-datacenter-manager v7 24/24] api: pve: rrd: trigger and wait for metric collection when requesting RRD data X-BeenThere: pdm-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Datacenter Manager development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" Since we now default to a much longer collection interval (10 min), the hourly RRD data might have a noticable gap an the end. So circumvent this, we now trigger metric collection for a single remote when requesting hourly RRD data, waiting for the completion of metric collection up to a short timeout of 5 seconds. If the timeout expires, which can happen in the metric collection for this remote is particularly slow (bad connection), or if the metric collection task is currently busy with a full-run that's taking a long time, we simply return the data that we already have. Signed-off-by: Lukas Wagner --- Notes: New in v7. server/src/api/pve/rrddata.rs | 43 +++++++++++++++++++++++++++-------- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/server/src/api/pve/rrddata.rs b/server/src/api/pve/rrddata.rs index b16c2313..b6a04037 100644 --- a/server/src/api/pve/rrddata.rs +++ b/server/src/api/pve/rrddata.rs @@ -1,3 +1,5 @@ +use std::time::Duration; + use anyhow::Error; use serde_json::Value; @@ -10,6 +12,7 @@ use pdm_api_types::rrddata::{LxcDataPoint, NodeDataPoint, QemuDataPoint}; use pdm_api_types::{NODE_SCHEMA, PRIV_RESOURCE_AUDIT, VMID_SCHEMA}; use crate::api::rrd_common::{self, DataPoint}; +use crate::metric_collection; impl DataPoint for NodeDataPoint { fn new(time: u64) -> Self { @@ -161,7 +164,7 @@ impl DataPoint for LxcDataPoint { }, )] /// Read qemu stats -fn get_qemu_rrd_data( +async fn get_qemu_rrd_data( remote: String, vmid: u32, timeframe: RrdTimeframe, @@ -169,8 +172,7 @@ fn get_qemu_rrd_data( _param: Value, ) -> Result, Error> { let base = format!("pve/{remote}/qemu/{vmid}"); - - rrd_common::create_datapoints_from_rrd(&base, timeframe, cf) + get_rrd_datapoints(remote, base, timeframe, cf).await } #[api( @@ -191,7 +193,7 @@ fn get_qemu_rrd_data( }, )] /// Read lxc stats -fn get_lxc_rrd_data( +async fn get_lxc_rrd_data( remote: String, vmid: u32, timeframe: RrdTimeframe, @@ -199,8 +201,7 @@ fn get_lxc_rrd_data( _param: Value, ) -> Result, Error> { let base = format!("pve/{remote}/lxc/{vmid}"); - - rrd_common::create_datapoints_from_rrd(&base, timeframe, cf) + get_rrd_datapoints(remote, base, timeframe, cf).await } #[api( @@ -221,7 +222,7 @@ fn get_lxc_rrd_data( }, )] /// Read node stats -fn get_node_rrd_data( +async fn get_node_rrd_data( remote: String, node: String, timeframe: RrdTimeframe, @@ -229,9 +230,33 @@ fn get_node_rrd_data( _param: Value, ) -> Result, Error> { let base = format!("pve/{remote}/node/{node}"); - - rrd_common::create_datapoints_from_rrd(&base, timeframe, cf) + get_rrd_datapoints(remote, base, timeframe, cf).await } + +async fn get_rrd_datapoints( + remote: String, + basepath: String, + timeframe: RrdTimeframe, + mode: RrdMode, +) -> Result, Error> { + const WAIT_FOR_NEWEST_METRIC_TIMEOUT: Duration = Duration::from_secs(5); + + if timeframe == RrdTimeframe::Hour { + // Let's wait for a limited time for the most recent metrics. If the connection to the remote + // is super slow or if the metric collection tasks currently busy with collecting other + // metrics, we just return the data we already have, not the newest one. + let _ = tokio::time::timeout(WAIT_FOR_NEWEST_METRIC_TIMEOUT, async { + metric_collection::trigger_metric_collection(Some(remote), true).await + }) + .await; + } + + tokio::task::spawn_blocking(move || { + rrd_common::create_datapoints_from_rrd(&basepath, timeframe, mode) + }) + .await? +} + pub const QEMU_RRD_ROUTER: Router = Router::new().get(&API_METHOD_GET_QEMU_RRD_DATA); pub const LXC_RRD_ROUTER: Router = Router::new().get(&API_METHOD_GET_LXC_RRD_DATA); pub const NODE_RRD_ROUTER: Router = Router::new().get(&API_METHOD_GET_NODE_RRD_DATA); -- 2.47.2 _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel