src/config/src/config.rs (1)

893-894: Add documentation for the new configuration field.

The field usage_reporting_thread_num would benefit from documentation that explains:

• Its purpose for configuring usage reporting threads
• The meaning of the default value 0 (auto-configuration based on CPU cores)
• The expected range of valid values

Add rustdoc comments like this:

+/// Number of threads to handle background usage reporting jobs.
+/// Default value of 0 means:
+/// - In local mode: Use half of the available CPU cores
+/// - In distributed mode: Use all available CPU cores
+/// Valid values: 0 or any positive integer
 #[env_config(name = "ZO_USAGE_REPORTING_THREAD_NUM", default = 0)]
 pub usage_reporting_thread_num: usize,

src/service/usage/mod.rs (1)

256-256: Improve log message clarity

The log message "Returning as no usages reported" could be more informative. Including the function name or additional context can aid in debugging and improve log traceability.

Apply this diff to enhance the log message:

-log::info!("Returning as no usages reported ");
+log::info!("ingest_usages: No usage data to process.");

Configuration used: CodeRabbit UI
Review profile: CHILL

src/service/usage/mod.rs (3)

57-63: Enhance thread initialization logging

Add more context to the log message to help with monitoring and debugging:

+    log::info!(
+        "[USAGE] Initializing {} usage reporting threads with batch_size={}, timeout={}s",
+        cfg.limit.usage_reporting_thread_num,
+        batch_size,
+        timeout.as_secs()
+    );
     for thread_id in 0..cfg.limit.usage_reporting_thread_num {

---

524-533: Improve error handling in message processing

The current implementation silently continues on error. Consider adding error context and metrics:

     let mut msg_receiver = msg_receiver.lock().await;
     tokio::select! {
         msg = msg_receiver.recv() => {
             match msg {
                 Some(UsageMessage::Data(usage_buf)) => {
                     log::debug!("[USAGE:JOB] thread_{thread_id} received and queued {} messages.", usage_buf.len());
                     usage_report_runner.push(usage_buf);
                     if usage_report_runner.should_process() {
                         let buffered = usage_report_runner.take_batch();
-                        ingest_buffered_usage(thread_id, buffered).await;
+                        if let Err(e) = ingest_buffered_usage(thread_id, buffered).await {
+                            log::error!("[USAGE:JOB] thread_{thread_id} failed to ingest buffered usage: {}", e);
+                            metrics::USAGE_INGEST_ERRORS.inc();
+                        }
                     }
                 }

---

563-567: Return Result from ingest_buffered_usage for proper error handling

The function should propagate errors to allow the caller to handle them appropriately:

-async fn ingest_buffered_usage(thread_id: usize, usage_buffer: Vec<UsageBuffer>) {
+async fn ingest_buffered_usage(thread_id: usize, usage_buffer: Vec<UsageBuffer>) -> Result<(), anyhow::Error> {
     log::debug!(
         "[USAGE:JOB] thread_{thread_id} ingests {} buffered usage data",
         usage_buffer.len()
     );

Configuration used: CodeRabbit UI
Review profile: CHILL

src/service/usage/mod.rs (2)

57-63: Consider using a thread pool for better resource management

Instead of spawning individual tasks for each thread, consider using a thread pool (e.g., tokio::runtime::Handle::current().spawn_blocking()) to better manage system resources and prevent potential thread explosion in case of misconfiguration.

---

Line range hint 524-559: Improve error handling in message processing

The current implementation silently ignores errors from ingest_buffered_usage. Consider adding error handling and potentially implementing a retry mechanism for failed ingestions.

-                            ingest_buffered_usage(thread_id, buffered).await;
+                            if let Err(e) = ingest_buffered_usage(thread_id, buffered).await {
+                                log::error!("[USAGE:JOB] thread_{thread_id} failed to ingest: {e}");
+                                // TODO: Implement retry mechanism
+                            }

src/config/src/config.rs (1)

893-894: Add documentation for the new configuration field.

Please add documentation for the usage_reporting_thread_num field using the help parameter in the env_config attribute to describe:

• Purpose of the configuration
• Default behavior (0 = half CPU cores in local mode, full CPU cores in distributed mode)

-    #[env_config(name = "ZO_USAGE_REPORTING_THREAD_NUM", default = 0)]
+    #[env_config(
+        name = "ZO_USAGE_REPORTING_THREAD_NUM",
+        default = 0,
+        help = "Number of threads for usage reporting. Default 0 means half of CPU cores in local mode, full CPU cores in distributed mode"
+    )]
     pub usage_reporting_thread_num: usize,

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify CPU core detection and thread calculation logic
# Test: Search for CPU core detection and thread calculations
rg "get_cpu_limit|usage_reporting_thread_num.*=.*cpu" -B 2 -A 2

#!/bin/bash
# Check cgroup CPU detection implementation
rg "read_cpu_cgroup" -A 10