Note: It is recommended to choose the SAML integration.
Note: The domain must be claimed by copying the TXT record and applying it to your DNS provider.
Note: Ensure that your IdP passes the groups attribute that is sent in the SAML Assertion.
Note: For more information, see Frontegg documentation.
## **Cost Type Mapping Across Providers** Finout standardizes cost calculations across cloud providers and services, ensuring a consistent and accurate view of spending. The table below outlines how Finout's cost types align with different providers.
| AWS | Azure | GCP | Snowflake | Datadog | Confluent | OCI | ||
| Unblended | Unblended | Actual | Cost | Cost | Cost | Amount | Cost / MyCost | |
| Net Unblended | Net Unblended | Actual | Cost | Cost | Cost | Amount | Cost / MyCost | |
| Amortized | Amortized | Amortized | Cost | Cost | Finout’s Amortization Calculation | Amount | Cost / MyCost | |
| Net Amortized | Net Amortized | Amortized | Cost | Cost | Finout’s Amortization Calculation | Amount | Cost / MyCost | |
| Blended | Blended | Amortized | Cost | Cost | Cost | Amount | Cost / MyCost | |
| List Cost | Public Pricing | Not Available | Public Pricing | Not Available | Not Available | Not Available | Not Available | |
| FairShare Cost | Finout FairShare Calculation | Not Available | Not Available | Not Available | Not Available | Not Available | Not Available | |
| Net FairShare Cost | Finout Net FairShare Calculation | Not Available | Not Available | Not Available | Not Available | Not Available | Not Available |
*Explanation*: All resource costs are calculated on an On-Demand basis (no discount applied). The FairShare cost and the AWS Amortized cost are the same.
Note: Not including EDP
Note: For services that are only eligible for Reserved Instances (RIs) and used consistently throughout the full month, the (Net) Amortized Cost and (Net) FairShare Cost will be identical—even when viewed at the individual service level:
- Amazon RDS
- Amazon ElastiCache
- Amazon DynamoDB
- Amazon Redshift
Important:
List Costreturns0for the following cases:- Enterprise Agreement (EA) Marketplace charges
- EA reservation usage when cost allocation is enabled
- Microsoft Customer Agreement (MCA) reservation usage.
Note: Pod label enrichment remains a separate Finout feature that is not covered in AWS's split data. Finout will also continue providing Kubernetes rightsizing recommendations.
Note: Non-alphanumeric characters — such as :, /, or . — are replaced by AWS with underscores (_) in the column names of the Parquet files.
* Create the destination bucket to store the cost and usage data: 1. Add a bucket name. Save it for future use in step [Integrate AWS to Finout](#h_159429fe73-1). 1. Choose a region. Save it for future use in step [Integrate AWS to Finout](#h_159429fe73-1). 2. Mark **The following default policy will be applied to your bucket**. 3. Click **Save**.\ Your bucket is created. 2. Add your **S3 path prefix**. Save it for future use in step [Integrate AWS to Finout](#h_159429fe73-1). 7. Click **Next** and then **Review and Complete**.\ The report is created within a few hours. ## 2. Create the Cost Optimization Export 1. In the AWS Console, open **Billing & Cost Management**. 2. Go to **Data Exports**. 3. Click **Create**.
Note: The prefix must be different from the billing.
# Connect to Azure ## Azure Integration Overview Integrate Azure with Finout to generate comprehensive cost and usage reports tailored to your organization's needs. Configure Finout to create detailed reports using Azure data, either for specific subscriptions or across your entire organization. This integration allows for in-depth analysis and management of expenses, offering valuable insights into cost allocation and usage trends across your Azure infrastructure. See [Azure documentation](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-improved-exports) to learn more about creating and managing cost management exports. **Azure Configuration Workflow:** 1. [Create a Service Principal for Finout](#h_caeb06e4d5) 2. [Create the Billing Export](#h_b1296fde84) 3. [Grant Finout Read-Only Permission from the Export Storage](#h_3457a15897) 4. [Connect Azure Advisor to Finout](/billing-integrations/cloud-providers/connect-to-azure#h_81357dba78) 5. [Connect Azure Commitments to Finout](#h_81357dba78-1) 6. [Integrate Azure with Finout](#h_81357dba78-1) ## 1. Create a Service Principal for Finout Integration with Azure is achieved using an [Azure service principal](https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/service-accounts-principal).\ \ There are two options:\ a. [Create a service principle using the CLI.](#h_39705424de) b. [Create a service principal using the Azure portal](#h_9306e184ac) and [set up an authentication](#h_d5c901358e). #### a. Create a service principal using the CLI 1. From the CLI, type the following: ```json az ad sp create-for-rbac -n "finout" ``` 2. You will receive an output similar to the following: ```json { "appId": "3c666g0g6-8cb8-8b33-cba6-abc7676a8989", "displayName": "finout", "password": "789************************", "tenant": "6666b777-ba88-44a9-a4aa-666ccb222a91" } ``` {% hint style="warning" %} **Important**: Save the following details to use in the Finout console (step 5): * appId → Application (client) ID * tenant → Directory (tenant) ID * password → Application password (Client Secret {% endhint %} #### b. Create a service principal using the Azure portal 1. From your Azure portal, search for and select **Azure Active Directory**. 2. Select **App registrations**, then click **New registration.**
Important: Save the following details to use in the Finout console (step 4):
- appId → Application (client) ID
- tenant → Directory (tenant) ID
Note: If the secret is set to expire, you must remember to renew the credentials and reconfigure it in the Finout console.
Note: The reports must be exported twice, once for each cost type. You should provide a different directory for both exports, but both exports must be exported to the same container.
Important:
- Ensure that the Format is CSV.
- Ensure that the Compression type is None.
Note: Save the following details to add to Finout (step 4):
-Storage Account
-Container
-Actual Cost Directory and Export Name
-Amortized Cost Directory and Export Name
3. **Create Actual and Amortized Exports**
Note: You will need to create two separate exports:
- One for Actual Cost and Usage
- One for Amortized Cost and Usage
Important: Azure allows exporting only one month at a time. To export additional months, repeat the process.
Note: You will need to run two separate exports:
- One for Actual Cost and Usage
- One for Amortized Cost and Usage
2. Select **Run now** and choose the relevant month. 7. **Locate and Share Files**:\ Once complete, both files will be available in the Blob Storage container you specified. Contact Finout support and they will then access the container and import the data into your account. (Optional) Create the same export for additional months: 1. In Exports, click  on the right side of each export.\  2. Click **Export for selected dates**, and configure another full calendar month.
Note: Save your tenancy for step 5.
Important: The following statement is not an example. You need to run this statement exactly as it is shown below.
Examples:
- If you chose the “Default” domain:
endorse group default to read objects in tenancy usage-report - If you chose a custom domain named “finoutdomain”:
endorse group finoutdomain/default to read objects in tenancy usage-report
Note: You can Edit the user capabilities and limit to only API keys.
Note: The Oracle documentation offers alternative methods for generating the key. Ensure that you have the complete configuration details as outlined in the following step.
Note: Finout generates the key pair for you. Finout securely stores the private key, and you receive the public key, which you can copy and paste into the OCI Console.
Note: Before running the authentication command, ensure that any existing OCI configuration files are removed, as they may have been left over from a prior integration run.
``` ----------------------- User ID: ocid1.user.oc1..8m3k9p2v7x1w4q5z6n0y8j3t2r9f5k7b4v1m6b8i3k2f8p7r9d0a2v3c API Key fingerprint: 3d:f8:12:91:c4:7e:0a:b5:82:39:e1:6f:4a:d0:8c:9b Tenancy: ocid1.tenancy.oc1..aaaaaaaalzf62oj3gqksyjc6jiee7na3m7ne7ebvecslrbk6xfhqgrlqbrka Region: us-ashburn-1 ----------------------- ``` 7. Fill the form. ### 3. Set Up CLI Parameters
Note: Group names may contain only letters, numbers, dots (.), dashes (-), and underscores (_).
This option uses a single CLI script to automatically create all required OCI resources, reducing setup time and minimizing configuration errors. **What the script does:** * Creates or reuses an IAM group * Creates or reuses a read-only IAM policy for cost and usage reports * Creates or reuses an IAM user in the selected identity domain * Adds the user to the group * Uploads the public API key provided by Finout * Outputs all required identifiers for Finout {% hint style="info" %} **Note**: If resources already exist, they will be reused. If not, they will be created. {% endhint %} 2. Copy the following values from the CLI script: * User ID * API Key Fingerprint * Tenancy * Region ### 5. Connect to OCI
Note: The UAT feature is available only for Enterprise/Pro accounts in DataDog; If your DataDog account doesn't support it, you will be limited to use the Custom Tags integration in Finout. If you are unsure how to verify that, please contact Finout support at support@finout.io for further assistance.
If sub-organizations use the same tags as the parent organization, their data can also be broken down using these tags. * **What if sub-organization Tags differ from the Parent organization?**\ \ Finout allows presentation and data breakdown only based on the parent organization's tags. Data using different tags will appear as "N/A" when filtering/grouping by the parent’s tags. Breakdown by sub-organization tags is not yet supported. * **Which Datadog API endpoint does Finout use to retrieve UAT data?**\ \ Finout retrieves UAT cost and usage data from Datadog using the [**Hourly Usage Metering API**](https://docs.datadoghq.com/api/latest/usage-metering/#get-hourly-usage-attribution), specifically the following endpoint:
* **How can I use UAT in Finout?**\ See [Usage Attribution Tags (UAT)](/billing-integrations/observability-platforms/connect-to-datadog/datadog-usage-attribution-tags-uat) for more details.
* **Who has UAT Integration in Finout?** \ \ Currently, the default integration is Custom Tags. However, for new accounts created since April 2025, the default state is [UAT-based integration](/billing-integrations/observability-platforms/connect-to-datadog/datadog-usage-attribution-tags-uat). For accounts older than that, the default remains Custom Tags, and they should contact Finout support at
* **What should I do to transition to the UAT-based integration?** * **If you currently have Datadog integration that uses Custom Tags**: \ No integration configuration changes are required once the UAT feature is enabled. \ The transition might affect the following features: * Saved Views * Widgets * Virtual Tags * Reallocations * Anomalies * Datadog Scans * Data Explorer Queries
Note: Contact support support@finout.io to get the list of the affected features within your account.
Note: The required migration might affect and break your current objects.
Note: Transitioning to UAT-based integration might require migration of the application features currently using Custom Tags data
usage\_read,
billing\_read
get-hourly-usage-by-product-family
| |usage\_read,
metrics\_read, timeseries\_query
logs\_read\_config
billing\_read
CostGuard- Out-of-the-box actionable cost optimizations for Idle Synthetics.
Note: Currently, the default integration is Usage Attribution Tags for new Datadog cost centers created since April 2025. For cot centers created before that, the default integration remains Custom Tags, and they should contact Finout support at
logs\_read\_config,
metrics\_read,
hosts\_read,
timeseries\_query
Logs Indexes
Metrics
Hosts
Metrics
- Enhanced Datadog integration- custom tags set by the customer
- Products basic list of tags- Indexed Log
get-all-hosts-for-your-organization
| To learn more about each capability and the data it requires, see the detailed explanations below. #### [Basic Datadog Integration](https://docs.finout.io/integrations/third-party/connect-to-datadog) The Basic Datadog integration enables Datadog cost visibility in Finout. With this integration: * Datadog is added as a cost center in Finout * Datadog costs appear in the MegaBill * Costs can be analyzed by: * Datadog product * usage type (committed vs on-demand) * Organization * Usage Attribution Tags Finout retrieves this information using Datadog billing APIs, allowing organizations to monitor their Datadog spend directly within Finout. Required scopes: `usage_read`, `billing_read` #### [Enhanced Datadog Integration](https://docs.finout.io/integrations/third-party/connect-to-datadog#faqs) The Enhanced Datadog integration expands the basic integration by enabling deeper cost analysis using Datadog tags and metric metadata. This allows Finout to: * Break down Datadog costs using the default Datadog custom tags * Provide richer cost attribution across Datadog services * support analysis across parent and child Datadog organizations These capabilities rely on additional Datadog APIs that provide access to metrics and metadata. Required scopes: `usage_read`, `metrics_read`, `timeseries_query`, `logs_read_config`, `billing_read` #### [Kubernetes Metrics Integration](/kubernetes-integrations/kubernetes/datadog) Datadog can also be used as a Kubernetes metrics source in Finout. When enabled, Finout retrieves Kubernetes resource usage metrics from Datadog to calculate how to distribute cluster infrastructure costs across Kubernetes workloads. This enables Finout to: * Allocate Kubernetes cluster costs across namespaces, workloads, and pods * Combine Kubernetes usage metrics with cloud infrastructure billing data * Provide Kubernetes cost visibility across Finout dashboards and analysis tools This integration relies on Datadog timeseries metrics APIs to retrieve CPU and memory usage metrics. Required scopes: `logs_read_config`, `metrics_read`, `hosts_read`, `timeseries_query` #### [CostGuard Integration](https://docs.finout.io/user-guide/optimize/costguard) The CostGuard integration enables Finout’s Datadog optimization insights. With this level enabled, Finout can analyze Datadog configuration data to generate cost-optimization recommendations. This includes: * Identifying Idle Synthetics * Surfacing optimization opportunities within CostGuard * Providing actionable insights to reduce unnecessary Datadog spend To enable this functionality, Finout requires read access to Datadog monitors and dashboards. Required scopes: `monitors_read`, `dashboards_read` # Datadog Usage Attribution Tags (UAT) ## What are Usage Attribution Tags (UAT)? UAT or user-defined tags in Datadog allow you to categorize resources and allocate costs using key-value pairs, such as team:engineering or project:beta. This feature enables more granular insights into usage patterns and cost breakdowns, helping you optimize your Datadog spend effectively. See [Datadog documentation](https://docs.datadoghq.com/account_management/billing/usage_attribution/) for more details. {% hint style="info" %} **Note**: * This feature is available only for accounts using Datadog’s Enterprise/Pro. * UATs can be created per Datadog organization (both parent and sub). * Each organization (parent/sub) supports up to 3 different UAT types. * Every parent /sub organization can select its own Usage Attribution Tags, they don’t have to be identical between different organizations. * UATs apply across all Datadog products the organization uses for cost and usage tracking. {% endhint %} ### **Integration Types:** UAT (Recommended) and Custom Tags Finout supports two Datadog integrations: UAT Integration (recommended) and Custom Tags Integration. UAT Integration provides detailed cost and usage breakdowns using Usage Attribution Tags, Datadog organizations, and regions, ensuring accurate data across all Finout features. At the same time, Custom Tags Integration retrieves only cost data based on user-defined tags, which can vary across products.**Key Benefits of Datadog UAT Integration:** * **Datadog Usage**: Easily track and analyze your **Datadog usage** with full support for fetching, presenting, and breaking down usage data by tags for deeper cost insights. * **More Coverage Across Datadog Products** – Allows the breakdown of cost and usage data of [multiple products](#uat-integration-with-datadog-products), unlike the previous Custom Tags integration. * **Accurate Cost and Usage Allocation** – UAT uses Datadog's native cost and usage allocation, eliminating guesswork and ensuring accurate and reliable cost distribution. * **Deeper Insights with Additional Breakdown Options** – Beyond UATs, you can also segment data by organizations and regions for a clearer financial picture. * **Consistent and Standardized Reporting** – Unlike custom tags, which vary by product, UAT provides a uniform and structured breakdown across organizations, sub-organizations, and regions. ### Prerequisites * UAT Integration is available only for Datadog Enterprise/Pro accounts. If your account is not on an Enterprise plan, you can use the Custom Tags integration as an alternative. * Your Usage Attribution Tags must be tagged at the parent organization level with an Enterprise/Pro account in Datadog.
Note: If you currently have the Custom Tags integration, contact us at support@finout.io to enable UAT.
{% endhint %} ## How can UAT be used in Finout? Usage Attribution Tags (UATs) in Datadog enable you to break down cost and usage data by your parent account's UATs, organizations (including sub-organizations), and regions. With UAT, you can analyze this data across all Finout features (except CostGuard) to make better-informed decisions and optimize cost management. For more details on integrating with Datadog, see [Connect to Datadog](/billing-integrations/observability-platforms/connect-to-datadog). **Use case: UAT in MegaBill** In Finout's MegaBill, you can view Datadog cost and usage data by grouping resources based on your UATs, organizations, or regions. This offers detailed insights into your Datadog's cost and usage. This analysis extends across features like Virtual Tags, Widgets, and Views, enabling better-informed decisions for optimizing cost management. Additionally, it improves your showback reports, providing clearer visibility into cost allocation and accountability. *Applying group-by for teams (where "team" is one of the accounts UATs):*
Run the setup commands in a new Snowflake worksheet using the ORGADMIN role
Click Connect Now on the Snowflake tile to open the setup wizard.
Verify your organization account details - they should match the pre-filled values.
Copy the public key, run the ALTER USER command in Snowflake, then check the confirmation box.
Finout detects all child accounts automatically. Deselect any you want to exclude.
Copy the SQL commands for each account, run them in Snowflake, then check the confirmation box.
Note: If you choose to use Key-pair authentication, you do not need to set a password when creating the user.
Note:
- Single organization accounts are automatically created when credit cost data is provided.
- For multiple organization accounts, compute and storage credits might change over time. Ensure that you update Finout support to keep your Snowflake cost accurate. Finout calculates the cost using usage * credit rate.
**1. Update Your Snowflake User Table:** * Open a worksheet in your Snowflake console. * Use the public key provided by Finout to update your Snowflake user permissions/authentication method: ``` ALTER USER
**2. Complete the Setup in Finout:** \ Return to the Finout console, mark **I have completed the ALTER USER command in Snowflake**, and click **Next**.\ Snowflake is onboarded and you will see Snowflake data in Finout within 24 hours.
## FAQs **Which Snowflake services are currently supported by Finout?** * Snowflake - Warehouse Reader Credits (Compute) * Snowflake - Warehouse Credits (Compute) * Snowflake - Warehouse Credits (Cloud Services) * Snowflake - Storage * Snowflake - Serverless Task Credits * Snowflake - Search Optimization Credits * Snowflake - Replication Credits * Snowflake - Pipe Credits * Snowflake - Materialization Credits * Snowflake - Auto Clustering Credits **I already have a Snowflake Cost Center (CC) with password authentication. How can I change it to key-pair authentication?** Follow these steps to switch from password to key-pair authentication: 1. **Request the public key**: Contact Support to obtain the public key. 2. **Update the Snowflake user**: Insert the provided public key in your Snowflake console using the `ALTER USER` command. Finout generates the key pair for you—securely storing the private key while giving you the public key to complete the setup.
# Connect to Databricks Connecting Databricks to Finout gives your team visibility into Databricks spend across all your workspaces, alongside your other cloud and SaaS costs. A single account-level connection covers every workspace automatically, with costs broken down by workspace, cluster, SQL warehouse, job, and pipeline - no manual DBU rate configuration required. {% hint style="warning" %} **Note for accounts with multiple workspaces** By following the steps below and giving Finout access to a Unity Catalog-enabled workspace, the costs reported in Finout will cover your whole account. You don't have to repeat this setup for multiple workspaces under the same account. {% endhint %} With this integration you can: * Track Databricks spend alongside your other cloud and SaaS costs in a single view * Break down costs by workspace, cluster, SQL warehouse, job, and pipeline * Use [Virtual Tags](https://docs.finout.io/user-guide/inform/virtual-tags) that include Databricks dimensions to allocate costs by team, project, or environment * Use [Shared Cost Reallocation](https://docs.finout.io/user-guide/inform/shared-cost-reallocation) to distribute shared cluster or warehouse costs across teams * Include Databricks cost data in custom [Dashboards](https://docs.finout.io/user-guide/inform/dashboards), [Anomalies](https://docs.finout.io/user-guide/optimize/anomalies), and financial plans {% hint style="info" %} Finout uses read-only access to Databricks system tables and does not modify or delete any of your data. Queries consume Databricks compute credits (DBUs). {% endhint %} *** ### Prerequisites Before connecting, make sure you have: * A Databricks account with account admin privileges * Unity Catalog enabled on any workspace — see the Databricks documentation for [AWS](https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/), [Azure](https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/manage-privileges), or [GCP](https://docs.databricks.com/gcp/en/data-governance/unity-catalog/manage-privileges/) * Metastore owner status for the Unity Catalog-enabled workspace *** ### 1. Set up in Databricks #### Step 1 — Collect your Account ID and Workspace URL 1. **Log in** to the Databricks account console. 2. **Click** your avatar in the top right and copy your **Databricks Account ID** — save this for the steps below.
| Field | Description |
|---|---|
| Cost Center Name | A name for this Cost Center in Finout |
| Service Principal Client ID | Client ID of the service principal created in Databricks |
| Service Principal Client Secret | Client secret generated in Databricks |
| Account Workspace URL | Workspace URL collected in Databricks (e.g. acme-inc.cloud.databricks.com)Make sure to remove your URL schema (e.g. https://) and any query params or paths following the top level domain (any ?xxx or /xxx after .com, .net etc.) |
# Connect to CircleCI ## Overview Finout calculates CircleCI costs by multiplying the number of credits consumed by the credit price you configure. Finout does **not** pull invoice data directly from CircleCI. With this integration, you can: * View CircleCI spend over time, broken down by organization, project, workflow, and job * Configure credit pricing across different date ranges to reflect contract changes * Monitor CI/CD costs using budgets and anomaly detection * Include CircleCI in showback and chargeback reporting alongside cloud and SaaS costs #### How it works Finout ingests usage data from CircleCI’s API and applies your configured credit pricing to calculate cost.\ Because CircleCI’s API does not provide cost data, all cost calculations in Finout are derived. {% hint style="info" %} **Note**: CircleCI’s Usage API does not expose cost data. As a result, you may see small differences between: * Costs calculated in Finout * Costs displayed in the CircleCI Plans UI For more details, refer to [CircleCI’s documentation on API limitations](https://support.circleci.com/hc/en-us/articles/34924793126427-Understanding-the-Difference-Between-CircleCI-s-Usage-API-and-Plans-UI). {% endhint %} #### Prerequisites Before you begin, make sure you have: * A CircleCI account with **Organization Admin** permissions. * Your contracted credit price(s) and their effective date ranges. * A Finout account with permissions to create a cost center. *** ## CircleCI Integration ### Step 1: Generate a CircleCI Personal API Token
Note: This step is required. Finout calculates the cost based on the credit price you define. If pricing is not configured, cost data will not be calculated correctly.
Note: It's recommended to cover 13 months to align with the maximum range supported by the CircleCI API.
Note: To add another pricing period, click + Add pricing period and enter the same credit pricing fields.
Make sure your pricing periods cover the entire time range—from your earliest start date through the current (ongoing) pricing period. The UI will not allow submission if there are gaps between periods.
Note:
- Additional dimensions can be added, as a dedicated column per dimension.
- Data should be uploaded as a single CSV file per day.
Note: Finout will automatically ingest every file created or updated since the previous ingestion; when past files are edited, their up-to-date versions will overwrite existing data.
# Credentials Vault ## **Overview** The Credentials Vault is a secure tool for sharing sensitive credentials with Finout. It ensures your secrets are transmitted and stored safely. To use it, simply upload your credentials and contact Finout support with clear instructions on what actions you'd like them to take with the provided information. {% hint style="info" %} **Note**: Credentials Vault is available only upon request and not by default. To activate it, users should contact Finout support at
# How Finout Calculates Kubernetes Costs ## Overview Kubernetes is an abstraction layer over your infrastructure that orchestrates resources and manages their lifecycles. At the base of Kubernetes, there are **containers**, which package your application’s code and dependencies. Containers are grouped into **pods**, the smallest deployable units in Kubernetes. Pods are grouped into **workloads** (deployments, statefulsets, or cronjobs), which define how your application runs and scales, adding business context by connecting each pod’s purpose to its broader goal. Each workload operates within a **namespace**, which serves as a logical scope that groups related workloads and resources, providing isolation, naming, and policy for environments, teams, or applications. Underneath these logical layers are the physical resources that Kubernetes manages: **nodes** (individual servers) and **clusters** (collections of nodes). Kubernetes orchestrates this entire stack and maintains the desired application state, ensuring availability. ### **The Challenges of Kubernetes Costs** Kubernetes cost allocation presents a unique challenge in cloud financial management. Unlike traditional cloud vendor billing, where costs are directly tied to specific resources, Kubernetes abstracts away the underlying infrastructure, making it difficult to attribute costs to individual pods, namespaces, deployments, and applications. ### **Finout’s Solution** Finout solves this challenge by combining Kubernetes request, usage, network metrics, with actual cloud billing data, transforming Kubernetes into a fully integrated cost center within your financial management framework. This integration ensures that Kubernetes cost data is available [across Finout](/kubernetes-integrations/kubernetes/kubernetes-across-finout), just like any other cloud provider. By treating Kubernetes as a standard cost center, users can leverage Finout's powerful cost management tools to address shared cost allocation and idle resource challenges effectively. #### High-Level Calculation Process Finout combines cloud billing data with Kubernetes metrics to accurately distribute node costs across Kubernetes abstractions based on resource consumption. 1. **Collect Metrics**: Finout gathers CPU and memory request and usage metrics, as well as network metrics from Kubernetes through its native integration with [Prometheus](/kubernetes-integrations/kubernetes/prometheus/prometheus-per-cluster-integration) or [Datadog](/billing-integrations/observability-platforms/connect-to-datadog), providing the foundation for accurate cost allocation and optimization. 2. **Parse Unit Metrics**: Finout identifies allocatable usage metrics per pod from raw Kubernetes data. 3. **Collect Node Costs**: Finout retrieves node costs from the cloud provider's billing. 4. **Apply Finout's Kubernetes Cost Algorithm**: Finout determines the resource’s CPU, Memory, and Network allocation and distributes the node costs accordingly. 5. **Idle Calculation**: Calculates and allocates costs for unused capacity. ## Step 1: Query the Metrics Finout reads Kubernetes metrics from your connected source ([Prometheus](/kubernetes-integrations/kubernetes/prometheus/prometheus-per-cluster-integration) or [Datadog](/billing-integrations/observability-platforms/connect-to-datadog)) and uses them as the foundation of the Kubernetes cost calculation. Finout gathers per pod CPU, Memory, and Network metrics. These metrics provide the basis for parsing the usage metrics per pod in [step 2](#h_699f450f42). {% hint style="info" %} **Note**: The data is sampled at a one-minute resolution every 30 minutes, with the 30-minute interval being configurable per account. {% endhint %} ## Step 2: Allocate the Metrics Finout processes the collected Kubernetes metrics and assigns them to their respective pods, generating hourly usage and request hourly metrics allocations per pod. This allocation is then used to calculate pod costs in [step 3](#h_535ee08152). ### CPU & Memory * Finout uses hourly Kubernetes metrics to calculate resource allocations for each pod, separately for CPU (cores) and memory (GiB). These allocations are later used to determine pod costs. * It reflects engineering intent (requests) and actual consumption (usage) to avoid under- or over-allocation. * For each hour, the CPU/Memory metrics allocation is **based on the larger value between the pod’s usage and the pod’s request**. * It’s **capped** **at the node’s capacity**, thereby excluding any pending pods or nodes. ### Network * Finout uses Kubernetes metrics to measure bytes received and bytes sent per pod (per hour), providing network usage context alongside CPU and memory. > **For Example**: > > * **Hour A:** CPU request peaks at **3 cores** in a certain hour, CPU usage peaks at **1 core** in the same hour → hourly CPU allocation = **3 cores**. > * **Hour B**: CPU usage peaks at **4 cores** (above request) → hourly CPU allocation = **4 cores**. > * The same “larger value of usage or request” rule applies to **Memory (GiB)** each hour. ## Step 3: Get the Hourly Price per Cloud Resource (Node) Finout takes the node’s resource cost directly from your cloud billing and uses it as the price to be allocated later across the Kubernetes abstractions (namespaces/workloads). * **Billing-sourced price**: Finout reads vendor’s billing exports (e.g., AWS CUR) to get the exact node $/hour. * **Discount-aware**: Finout considers Savings Plans, RIs, Spot, and EDP (when applicable), so the price reflects your real effective rate. * **Purpose**: This node's hourly price is used in the rest of the calculations. ## Step 4: Calculate the Pod Costs To calculate the cost of a pod, Finout uses the **hourly CPU, memory, and network** metrics allocations ([step 2](#h_e3918ed0e4)), along with the **hourly node cost** ([step 3](#h_535ee08152)), to determine the pod's CPU and memory cost, respectively. The hourly pod cost is reported as the total cost of the allocated CPU and memory within an hour. The problem is that the cloud provider does not provide billing data in this granularity, nor a CPU/memory cost breakdown. To apportion the node costs to CPU and memory costs in the pod level correctly, Finout specifies a configurable CPU/memory ratio applied in cost calculation algorithm for each resource, workload, cluster, or namespace. {% hint style="info" %} **Note**: Finout calculates Kubernetes costs at the pod level, based on each pod’s CPU and memory allocations. These calculations are then aggregated at the workload level (such as Deployments, CronJobs, and StatefulSets) and reflected in the MegaBill. This approach presents cost data in a meaningful business context rather than at the overly granular pod level. {% endhint %} ### Compute Costs #### **Calculation Process Overview:** 1. **Inputs**: Hourly Node Price ($/hour) from the cloud vendor billing + per-pod hourly CPU/Memory allocations. 2. **CPU:Memory ratio and algorithm**: This defines how node costs are split between CPU and Memory, and how the pod cost is calculated accordingly. \ There are two types of algorithms: Recommended and Legacy.\ \ [**Recommended algorithm**](#compute-cost-recommended-algorithm): Based on a 88:12 CPU:Memory default ratio. * Starting November 2024, the Recommended algorithm is the default for all new accounts. * The default CPU:Memory ratio is configurable per account. To change it, contact
Note: Pods that define CPU or memory requests but do not emit usage metrics are excluded from workload cost allocation and classified as Idle.
1. **Hourly Pod CPU Allocation**: Hourly pod CPU allocation is used to determine how much of the node’s CPU was allocated. This is based on the greater value of the average hourly CPU usage or the average hourly CPU request. See the full explanation about parsing the metrics per pod in [step 2](#h_699f450f42).
Note: For AKS cost calculation (Azure), the calculations are performed on a daily granularity, not an hourly granularity.
(Node Price / # Cores) x \[Hourly] Pod CPU Allocation x Node Uptime : (10 / 3) x 2 x 1 = 6.66$
|(Node Price / # Cores) x \[Hourly] Pod CPU Allocation x Node Uptime : (10 / 3) x 1 x 0.5 = 1.66$
| | Calculating Hourly Pod GiB Cost |(Node Price / # GiB) x \[Hourly] Pod GiB Allocation x Node Uptime : (10 / 8) x 3 x 1 = 3.75$
|(Node Price / # GiB) x \[Hourly] Pod GiB Allocation x Node Uptime : (10 / 8) x 5 x 0.5 = 3.125$
| | Calculating Hourly Pod Cost (50:50) | 6.66*0.5 + 3.75*0.5 = **5.205$** | 1.66*0.5 + 3.125*0.5 = **2.392$** | Based on this breakdown, the node cost according to Finout (Legacy algorithm) is: 5.205$ + 2.392$ = **7.6$**.\ Proportionally, the [Node idle cost](#h_6d91610b58) is: 10$ − 7.6$ = **2.4$**. #### Unutilized Pod Costs - Limited Release {% hint style="warning" %} This feature is under a **limited release** and isn't enabled by default. To enable it, contact Finout support at* Hourly Unutilized Pod CPU Allocation = `cpu_alloc − cpu_hourly_usage` * Hourly Unutilized Pod Memory Allocation (GB) = `mem_alloc_gb − mem_hourly_usage` {% hint style="info" %} **Note**: * If the allocation equals actual usage, the difference is 0, and no unutilized (waste) cost is generated. * If the calculated value is less than or equal to zero, that component does not contribute to Unutilized Pods. {% endhint %} 2\. Unutilized Cost Calculation The unutilized CPU and memory allocations are then used as the hourly allocation input at the standard Kubernetes [compute cost formulas](#compute-costs) described above. {% hint style="info" %} **Note**: * Unutilized Pod cost calculations apply to **Kubernetes compute rows only**. * For network rows, Finout emits **only Utilized Pods cost**. {% endhint %} ### Network cost Finout determines each node’s hourly data transfer cost using cloud provider data. It then allocates this cost to individual pods by analyzing their incoming and outgoing network traffic. Each pod’s share of the total node network cost is calculated according to its usage of the network metrics. {% hint style="info" %} **Note**: Pod idle costs are not calculated in the network cost. {% endhint %} ## Step 5: Calculate Node-Level Idle For each node and hour, **Node Idle** is the unallocated portion of the node’s price after pod costs are attributed according to Finout’s calculation in [Step 4](#h_da96737e2f): **Node Idle (per hour) = Node Price (billing, Step 3) − Σ (pod costs on that node for the same hour,** [**Step 4**](#h_da96737e2f)**)** #### Why does this happen? Idle capacity on a node is often associated with oversized instances or uneven packing. Kubernetes schedules pods onto available space; in busy, mixed workloads it’s tempting to use larger nodes that can host many pods. When demand drops, those large nodes can sit partially empty. Using smaller instance types (or tuning autoscaling) can reduce this idle. Conversely, nodes that are too small may also end up underused if they can’t efficiently host multiple workloads. #### Where to see and how to allocate this? Node-level idle appears in Finout under the **Idle Namespace** dimension. Teams often allocate it differently from **overhead** (platform essentials) to encourage efficiency. Use **Virtual** **Tags** to distribute Node Idle across the teams/applications of your choice.
Note: This is relevant for all widgets except for CostGuard.
Note: This can be done only if the teams virtual tag isn't using reallocation, and it can also be applied to any other virtual tag in your account.
# Prometheus ## Overview #### Agentless Kubernetes Cost Management Finout’s solution for managing container costs is entirely agentless, reducing security risks and eliminating performance overhead. It automatically detects Kubernetes usage and waste across any Kubernetes resource, whether running on Amazon EKS, Google GKE, or Azure AKS - and enriches your cost data for precise visibility and optimization. Finout integrates with Prometheus, supporting both Per-Cluster and Centralized Prometheus monitoring tools. #### How the Agentless Architecture Works Unlike traditional agent-based tools that run continuously and consume cluster resources, Finout uses a scheduled, read-only cronjob that runs periodically to collect Kubernetes metrics from your clusters, using Prometheus querying. **Key benefits of this design:** * *Non-intrusive:* No Finout components are installed in your cluster, and no Kubernetes resources are modified by Finout. * *Periodic collection:* metrics are gathered based on a user-configured schedule, minimizing resource impact. * *External storage:* collected metrics are stored in your configured S3 bucket; nothing is written directly to your cluster. * *Minimal setup:* works seamlessly with your existing Prometheus infrastructure without requiring elevated permissions or persistent components.\ \ This lightweight approach maintains both system security and operational efficiency, while providing a reliable cost visibility across all your Kubernetes environments. #### **This integration supports both metric collection methods**: * [**Per-Cluster Prometheus Monitoring**](/kubernetes-integrations/kubernetes/prometheus/prometheus-per-cluster-integration):\ Integrate Finout with the Prometheus instance in each of your monitored clusters. Each Cost Center’s configuration determines how the Finout Metrics Exporter CronJob collects metrics. The CronJob will be set up to gather data from every monitored cluster according to its associated Cost Center configuration.
*How do I integrate multiple clusters*? * Apply the [cronjob YAML](/kubernetes-integrations/kubernetes/prometheus/prometheus-per-cluster-integration#example-yaml) to every cluster that shares the same configuration. All of them will write to the same S3 bucket and prefix. * If you want different S3 locations (buckets/prefixes), create additional Prometheus integrations.
* **Centralized Prometheus Compatible Monitoring Tools:** \ Centralized Prometheus Monitoring tools aggregate metrics from multiple Kubernetes clusters into a single, unified monitoring system with a central Prometheus-compatible API. To integrate Centralized Prometheus Monitoring tools into Finout, create a single Prometheus integration that connects to that tool’s centralized API, by selecting the specific tool you’re using: * [Amazon Managed Prometheus](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations-1/amazon-managed-prometheus-integration) * [Chronosphere](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations-1/chronosphere-integration) * [Coralogix](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations/coralogix-integration) * [Mimir](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations/mimir-integration) * [Thanos](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations/thanos-integration) * [VictoriaMetrics](/kubernetes-integrations/kubernetes/prometheus/centralized-prometheus-monitoring-tool-integrations/victoriametrics-integration)
Note: Finout integrates seamlessly with all clusters you have connected to the selected centralized tool.
| Prometheus Metric | Required Labels | Required | Purpose |
|---|---|---|---|
kube_node_info | node, provider_id, cluster_label | Yes | Required to calculate Cost Allocation. This metric enables the connection of nodes and pods to billing. |
container_cpu_usage_seconds_total | node, namespace, pod, container, cluster_label | Yes | Actual container CPU usage. |
container_memory_working_set_bytes | node, namespace, pod, container, cluster_label | Yes | Actual container memory usage. |
kube_node_status_capacity{resource="cpu"} | node, cluster_label | Yes | Node CPU cores capacity. |
kube_node_status_capacity{resource="memory"} | node, cluster_label | Yes | Node memory capacity. |
kube_pod_container_resource_requests{resource="cpu"} | node, namespace, pod, container, cluster_label | Yes | Pod/container CPU requests improve accuracy and enable rightsizing recommendations in CostGuard. |
kube_pod_init_container_resource_requests{resource="cpu"} | node, namespace, pod, container, cluster_label | Yes | Improves accuracy by collecting CPU requests from initContainers. Relevant especially when the initContainers running as sidecars. |
kube_pod_container_resource_requests{resource="memory"} | node, namespace, pod, container, cluster_label | Yes | Pod/container memory improves accuracy and enables rightsizing recommendations in CostGuard. |
kube_pod_init_container_resource_requests{resource="memory"} | node, namespace, pod, container, cluster_label | Yes | Improves accuracy by collecting memory requests from initContainers. Relevant especially when the initContainers running as sidecars. |
container_network_receive_bytes_total | node, namespace, pod, container, cluster_label | Yes | Container incoming network usage. |
container_network_transmit_bytes_total | node, namespace, pod, container, cluster_label | Yes | Container outgoing network usage. |
kube_pod_labels | — | Recommended | Enables filtering/grouping by pod labels. |
kube_node_labels | — | Recommended | Enables filtering/grouping by node labels. |
kube_namespace_labels | — | Recommended | Enables filtering/grouping by namespace labels. |
kube_pod_info | — | Recommended | Needed to allocate costs to higher-level K8s objects (deployment, statefulset, daemonset, cronjob) instead of just pods. |
kube_replicaset_owner | — | Recommended | Allows rolling pod costs up to deployments accurately. |
kube_job_owner | — | Recommended | Allows rolling pod costs up to cronjob definitions rather than individual jobs. |
# Prometheus Per-Cluster Integration- ## Overview Integrate Finout with the Prometheus instance in each monitored cluster to track that cluster’s Kubernetes costs and waste directly in Finout. This Per-Cluster Prometheus cost enrichment is supported across all major clouds, including AWS, GCP, and Azure. * To connect multiple clusters that share the same configuration, apply the YAML from Step 3 (Create and Configure the CronJob) to each cluster. This will send all metrics to the same S3 bucket and prefix. * If you need different S3 locations (buckets or prefixes), create additional Prometheus integration for those clusters by contacting support at
| Category | Variable | Description | Required / Optional | Default | Notes |
|---|---|---|---|---|---|
| Scope & Multi-Cluster Behavior | CLUSTER_NAME | The cluster name defines the folder where metrics are stored in S3 and also appears as the cluster name within the Finout app. | Required | None | Identifies the metrics source cluster. |
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
| Category | Variable | Description | Required / Optional | Default | Notes |
|---|---|---|---|---|---|
| Scope & Multi-Cluster Behavior | CLUSTER_NAME | The cluster name defines the folder where metrics are stored in S3 and also appears as the cluster name within the Finout app. | Required | None | Identifies the metrics source cluster. |
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
apiVersion: batch/v1
kind: CronJob
metadata:
name: finout-prometheus-exporter-job
spec:
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
concurrencyPolicy: Forbid
schedule: "*/30 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: finout-prometheus-exporter
image: finout/finout-metrics-exporter:2.0.2
imagePullPolicy: Always
env:
- name: S3_BUCKET
value: "<BUCKET_NAME>"
- name: S3_PREFIX
value: "k8s/prometheus"
- name: CLUSTER_NAME
value: "<CLUSTER_NAME>"
- name: HOSTNAME
value: "The metrics endpoint, i.e, HOSTNAME=ng-api-http.eu2.coralogix.com"
- name: PORT
value: 443
- name: SCHEME
value: "https"
- name: PATH_PREFIX
value: "metrics"
- name: CLUSTER_LABEL_NAME
value: "<the label name in your metrics indicates the origin cluster>"
- name: PROMETHEUS_BEARER_AUTH_TOKEN
value: "<Bearer Token>”
restartPolicy: OnFailure
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Auth & Identity | PROMETHEUS_BEARER_AUTH_TOKEN | Bearer token placed in the Authorization: Bearer header for Prometheus calls. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible Coralogix API endpoint. | Required | None | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | Coralogix API port | Optional | 9090 | Metrics endpoint port |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
It is recommended to use with the
PROMETHEUS\_PASSWORD environment variable.
| | Auth & Identity | **PROMETHEUS\_PASSWORD** | Basic Auth credentials sent on Prometheus requests. | Optional | None |It is recommended to use with the
PROMETHEUS\_USERNAME environment variable.
| | Auth & Identity | **PROMETHEUS\_X\_SCOPE\_ORGID** | Tenant ID sent in X-Scope-OrgID header, for multi-tenant setups. | Optional | None | ----- || Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
It is recommended to use with the
PROMETHEUS\_PASSWORD environment variable.
| | Auth & Identity | **PROMETHEUS\_PASSWORD** | Basic Auth credentials sent on Prometheus requests. | Optional | None |It is recommended to use with the
PROMETHEUS\_USERNAME environment variable.
| | Auth & Identity | **PROMETHEUS\_X\_SCOPE\_ORGID** | Tenant ID sent in X-Scope-OrgID header, for multi-tenant setups. | Optional | None | ----- || Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
apiVersion: batch/v1
kind: CronJob
metadata:
name: finout-prometheus-exporter-job
spec:
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
concurrencyPolicy: Forbid
schedule: "*/30 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: finout-prometheus-exporter
image: finout/finout-metrics-exporter:2.0.2
imagePullPolicy: Always
env:
- name: S3_BUCKET
value: "<BUCKET_NAME>"
- name: S3_PREFIX
value: "<S3_PREFIX>"
- name: CLUSTER_NAME
value: "<CLUSTER_NAME>"
- name: HOSTNAME
value: "<PROMETHEUS_SERVICE>.<NAMESPACE>.svc.cluster.local"
- name: PORT
value: 9090
- name: SCHEME
value: "https"
- name: PATH_PREFIX
value: "< Optional path prefix appended to the Prometheus base URL when the API is served under a subpath or reverse proxy (e.g., data/metrics).>"
- name: CLUSTER_LABEL_NAME
value: "<the label name in your metrics indicates the origin cluster>"
restartPolicy: OnFailure
It is recommended to use with the
PROMETHEUS\_PASSWORD environment variable.
| | Auth & Identity | **PROMETHEUS\_PASSWORD** | Basic Auth credentials sent on Prometheus requests. | Optional | None |It is recommended to use with the
PROMETHEUS\_USERNAME environment variable.
| | Auth & Identity | **PROMETHEUS\_X\_SCOPE\_ORGID** | Tenant ID sent in X-Scope-OrgID header, for multi-tenant setups. | Optional | None | ----- || Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
```yaml { "Version": "2012-10-17", "Statement": [ { "Sid": "FinoutBucketPermissions", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Endpoint & Connectivity | HOSTNAME | The external AMP API endpoint. | Required | None | Must be reachable from the pod running the Finout exporter cronjob. Example: “ https://aps-workspaces.{AMP_REGION}.amazonaws.com/workspaces/{AMP_WORKSPACE_ID}" |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note:
- If this cost center is already enriched by a Kubernetes integration, ensure there are no overlapping nodes between the integrations to avoid duplicated costs and resources.
You can hover over every created cloud cost center and see all the Kubernetes cost centers that enrich it.
Note: This configuration will affect the following steps; adjust them accordingly.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Scope & Multi-Cluster Behavior | CLUSTER_LABEL_NAME | The cluster label name defines the label whose values represent cluster names in your metrics , allowing Finout to identify and group metrics by cluster from the single metrics endpoint. | Required | cluster | The value is "cluster" by default. |
| Endpoint & Connectivity | METRICS_READINESS_PATH | Allows Finout’s exporter to perform readiness validation, ensuring the Mimir API is fully available before scraping begins, using a custom readiness endpoint to change the default config. | Optional | /-/ready | This is unique for Chronoshpere. Note: Starting from version 2.0.3, this environment variable is not supported and will be ignored. |
| Scope & Multi-Cluster Behavior | CLUSTER_NAME | The cluster name defines the folder where metrics are stored in S3. | Required | Cluster names are extracted directly from the metric data. However, this environment variable is still required and determines the folder name under which all centralized metrics will be temporarily stored. It is recommended to set it to the name of the cluster where the cronjob is deployed. |
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
apiVersion: batch/v1
kind: CronJob
metadata:
name: finout-prometheus-exporter-job
spec:
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
concurrencyPolicy: Forbid
schedule: "*/30 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: finout-prometheus-exporter
image: finout/finout-metrics-exporter:2.0.6
imagePullPolicy: Always
env:
- name: S3_BUCKET
value: "<BUCKET_NAME>"
- name: S3_PREFIX
value: "k8s/prometheus"
- name: CLUSTER_NAME
value: "<CLUSTER_NAME>"
- name: HOSTNAME
value: "The metrics endpoint, i.e, HOSTNAME=ng-api-http.eu2.coralogix.com"
- name: PORT
value: 443
- name: SCHEME
value: "https"
- name: PATH_PREFIX
value: "metrics"
- name: CLUSTER_LABEL_NAME
value: "<the label name in your metrics indicates the origin cluster>"
- name: PROMETHEUS_BEARER_AUTH_TOKEN
value: "<Bearer Token>”
restartPolicy: OnFailure
This is unique for Coralogix.
Note: Starting from version 2.0.3, this environment variable is not supported and will be ignored.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Auth & Identity | PROMETHEUS_BEARER_AUTH_TOKEN | Bearer token placed in the Authorization: Bearer header for Prometheus calls. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible Coralogix API endpoint. | Required | None | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | Coralogix API port | Optional | 9090 | Metrics endpoint port |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note:
- If this cost center already enriched by a Kubernetes integration, ensure there are no overlapping nodes between the integrations to avoid duplicated costs and resources.
- You can hover over every created cloud cost center and see all the Kubernetes cost centers that enrich it.
Note: This configuration will affect the following steps; adjust them accordingly.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
This is unique for Mimir.
Note: Starting from version 2.0.3, this environment variable is not supported and will be ignored.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
Note: This configuration will affect the following steps; adjust them accordingly.
This is unique for Thanos.
Note: Starting from version 2.0.3, this environment variable is not supported and will be ignored.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity | ROLE_ARN | ARN for IAM role to assume for authorization. | Optional | None | Used if assuming a role instead of direct access. |
| Auth & Identity | ROLE_EXTERNAL_ID | External ID for assumed role. | Optional | None | Only needed if the IAM role requires an external ID. |
| Storage & Paths | S3_BUCKET | Customer’s S3 bucket to store the exported metrics. | Required | None | Must exist in customer’s environment. |
| Storage & Paths | S3_PREFIX | S3 prefix where metrics will be stored. | Required | None | For example, k8s/prometheus has to be the same s3_prefix if multiple per cluster integrations within the same cost center config. |
| Endpoint & Connectivity | SCHEME | The protocol used when calling the Prometheus metrics endpoint: either https or http | Optional | http | ----- |
| Endpoint & Connectivity | PATH_PREFIX | Optional sub-path between host/port and the Prometheus metrics API. | Optional | None | ----- |
| Endpoint & Connectivity | HOSTNAME | The Prometheus compatible API endpoint. | Optional | localhost | Must be reachable from the pod running the Finout exporter cronjob. |
| Endpoint & Connectivity | PORT | API port | Optional | 9090 | Standard Prometheus port. |
| Query Window & Data Volume | TIME_FRAME | Time range per query in seconds. | Optional | 3600 | Lower values reduce query load and risk of OOM. |
| Query Window & Data Volume | BACKFILL_DAYS | Days of historical data to fetch on first run. | Optional | 3d | Large values increase load and risk of slow queries. |
| Query Window & Data Volume | INITIAL_BACKFILL_DATE | Defines the initial backfill start date | Optional | None |
|
| Query Window & Data Volume | QUERIES_BATCH_SIZE | Controls how many queries are processed per batch to manage memory usage. | Optional | 5 |
|
Note: This can be changed by modifying your BACKFILL_DAYS variable.
# VictoriaMetrics Integration ## Overview This page covers Centralized Prometheus Monitoring via VictoriaMetrics: VictoriaMetrics exposes a single, PromQL-compatible API endpoint that aggregates metrics from multiple Prometheus servers across clusters. Because all metrics are reachable through one endpoint, Finout can read them without querying each cluster separately—a more efficient approach for large, multi-cluster environments. For a holistic introduction to Prometheus in Finout and alternative topologies, see the [Prometheus Integration Overview](/kubernetes-integrations/kubernetes). Finout supports Kubernetes enrichment across AWS, GCP, and Azure using the same pattern: VictoriaMetrics-sourced metrics are exported into your connected S3 bucket, and Finout reads them to enrich Kubernetes costs. #### VictoriaMetrics Setup at a Glance 1. **Set Collection Method:** Name your integration and select your metrics collection method. 2. **Connect S3 Bucket**: The destination for Kubernetes metrics. 3. **Set cronjob permissions:** This allows the cronjob to write the metrics into your S3 bucket. 4. **Configure the create cronjob YAML** using the template, and deploy it in the cluster. 1. Select the authentication method. 2. Set the required environment variables in the YAML and make additional adjustments, then deploy it in your cluster. 5. **Select cost centers:** This enriches with the integrated Kubernetes metrics. 6. **Validate your Kubernetes Integration:** Ensure that the Prometheus metrics are exported correctly to S3. **What happens next:** Finout creates a Prometheus (centralized) Cost Center, automatically links it to your AWS Cost Center, and begins enrichment. Data appears in Finout within \~2 days (cloud billing delay). {% hint style="success" %} **Note**: * This flow is **very similar to the Per-Cluster integration**, with a few YAML adjustments (notably the VictoriaMetrics endpoint and authentication variables). We’ll link to the Per-Cluster guide and list the specific VictoriaMetrics auth options and examples later in this doc. * Linking a Prometheus Cost Center to a non-AWS Cost Center (GCP or Azure) currently requires Support to complete on Finout’s side and cannot be done in-app. {% endhint %} ## 1. Set Collection Method
Note: This configuration will affect the following steps; adjust them accordingly.
apiVersion: batch/v1
kind: CronJob
metadata:
name: finout-prometheus-exporter-job
spec:
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
concurrencyPolicy: Forbid
schedule: "*/30 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: finout-prometheus-exporter
image: finout/finout-metrics-exporter:2.0.6
imagePullPolicy: Always
env:
- name: S3_BUCKET
value: "<BUCKET_NAME>"
- name: S3_PREFIX
value: "<S3_PREFIX>"
- name: CLUSTER_NAME
value: "<CLUSTER_NAME>"
- name: HOSTNAME
value: "<PROMETHEUS_SERVICE>.<NAMESPACE>.svc.cluster.local"
- name: PORT
value: 9090
- name: SCHEME
value: "https"
- name: PATH_PREFIX
value: "< Optional path prefix appended to the Prometheus base URL when the API is served under a subpath or reverse proxy (e.g., data/metrics).>"
- name: CLUSTER_LABEL_NAME
value: "<the label name in your metrics indicates the origin cluster>"
restartPolicy: OnFailure
This is unique for VictoriaMetrics.
Note: Starting from version 2.0.3, this environment variable is not supported and will be ignored.
| Category | Variable | Description | Required / Optional | Default Value | Notes |
|---|---|---|---|---|---|
| Auth & Identity |