Prometheus Metrics Exporter Release Notes

This page consolidates all Finout Prometheus Metrics Exporter release notes starting from version 2.0. Use this page to understand the changes made between exporter versions, how upgrades affect cost calculation, and what actions (if any) are required during onboarding or upgrading.

Version 2.0.0 - Release date: January 14, 2026

Overview

Prometheus Exporter v2.0.0 introduces major improvements to Kubernetes cost accuracy, backfill control, performance, and platform compatibility.

If you are upgrading to version 2.0.0, you must update your existing Kubernetes CronJob deployment to use the new exporter image. Upgrade impact: Cost calculation changes due to consideration of initContainers metrics.

Required action: Update the exporter image in your CronJob YAML to the new version:

finout/finout-metrics-exporter:2.0.0

No other configuration changes are required unless explicitly noted below.

Note: Starting January 31, 2027, all versions 1.x and earlier will reach End of Life. These versions do not include the major improvements introduced in v2.0.0 and will no longer receive updates, maintenance, or support. You are encouraged to upgrade to v2.0.0 or later versions to ensure continued stability and compatibility.

What’s New

1. InitContainer Resource Metrics - Finout now supports collecting and attributing resource usage from initContainers, including both short-lived setup containers and persistent sidecar initContainers.

   • What changed – Exporter v2.0.0 now includes CPU and memory requests from all initContainers, ensuring full visibility into their cost impact.

   • Why it matters – Provides more accurate Kubernetes cost allocation by capturing all container resource usage and reducing unattributed (idle) costs.

   • Required Configuration – No configuration required. These improvements are included by default in the exporter image. Updated cost data appears in Finout within 48 hours after integration.

2. Configurable Initial Backfill Start Date – The exporter now provides a clear and explicit way to control the initial backfill start date during CronJob onboarding.

   • What changed – In addition to the existing BACKFILL_DAYS configuration, customers can now set an explicit initial backfill start date using INITIAL_BACKFILL_DATE. This is the preferred configuration for new deployments, as it is more explicit and predictable than relative backfill days.

   • Why it matters – Setting a fixed start date makes it easier to understand exactly which data will be fetched during the initial backfill and avoids ambiguity around relative timeframes.

   • Required Configuration – Optional. Use INITIAL_BACKFILL_DATE in YYYY-MM-DD format to define the initial backfill start date.

     • Initial backfills using INITIAL_BACKFILL_DATE are limited to a maximum of 3 days.

     • If no configuration is provided, the exporter defaults to backfilling the last 3 days from deployment time.

     • If both INITIAL_BACKFILL_DATE and BACKFILL_DAYS are set, the cronjob run will fail.

3. Memory Handling Improvements – The exporter was refactored to manage in-process memory more efficiently, improving performance and stability for large-scale environments.

   • What changed – Instead of loading all query data into memory before writing, the exporter now processes and writes data in smaller batches. This prevents excessive memory usage during large Prometheus queries.

   • Why it matters – Reduces the risk of exporter crashes in large Kubernetes environments, ensuring smoother operation and higher reliability when handling extensive datasets.

   • Required Configuration - Optional. The exporter uses a default query batch size of 5. This can be reduced to lower memory consumption by setting the QUERIES_BATCH_SIZE environment variable (minimum value: 1, which results in the lowest memory usage).

4. Improved Readiness Validation for Centralized Prometheus Monitoring Tools Integrations - The exporter readiness check now supports more readiness endpoint variants, including /ready, and can be customized via a new environment variable.

   Note: These validations are informative only - they help surface issues early but do not block the job from continuing or prevent scraping.

   • What changed - Previously, readiness validation supported only /-/ready, with no fallback to /ready and no way to customize the readiness path, therefore:

     • Added support for the /ready readiness suffix.

     • Added a new optional environment variable: METRICS_READINESS_PATH, allowing custom readiness endpoint suffixes.

   • Why it matters - Improves compatibility with different centralized tools and surfaces readiness issues more clearly - without impacting metric collection.

   • Required Configuration - Optional. Set METRICS_READINESS_PATH in the CronJob YAML only if your backend readiness endpoint differs from the supported defaults.

5. ARM Architecture Support – The Finout Metrics Exporter image is now released as a multi-architecture build, supporting both linux/amd64 and linux/arm64 platforms (previously only amd64).

   • What changed – The exporter image now automatically detects and runs on the correct architecture; there’s no need to specify the --platform flag manually. This works seamlessly on both x86_64 and ARM64 systems.

   • Why it matters – Expands compatibility to ARM-based environments, ensuring seamless deployment across diverse infrastructure.

   • Required Configuration – No configuration required if you’re using the default image tags. If your deployment scripts explicitly define --platform=linux/amd64, you can safely remove or update that line for broader compatibility.

6. Logging Enhancements – Finout’s exporter now provides clearer, more structured logs to improve visibility and streamline troubleshooting for the R&D and Support teams.

   • What changed – The exporter now provides clearer logs with human-readable timeframes, making it easier to follow CronJob execution and metric processing progress.

   • Why it matters – Enhances internal monitoring and debugging efficiency, enabling faster issue resolution and more proactive detection of data pipeline or integration problems.

   • Required Configuration - No configuration required. These improvements are included by default in the exporter image.

Benefits for Customers

• More accurate Kubernetes costs when using SideCar initContainers InitContainers are now included in cost allocation and work seamlessly with both old and new Kubernetes ratio algorithms.

• Greater control over historical data Improved backfill capabilities enable customers to more effectively control the historical backfill start date used during initial setup.

• Fewer failures in large environments Memory handling improvements make the exporter more stable and reliable at scale.

• Wider platform support The exporter now runs seamlessly on ARM-based systems.