From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 38E751FF15C for ; Fri, 22 Aug 2025 13:27:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4BA52F01E; Fri, 22 Aug 2025 13:27:38 +0200 (CEST) Message-ID: Date: Fri, 22 Aug 2025 13:27:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Lukas Wagner , Proxmox Datacenter Manager development discussion References: <20250821095319.134215-1-l.wagner@proxmox.com> <3584b07f-92b7-4cf6-a0f4-6adf7f5752d6@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1755862053867 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pdm-devel] [PATCH proxmox-datacenter-manager v6 00/23] metric collection improvements (concurrency, API, CLI) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pdm-devel-bounces@lists.proxmox.com Sender: "pdm-devel" On 8/21/25 3:46 PM, Lukas Wagner wrote: > On Thu Aug 21, 2025 at 2:53 PM CEST, Dominik Csapak wrote: >> just a first high level question while i'm testing/reviewing this: >> >> when using this patch, it seems the collection interval is much reduced? >> >> e.g. in the gui I'm missing up to the last 10 minutes now? >> (at 14:49 the last point i have for the rrd is from 14:40) >> >> is this by design? i get that we don't want to pull too often, >> but showing up to 10minutes out of date graphs is also not practical? > > Maybe I misremember, but I vaguely recall Thomas and Dietmar > independently mentioning that the default metric polling interval should > be higher than what is implemented right now (1min). > > Anyway, at some point the interval should be configurable (already was > in earlier versions of this series, but I dropped these patches for now > since it's not 100% clear yet to me *where* we want to configure these > things/store the settings). So then the question is what *default* to > use - for now I settled for 10mins. But I'm open for better values, I > don't have hard feelings about this. > >> >> my naive solution would be to proxy the rrd requests to the >> pve nodes directly, but then why would we need the metric >> collection in the first place? > > We also could trigger an out-of-schedule metric collection for a remote > when the RRD graph calls the rrddata endpoint (the functions for > triggering the collection of a single remote are already there, albeit > non-blocking, so this would need some changes). Fetching the missing > data for a single remote should be fast enough any way. The rrddata > endpoint could have some timeout for waiting for the results of > collecting that single remote; if that one is exceeded we don't wait > until the collection results are done but simply return the existing > data. > The problem is actually just the 'hourly' graphs, since there the interval is so small one noticed the 10 minutes quite often. All others (daily,monthly, etc.) don't exhibit the same problem so i'd say if we can fetch missing data on-the-fly in the api call for hourly calls, it would be good enough >> >> i guess i'm just missing something here, maybe you can point it out for me? > _______________________________________________ pdm-devel mailing list pdm-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel